Hacker News Reader

Comment by camtarn | Hacker News Reader

Since the article doesn't mention it til quite far in: Redis is apparently single threaded, which is why the blocking nature of OS page swapping is so disastrous. Presumably for a more traditional server with lots of worker threads this would be less true.

View on HN

It does make the conversation interesting, as the "varnish guy" sort of subtly suggests that single threaded is subpar. Which seems odd, given that nginx is single threaded, and in a somewhat similar space to varnish...and seems to enjoy a good reputation for performance.

http://www.cs.princeton.edu/~vivek/pubs/pai_flash_99.pdf

That's a reasonably good paper on the trade-offs between event-driven, multi-threaded, and hybrid approaches to file serving.

I don't know that much about nginx in particular, but it seems like they've implemented thread pools for blocking operations: https://www.nginx.com/blog/thread-pools-boost-performance-9x.... "Hard drives are slow (especially the spinning ones), and while the other requests waiting in the queue might not need access to the drive, they are forced to wait anyway." So, if you're blocking reading a file from the hard drive, all the other requests are queued up behind it.

The thread-pool approach noted in the nginx blog sounds pretty much the same as the approach in the linked paper.

nginx does have a good reputation for performance, but I think a lot of that reputation comes as a front-end for web applications rather than serving lots of hard-to-cache files.

Anyway, the nginx blog article as well as the academic paper note that single-threaded event-driven has drawbacks around file io and using a worker pool of threads or processes to offload blocking operations onto can help mitigate that.

The thread pools are optional, and reading the link you posted, not recommended unless specific conditions exist. They use streaming media as a good use case for the thread pools.

Nginx is commonly used as a caching proxy, and called out as being high performance in those cases. I can't speak as to whether what's being cached is "hard-to-cache" files.

> nginx does have a good reputation for performance, but I think a lot of that reputation comes as a front-end for web applications rather than serving lots of hard-to-cache files.

Netflix uses nginx to serve hard-to-cache files (using aio sendfile under FreeBSD).

nginx is a forking server, though, so individual workers being blocked wouldn't affect others, and the application as a whole can use all available CPU cores.

That's roughly the reply from antirez regarding redis being single threaded, just run more processes.

Let's start with Redis being single threaded, the path we are taking is to build "Redis Cluster"...This means that Redis will run 48 instances in a 48 core CPU...

Right, but running redis in that manner is far more operationally-intensive than running several nginx worker threads.

nginx runs workers by default, which (I believe) can be tuned by a couple config options.

To run multiple redis instances as a part of the same cluster, you need a way to shard your data (which you have to reason about client-side), you need separate config files, data directories, etc. for each instance. It's a huge pain.

It is subpar on Linux. On an engineered OS like FreeBSD it is amazing. There is a reason Netflix/Cloudflare/more run all their nginxs on BSD.

https://www.nginx.com/blog/thread-pools-boost-performance-9x...

I think the different between redis and webserver like nginx is that all the operations in redis is almost the same, it is about less than 1ms. However the request to nginx fall in a widely range, some request need 10ms, while some request need 10s. Since nginx need do some file operations.

So the single model work well for redis, but it doesn't work well for nginx, since if there is a request in nginx that is blocking for about 10s, people can't tolerate this situation.

Reply on news.ycombinator.com