Hacker News Reader

Comment by a-priori | Hacker News Reader

Okay here's a peeve of mine: just because something is in C ("no overhead!") doesn't mean it's faster than something in another language in all situations.

As an example, this server uses a thread pool architecture. This architecture will perform poorly with slow clients (common on the public Internet), servers which have to interact with slow disks or external services, and is useless for long-polling. It's only useful for CPU-bound applications when you can assume fast clients and short requests.

In fact, I could make this server grind to a halt by opening one connection per worker, issuing partial requests to each, then letting the connection hang. So to be used in production, this server will have to sit behind something like nginx, which can insulate your application from pathologically slow clients.

View on HN

> this server uses a thread pool architecture.

Is the README wrong? It says:

"Event driven architecture and worker processes for throughput"

To me this indicates using events for the external interface (slow clients), and threads for taking advantage of multiple cores.

It looks like the README is accurate. A number of child processes are forked off and then event processing is done with kqueue on the BSD platform and epoll on Linux.

Threaded servers are not necessarily slower than asynchronous architectures, though they can be. In fact, threaded models are coming back into fashion these days, and can (sometimes) be faster than asynchronous models when each thread is affine to a particular physical CPU. This is due to cache effects and the substitution of fast stack allocation for slow heap allocation.

Bazillions of threads using too much stack space have been a problem in the past, but these days servers have plenty of memory, and to some extent size can also be mitigated by tail call optimizations.

I don't think your particular DoS attack will work with this server, which implements an idle timer to recover stack space. However, they could go one step further and only allow worker threads to use n% of server memory, and killing old, slow connections when the thread is needed and the memory limit has been reached.

Modern threading implementations are pretty good. Plus, a lot of the memory threads use is just virtual address space, not real memory. On 32-bit systems you ran into the problem of running out of virtual address space with a few hundred threads. With the popularity of 64-bit platforms this problem has gone away. Plus, because this is C, it's trivial to reduce the stack size to, say, 512 KB without too many problems.

That's a terrible example, both because it has nothing to do with speed (your complaint is about scalability, not speed) and because it is wrong. Having a pool of workers to handle requests while using event driven interfaces is normal now, and gives you the best of both worlds. Your theoretical attack works the same as it would on nginx: you'd need to run it out of file handles.

Reply on news.ycombinator.com