4 ms·

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 disastrou

by camtarn 10y ago

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.

tyingq 10y ago
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.
- mdasen 10y ago
  http://www.cs.princeton.edu/~vivek/pubs/pai_flash_99.pdf 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/ 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.
  - tyingq 10y ago
    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.
  - deleted 10y ago
    [deleted]
  - citrin_ru 10y ago
    > 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).
- kelnos 10y ago
  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.
  - tyingq 10y ago
    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...
    - kelnos 10y ago
      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.
- smegel 10y ago
  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/ https://www.nginx.com/blog/thread-pools-boost-performance-9x...
deleted 10y ago
[deleted]
baotiao 10y ago
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.

by camtarn 10y ago

tyingq 10y ago

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.

mdasen 10y ago
http://www.cs.princeton.edu/~vivek/pubs/pai_flash_99.pdf 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/ 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.
- tyingq 10y ago
  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.
- deleted 10y ago
  [deleted]
- citrin_ru 10y ago
  > 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).
kelnos 10y ago
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.
- tyingq 10y ago
  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...
  - kelnos 10y ago
    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.
smegel 10y ago
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/ https://www.nginx.com/blog/thread-pools-boost-performance-9x...

deleted 10y ago

[deleted]

baotiao 10y ago

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.