diff options
Diffstat (limited to 'doc/performance.txt')
| -rw-r--r-- | doc/performance.txt | 142 |
1 files changed, 74 insertions, 68 deletions
diff --git a/doc/performance.txt b/doc/performance.txt index 06a767b..3a5b964 100644 --- a/doc/performance.txt +++ b/doc/performance.txt @@ -12,10 +12,10 @@ Module: core :abstract: handling performance issues in lighttpd - + .. meta:: :keywords: lighttpd, performance - + .. contents:: Table of Contents Description @@ -24,17 +24,17 @@ Description Performance Issues ------------------ -lighttpd is optimized into various directions. The most important is -performance. The operation system has two major facalities to help lighttpd -a deliver it best performance. +lighttpd is optimized into varying directions. The most important direction is +performance. The operation system has two major facilities to help lighttpd +a deliver its best performance. HTTP Keep-Alive --------------- Disabling keep-alive might help your server if you suffer from a large -number of open file-descriptors. +number of open file descriptors. -The defaults fo the server is: :: +The defaults for the server are: :: server.max-keep-alive-requests = 128 server.max-keep-alive-idle = 30 @@ -42,7 +42,7 @@ The defaults fo the server is: :: server.max-write-idle = 360 handling 128 keep-alive requests in a row on a single connection, waiting 30 seconds -before a unused keep-alive connection get dropped by lighttpd. +before an unused keep-alive connection gets dropped by lighttpd. If you handle several connections at once under a high load (let's assume 500 connections in parallel for 24h) you might run into the out-of-fd problem described below. :: @@ -50,22 +50,22 @@ in parallel for 24h) you might run into the out-of-fd problem described below. : server.max-keep-alive-requests = 4 server.max-keep-alive-idle = 4 -would release the connections earlier and would free file-descriptors without a to large -performance loss. +would release the connections earlier and would free file descriptors without a +detrimental performance loss. -Disabling keep-alive completly is the last choice if you are still short in filedescriptors: :: +Disabling keep-alive completely is the last resort if you are still short on file descriptors: :: server.max-keep-alive-requests = 0 Event Handlers -------------- -The first one is the Event Handler which cares about notifying the server -that one of the connections is ready to send or to recieve. As you can see -every OS has at least the select() call which has some limitations. +The first one is the Event Handler which takes care of notifying the server +that one of the connections is ready to send or receive. As you can see, +every OS has at least the select() call which has some limitations. ============ ========== =============== -OS Method Config-Value +OS Method Config Value ============ ========== =============== all select select Unix poll poll @@ -76,151 +76,157 @@ FreeBSD, ... kqueue freebsd-kqueue ============ ========== =============== -For more infomation in this topic take a look at http://www.kegel.com/c10k.html +For more information on this topic take a look at http://www.kegel.com/c10k.html Configuration ````````````` -The event-handler can be set by specifying the 'Config-Value' from above +The event handler can be set by specifying the 'Config Value' from above in the ``server.event-handler`` variable e.g.: :: server.event-handler = "linux-sysepoll" - + Network Handlers ---------------- The basic network interface for all platforms at the syscalls read() and -write(). Each modern OS provides its own syscall to help network servers -to transfer files as fast as possible. +write(). Every modern OS provides its own syscall to help network servers +transfer files as fast as possible. -If you want to send out a file from the webserver it does make any sense +If you want to send out a file from the webserver, it doesn't make any sense to copy the file into the webserver just to write() it back into a socket in the next step. sendfile() minimizes the work in the application and pushes a file directly -into the network card (idealy spoken). +into the network card (ideally). -lighttpd supports all major platform specific calls: +lighttpd supports all major platform-specific calls: -========== ========== -OS Method ========== ========== -all write -Unix writev -Linux 2.4+ sendfile -Linux 2.6+ sendfile64 +OS Method +========== ========== +all write +Unix writev +Linux 2.4+ sendfile +Linux 2.6+ sendfile64 Solaris sendfilev FreeBSD sendfile -========== ========== +========== ========== -They are selected automaticly on compile-time. If you have problems check +They are selected automatically at compile-time. If you have problems, check ./src/network_backend.h and disable the corresponding USE\_... define. Max Connections --------------- -As lighttpd is a single-threaded server its main resource limit is the -number of file-descriptors which is (on most systems) set to 1024 by default. +As lighttpd is a single-threaded server, its main resource limit is the +number of file descriptors, which is set to 1024 by default (on most systems). If you are running a high-traffic site you might want to increase this limit by setting :: server.max-fds = 2048 - + This only works if lighttpd is started as root. Out-of-fd condition ------------------- -As fds are used for tcp/ip sockets, files, directories, ... a simple request -for a PHP page might result in using 3 fds: +Since file descriptors are used for TCP/IP sockets, files and directories, +a simple request for a PHP page might result in using 3 file descriptors: 1. the TCP/IP socket to the client 2. the TCP/IP and Unix domain socket to the FastCGI process -3. the filehandle to the file in the document-root to check if it is really existing +3. the filehandle to the file in the document root to check if it exists -If lighttpd runs out of file-descriptors it will stop accepting new -connections for while to use the currently available fds (file-descriptors) -to handle the currently running requests. +If lighttpd runs out of file descriptors, it will stop accepting new +connections for awhile to use the existing file descriptors to handle the +currently-running requests. -If more than 90% of the fds are used the the handling of new connections is -disabled, if it dropes below 80% again new connection will accepted again. +If more than 90% of the file descriptors are used then the handling of new +connections is disabled. If it drops below 80% again new connections will +be accepted again. Under some circumstances you will see :: ... accept() failed: Too many open files -in the error-log. This tells you the you had to many new requests at once -and lighttpd could not disable the incomming connections soon enough. The -connection is drop and the client will get a error-message like 'connection -failed'. This is very rare and might only occur in test-setups. +in the error log. This tells you there were too many new requests at once +and lighttpd could not disable the incoming connections soon enough. The +connection was dropped and the client received an error message like 'connection +failed'. This is very rare and might only occur in test setups. -Increasing the ``server.max-fds`` limit will reduce the propability of this +Increasing the ``server.max-fds`` limit will reduce the probability of this problem. stat() cache ============ -A stat(2) can be expensive, caching it saves time adn context-switches.. +A stat(2) can be expensive; caching it saves time and context switches. -Instead of stat() for the existence of the file you can stat() it once and -monitor the directory the file is in for modifications. As long as the -directiry doesn't change, the files in it are all the same. +Instead of using stat() every time to check for the existence of a file +you can stat() it once and monitor the directory the file is in for +modifications. As long as the directory doesn't change, the files in it +must all still be the same. With the help of FAM or gamin you can use kernel events to assure that -your stat-cache is up to date. :: +your stat cache is up to date. :: server.stat-cache-engine = "fam" # either fam, simple or disabled -Plattform Specific Notes -======================== +Platform-Specific Notes +======================= Linux ----- -For Linux 2.4.x should should think about compiling lighttpd with the option -``--disable-lfs`` to disable the support for files larger than 2Gb. lighttpd will +For Linux 2.4.x you should think about compiling lighttpd with the option +``--disable-lfs`` to disable the support for files larger than 2GB. lighttpd will fall back to the ``writev() + mmap()`` network calls which is ok, but not as -fast as possible but support files larger than 2Gb. +fast as possible but support files larger than 2GB. Disabling the TCP options reduces the overhead of each TCP packet and might -help to get the last few percent of performance out of the server. +help to get the last few percent of performance out of the server. Be aware that +disabling these options most likely decreases performance for high-latency and lossy +links. -- net.ipv4.tcp_sack = 0 +- net.ipv4.tcp_sack = 0 - net.ipv4.tcp_timestamps = 0 Increasing the TCP send and receive buffers will increase the performance a -lot if (and only if) you have a lot large files to send. +lot if (and only if) you have a lot of large files to send. - net.ipv4.tcp_wmem = 4096 65536 524288 - net.core.wmem_max = 1048576 -If you have a lot large file uploads increasing the receive buffers will help. +If you have a lot of large file uploads, increasing the receive buffers will help. - net.ipv4.tcp_rmem = 4096 87380 524288 - net.core.rmem_max = 1048576 -Keep in mind that the buffers have to multiplied by server.max-fds and be -allocated in the Kernel area. Be carefull with that. +Keep in mind that every TCP connection uses the configured amount of memory for socket +buffers. If you've got many connections this can quickly drain the available memory. + +See http://www.acc.umu.se/~maswan/linux-netperf.txt for more information on these parameters. FreeBSD ------- -On FreeBSD you might gain some performance by enabling accept-filters. Just +On FreeBSD you might gain some performance by enabling accept filters. Just compile your kernel with: :: options ACCEPT_FILTER_HTTP -For more ideas in tuning FreeBSD read: tuning(7) +For more ideas about tuning FreeBSD read: tuning(7) Reducing the recvspace should always be ok if the server only handles HTTP requests without large uploads. Increasing the sendspace would reduce the -system-load if you have a lot large files to be sent, but keep in mind that -you to provide the memory in kernel for each connection. 1024 * 64k would mean -64M of kernel-ram. Keep this in mind. +system load if you have a lot of large files to be sent, but keep in mind that +you have to provide the memory in the kernel for each connection. 1024 * 64KB +would mean 64MB of kernel RAM. Keep this in mind. - net.inet.tcp.recvspace = 4096 |