diff options
author | Eric Wong <normalperson@yhbt.net> | 2010-08-30 23:25:59 -0700 |
---|---|---|
committer | Eric Wong <normalperson@yhbt.net> | 2010-08-30 23:30:30 -0700 |
commit | 2023d725a57b400d8f19a6aad2e7d119ee27d7f3 (patch) | |
tree | ae0192878f83d6507efb887da5f2b920ab36e475 | |
parent | d634b0699c8eceece5694680be0fc5e731717d92 (diff) | |
download | unicorn-2023d725a57b400d8f19a6aad2e7d119ee27d7f3.tar.gz |
Large buffers can hurt as well as help. And the difference in real apps that do a lot of things other than I/O often makes it not worth it. (cherry picked from commit f9a7a19a361fd674bab4e2df7e0897015528bba7)
-rw-r--r-- | TUNING | 8 |
1 files changed, 7 insertions, 1 deletions
@@ -22,7 +22,13 @@ See Unicorn::Configurator for details on the config file format. listeners under Linux 2.6 because auto-tuning is enabled. UNIX domain sockets do not have auto-tuning buffer sizes; so increasing those will allow syscalls and task switches to be saved for larger requests - and responses. + and responses. If your app only generates small responses or expects + small requests, you may shrink the buffer sizes to save memory, too. + +* Having socket buffers too large can also be detrimental or have + little effect. Huge buffers can put more pressure on the allocator + and may also thrash CPU caches, cancelling out performance gains + one would normally expect. * Setting "preload_app true" can allow copy-on-write-friendly GC to be used to save memory. It will probably not work out of the box with |