3 ms·
While node.js is great at non-blocking IO, it's not great at the blocking kind. E.g., shuffling bytes. While you are correct that node.js is happily not blocki
by vkjv 12y ago
While node.js is great at non-blocking IO, it's not great at the blocking kind. E.g., shuffling bytes.
While you are correct that node.js is happily not blocking the main thread while reading from disk, once that returns it still needs to serialize that data from I/O to the request and that is both blocking and slow.
I highly advise that you don't use node.js to service static content outside of a development environment. And if you are already using nginx in front of node, you might as well use it for SSL.
As a bonus, nginx does a great job proxying multiple node.js processes. You could also use the cluster module, but last time I checked, that was still marked as experimental.
- nailer 12y ago> it still needs to serialize that data from I/O to the request and that is both blocking and slow. That's incorrect. See edit to parent post (sorry I couldn't reply earlier).
- virmundi 12y agoI know that the parent replied already, but I want add that using node for static content is a good idea. I/O is what Node excels at. As long as you use the non-blocking API to load content, you should get good throughput. What Node is bad at is processing dynamic things. If your templates are CPU intensive, you'll block Node. This is why I'm, to this day, confused about building whole websites on Node. Dynamic, templated web sites are computation intensive (without result caching). Sure you can have N-Nodes running for N cores. This will minimize blocking. I/O for DB is time intensive so Node will pickup other workloads while it waits. So everything averages out, but it still an interesting thing often overlooked.