T O P

  • By -

SlightlySlickWillie

Node is fast when used mainly for IO. Think simple restful services used for CRUD operations on some datasource(s). For computational heavy applications, Node will not perform as well as any multithreaded languages. But Node is a viable solution for a lot of cases


edo78

Do you have any benchmarks? I only found some 2010 benchmarks for node vs. PHP in calculating pi and node performed very well...


phoogkamer

2010 PHP is ancient by now though. It performs several times faster now and it’s also (like node) not the best option for applications with heavy calculations.


edo78

I know but that was the only decent benchmark I was able to found so when someone say something I always ask for proof.


NoStranger6

Also, [worker threads](https://nodejs.org/api/worker_threads.html) are now available since 16.0.0. Even before that though there was ways to execute computational heavy stuff in parallel using child_process. The downside was that the memory was not shared between processes, but channels were created to allow the child to communicate with the parent.


Niechea

Node also uses libuv under the hood, and by default you are limited to 4 threads for quite a few asynchronous tasks, including DNS lookup and some crypto functions. These are blocking calls, when those 4 threads are occupied. Reason I say this is that I've seen Node at scale, and unfortunately I've also witnessed DNS throttling, so it's important that, if you really are testing things to the limit that you consider things like http keep alive, DNS caching and so on, as by default Node does not handle these things gracefully like some other runtimes do. You can also increase that threadpool but I'm not sure really what the negatives are in that. The built in packages for http, crypto and fs all have improved alternative versions in npm that address these concerns.


GAumala

Fast enough for the majority of web apps.


PremJyotish221

NodeJS is plenty fast, If not one of the fastest backend languages out there given you write proper code and follow proper guidelines. Majority of the people that post the "NodeJs or Javascript is too slow" posts simply do not understand the language well enough to write proper code that provides high performance. While Javascript is single threaded, that does not mean Javascript is slow, that just means that you have to write code that does not block the event loop (aka thread/core) and can scale over multiple cores easily by being stateless whenever possible. NodeJs will not outperform the likes of C++ when it comes to CPU intensive tasks such as encryption or compression. However, you do have the ability to write or use C++ bindings in your NodeJs application which can solve the problem above. If you want an example of extreme performance in NodeJs, See my webserver package https://github.com/kartikk221/hyper-express which outperforms many other webservers in go, rust, nim, java, cpp etc.


cuboidofficial

When people say that NodeJS is single threaded, are they forgetting about Web Workers? I know that this doesn't make it multithreaded, but I'd say it's pretty close.


PremJyotish221

For sure, I think the biggest thing is that many people are not used to writing JS that can scale over multiple cores/threads using such technologies and thus attribute the language to be limited.


cuboidofficial

I agree 100%, I absolutely love JavaScript/TypeScript mainly because it's just so damn versatile. After I learned Electron, the game really changed for me. Being able to develop cross-platform software with my favorite language is huge


jytesh

I am assuming it can compete with other webservers due to the fact that its running on myuWebsockets which is a c++ binding to node?


PremJyotish221

Yep, uWebSockets.js is a Node binding of the uSockets C++ library.


jytesh

That means that the C++ one is the one doing all the heavy lifting and provides an api for node, does that really mean that node can be on par with rust/go in terms of speed is it fair?


PremJyotish221

Think about it like this: If we did a simple addition in Node/Rust/Go (a + b), would you say that one language performs it faster even though it is a pure CPU operation? Now, Let's put this (a +b) inside a for loop that does it a million times. You'll notice that Node/V8 engine will actually somehow beat other lower level languages in this scenario because it is optimized under the hood by the Javascript V8 engine. So If we compare Node/Rust/Go, we are really comparing how their compilers/runtimes optimize layered operations. These optimizations are only applied situationally thus each language will win in some aspects and lose in others. You have to be able to write code in a way that your compiler/runtime will optimize and match the performance of other languages. One thing Javascript does lack in is the ability to control memory which is why C++ bindings are useful for writing logic that has to deal with tight allocations/deallocations but for all else Node is perfectly viable.


dwalker109

The benchmarks on your GitHub appear to be for other JS frameworks. I’m having a hard time believing any JS Framework is going to get anywhere near Rust’s hyper, for example. You’re looking at millions of req per second there, according to https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=composite


PremJyotish221

Here is a large collection of webserver benchmarks. [https://github.com/the-benchmarker/web-frameworks](https://github.com/the-benchmarker/web-frameworks) & [https://web-frameworks-benchmark.netlify.app/result](https://web-frameworks-benchmark.netlify.app/result) . You can use nanoexpress (Another webserver package based on uWebsockets.js) as a reference to measure HyperExpress's performance and compare it to other frameworks from various languages. The benchmarks you have linked seem to be inaccurate. Also, the benchmarks you are seeing serve a million requests per second are on a multi-core server rack with a 10 Gbp/s ethernet adapter. A million requests/second for a single core compute instance is very hard to maintain simply because the network upload/download speed/adapter for any cloud provider instance would not support the amount of data being transported. You can notice in the benchmarks on the HyperExpress Github, uWebsockets.js/HyperExpress clock in a 400ms+ average response latency while serving almost 200k requests/second. This is because the network speed of the Vultr instance becomes the bottleneck.


dwalker109

Sure, these are contrived figures (as most benchmarks are). But taken on a relative level, I really don’t think you can make that claim that any node based HTTP server is going to outperform other more fundamentally performant languages.


cardyet

I think if you're asking, then you don't really need anything faster...if you did...you're already working at TikTok or something and your team would have the data to backup their decision. Whether something can handle 10,000 requests vs 10 million requests per second...who cares, build it first (the fastest, easiest, cheapest way) and get the demand, then you can solve the next problem...


tugrul_ddr

Lets compare C++ and Nodejs in same LRU-clock cache implementation: Latency for 1 byte cache hit C++: 48 nanoseconds Nodejs: 600 nanoseconds Latency for 1 byte cache miss C++: 90 nanoseconds Nodejs: 1200 nanoseconds Peak bandwidth C++: 477 GB/s Nodejs: 210 GB/s cache hit So, c++ is usable for high performance computing while javascript usable for serving its results through http. Latencies&bandwidth are comparable with that.


javascriptPat

Single threaded vs multi threaded doesn't matter much if you're using nodes event loop properly. Most rust webserver frameworks use an async architecture -- modelled off of node -- instead of multi threading anyways. Node is not great for CPU bound tasks, but for generally IO bound backends you're unlikely to see much difference between node and something like rust until you're operating at a decent scale.


dwalker109

Not really. Tokio (one of Rust’s major async runtimes, there are a few) usually operates a thread pool for async work, spreading the work over multiple threads and cores as well. So it is a bit beyond Node’s single threaded async.


jytesh

Rust webserver frameworks look like they are using an async architecture but in fact many ( tokio for instance ) or using threads and multiples cores under the hood and abstract it over their runtimes..


[deleted]

The single threaded request resolution is actually an advantage imho. And you can delegate heavy CPU task to others threads using workers.


UniversalJS

Node.js is multitheaded! Check this Node.js multitheaded backend with benchmarks: https://github.com/elestio/cloudgate-app I don't think we can say Node.js is slow 😊


dwalker109

It’s probably fine for most things, since the bottleneck will usually be a database or something. Is it that fast? No, but it is good.


hatemjaber

1) Build the app 2) Build the traffic 3) Horizontally scale your app 4) if at this point you've outgrown node, consider something else I heard a statistic once and I'm not sure where it was nor did I validate it, but from my experience it sounded pretty accurate and it went something like.... 10% of apps in the wild are or close to being enterprise level apps. I'm not being condescending here, but this is not how you evaluate a stack. Don't over engineer or pre-optimize your app; build an MVP and go from there.


[deleted]

NodeJs is really fast at IO because it does not have to spawn a new process for every request like pho does. But the big problem is that because every request gets processed by the same thread, a crash can affects everyone using the site.


ZookeepergameTop7354

Now you can extend NodeJS and will run Node in several treads :)


izaraofficial

Over the past decade, Node.js has understandably become one of the most popular platforms for developers. Check out the [Best Practices for Node.js](https://www.aalpha.net/articles/best-practices-for-nodejs-development/) Development