3 ms·
> If you were to do this on nginx you'd have to write the > module in C. You can write a module to glue nginx and V8. Many people've done it. It takes less t
by alecco 16y ago
> If you were to do this on nginx you'd have to write the
> module in C.
You can write a module to glue nginx and V8. Many people've done it. It takes less than 400 lines of code and a lot of it is nginx typical module code. (The problem is more about the lack of nginx online help, perhaps.)
> The fact that you can write a web server in a few lines of easy to
> understand and maintain Javascript that can handle over 10,000
> concurrent connections without breaking a sweat is a
> breakthrough.
Yes. But the big performance issue still is hitting the database and disks. There's no point in having a super fast web server if the DB is dog slow like the vast majority of databases out there. Including the NoSQL bunch. They are not fixing the issue of latency vs. scalability vs. reliability. For that they need to address many uncomfortable problems of current hardware architectures. This is the elephant in the room.
- IsaacSchlueter 16y agoWell, at least it's an elephant we're all talking about a lot. It's not as if anyone's ignoring that. If your DB is dog slow, you can still handle wildly high concurrency with node. It's just that the user will feel the slowness, and your DB will struggle. But at least your server won't be unable to serve requests while it's waiting for IO. Of course it's still on the developer to architect their system for success. Node just takes one unnecessary bottleneck out of the equation.