-
-
Notifications
You must be signed in to change notification settings - Fork 231
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add benchmarks for native NodeJS (LTS) server? #255
Comments
Edit - after reading a blog regarding the Fastify benchmarks, is it correct to understand that "bare" is the native server? If so, perhaps making this more explicit in the results table might be helpful for some as this wasn't immediately clear to me? |
Yes, bare is the native http server. Would you like to make a PR to keep this clearer? |
Yep will do that - I think just a minimal "(Node 14.x.x)" suffix should be enough if that sounds ok? (I assume from reading the main page, this is the version used in the current benchmark?) |
I think that might be off too, check what versions the benchmarks are actually run. You can bring it up to v18. |
This is the correct entrypoint to the generator that produces the markdown yeah? |
Here is the actual version running against the benchmark.
Yes, you can update the static version to Line 7 in da0b992
|
Note that we should also update this to node v18 |
Prerequisites
🚀 Feature Proposal
I might be misreading one of the existing labels which perhaps already provides this benchmark, but it would be great to get a benchmark for the native (LTS) NodeJS
node:http
server class.Motivation
This would help when justifying the use of Fastify to stakeholders when presented with the "why not native?" question where native may be a reasonable option when provided the context of a performance differential.
Currently, I find myself leaning too heavily on "because we might need additional features in the future", which feels weak from a justification perspective, without knowing how much more (or less) performance might be gained from implementing the native server instead.
Example
An example would be when planning a small, simple http or websocket server for an internal application.
It's unknown or unlikely if more advanced features might be required in the future, but refactoring to Fastify in the event this occurs would be expensive.
Although certainly not the only factor within the decision matrix, the performance differential (especially if the result is better-than-native) would be a key consideration when calculating a cost/benefit EV of the comparison.
The text was updated successfully, but these errors were encountered: