4 ms·
Old post, as a side note, i've performed some tests with nginx and his configuration 1-2 weeks ago on linode and the results on the smallest linode were nearly
by drtse4 15y ago
Old post, as a side note, i've performed some tests with nginx and his configuration 1-2 weeks ago on linode and the results on the smallest linode were nearly 10-15% less than what the author report in his post (quite good imo).
If someone with a less optimized configuration is wondering what in his test configuration allows him to obtain those results, here is a brief recap:
1- Tests performed with ab with keepalive enabled on both the client and server
2- open_file_cache or similar options: this enable file caching, so basically the server is no more i/o bound
3- Furthermore, enabling tcp nodelay (that disables nagle alg, usefull when we have small tcp responses) and disabling access logging (this depends on how logging is implemented, if non-blocking and on a separate thread (not a worker) disabling it doesn't improve the results) could help a bit.
Being a cpu-bound test, having the client on a separate machine would have likely increased the results but i doubt it would have changed the performance ratio among them, after all in every test we had the same client with the same overhead.
- justin_vanw 15y agoI don't know what open_file_cache does specifically, but if you have enough memory to cache the file, then linux would have enough memory to cache it as well? In that case, aren't you really overcoming being IO bound, but rather avoiding the file opening/closing overhead?
- drtse4 15y agoThe open_file_cache_* options in nginx (but other server have similar options) allows to cache in memory the file so the disk is used only when the cached value is no more valid (timed to 30s lifetime on the linked tests). After a quick refresh of how the buffer cache works, i'd say that you are correct and that with the option above the server is also using a simpler data structure to retrieve those cached pages (no blocks list to traverse, no access locks). The difference in performance with and without this option was huge in a quick test, enabling the server caching i saw the number of req/s increase 400%-500%.