Annotation of embedaddon/lighttpd/doc/outdated/performance.txt, revision 1.1
1.1 ! misho 1: ========================
! 2: Performance Improvements
! 3: ========================
! 4:
! 5: ------------
! 6: Module: core
! 7: ------------
! 8:
! 9: :Author: Jan Kneschke
! 10: :Date: $Date: 2004/11/03 22:26:05 $
! 11: :Revision: $Revision: 1.3 $
! 12:
! 13: :abstract:
! 14: handling performance issues in lighttpd
! 15:
! 16: .. meta::
! 17: :keywords: lighttpd, performance
! 18:
! 19: .. contents:: Table of Contents
! 20:
! 21: Description
! 22: ===========
! 23:
! 24: Performance Issues
! 25: ------------------
! 26:
! 27: lighttpd is optimized into varying directions. The most important direction is
! 28: performance. The operation system has two major facilities to help lighttpd
! 29: a deliver its best performance.
! 30:
! 31: HTTP Keep-Alive
! 32: ---------------
! 33:
! 34: Disabling keep-alive might help your server if you suffer from a large
! 35: number of open file descriptors.
! 36:
! 37: The defaults for the server are: ::
! 38:
! 39: server.max-keep-alive-requests = 128
! 40: server.max-keep-alive-idle = 30
! 41: server.max-read-idle = 60
! 42: server.max-write-idle = 360
! 43:
! 44: handling 128 keep-alive requests in a row on a single connection, waiting 30 seconds
! 45: before an unused keep-alive connection gets dropped by lighttpd.
! 46:
! 47: If you handle several connections at once under a high load (let's assume 500 connections
! 48: in parallel for 24h) you might run into the out-of-fd problem described below. ::
! 49:
! 50: server.max-keep-alive-requests = 4
! 51: server.max-keep-alive-idle = 4
! 52:
! 53: would release the connections earlier and would free file descriptors without a
! 54: detrimental performance loss.
! 55:
! 56: Disabling keep-alive completely is the last resort if you are still short on file descriptors: ::
! 57:
! 58: server.max-keep-alive-requests = 0
! 59:
! 60: Event Handlers
! 61: --------------
! 62:
! 63: The first one is the Event Handler which takes care of notifying the server
! 64: that one of the connections is ready to send or receive. As you can see,
! 65: every OS has at least the select() call which has some limitations.
! 66:
! 67: ============ ========== ===============
! 68: OS Method Config Value
! 69: ============ ========== ===============
! 70: all select select
! 71: Unix poll poll
! 72: Linux 2.4+ rt-signals linux-rtsig
! 73: Linux 2.6+ epoll linux-sysepoll
! 74: Solaris /dev/poll solaris-devpoll
! 75: FreeBSD, ... kqueue freebsd-kqueue
! 76: ============ ========== ===============
! 77:
! 78:
! 79: For more information on this topic take a look at http://www.kegel.com/c10k.html
! 80:
! 81: Configuration
! 82: `````````````
! 83:
! 84: The event handler can be set by specifying the 'Config Value' from above
! 85: in the ``server.event-handler`` variable
! 86:
! 87: e.g.: ::
! 88:
! 89: server.event-handler = "linux-sysepoll"
! 90:
! 91: Network Handlers
! 92: ----------------
! 93:
! 94: The basic network interface for all platforms at the syscalls read() and
! 95: write(). Every modern OS provides its own syscall to help network servers
! 96: transfer files as fast as possible.
! 97:
! 98: If you want to send out a file from the webserver, it doesn't make any sense
! 99: to copy the file into the webserver just to write() it back into a socket
! 100: in the next step.
! 101:
! 102: sendfile() minimizes the work in the application and pushes a file directly
! 103: into the network card (ideally).
! 104:
! 105: lighttpd supports all major platform-specific calls:
! 106:
! 107: ========== ==========
! 108: OS Method
! 109: ========== ==========
! 110: all write
! 111: Unix writev
! 112: Linux 2.4+ sendfile
! 113: Linux 2.6+ sendfile64
! 114: Solaris sendfilev
! 115: FreeBSD sendfile
! 116: ========== ==========
! 117:
! 118: The best backend is selected at compile time. In case you want to use
! 119: another backend set: ::
! 120:
! 121: server.network-backend = "writev"
! 122:
! 123: You can find more information about network backend in:
! 124:
! 125: http://blog.lighttpd.net/articles/2005/11/11/optimizing-lighty-for-high-concurrent-large-file-downloads
! 126:
! 127:
! 128: Max Connections
! 129: ---------------
! 130:
! 131: As lighttpd is a single-threaded server, its main resource limit is the
! 132: number of file descriptors, which is set to 1024 by default (on most systems).
! 133:
! 134: If you are running a high-traffic site you might want to increase this limit
! 135: by setting ::
! 136:
! 137: server.max-fds = 2048
! 138:
! 139: This only works if lighttpd is started as root.
! 140:
! 141: Out-of-fd condition
! 142: -------------------
! 143:
! 144: Since file descriptors are used for TCP/IP sockets, files and directories,
! 145: a simple request for a PHP page might result in using 3 file descriptors:
! 146:
! 147: 1. the TCP/IP socket to the client
! 148: 2. the TCP/IP and Unix domain socket to the FastCGI process
! 149: 3. the filehandle to the file in the document root to check if it exists
! 150:
! 151: If lighttpd runs out of file descriptors, it will stop accepting new
! 152: connections for awhile to use the existing file descriptors to handle the
! 153: currently-running requests.
! 154:
! 155: If more than 90% of the file descriptors are used then the handling of new
! 156: connections is disabled. If it drops below 80% again new connections will
! 157: be accepted again.
! 158:
! 159: Under some circumstances you will see ::
! 160:
! 161: ... accept() failed: Too many open files
! 162:
! 163: in the error log. This tells you there were too many new requests at once
! 164: and lighttpd could not disable the incoming connections soon enough. The
! 165: connection was dropped and the client received an error message like 'connection
! 166: failed'. This is very rare and might only occur in test setups.
! 167:
! 168: Increasing the ``server.max-fds`` limit will reduce the probability of this
! 169: problem.
! 170:
! 171: stat() cache
! 172: ============
! 173:
! 174: A stat(2) can be expensive; caching it saves time and context switches.
! 175:
! 176: Instead of using stat() every time to check for the existence of a file
! 177: you can stat() it once and monitor the directory the file is in for
! 178: modifications. As long as the directory doesn't change, the files in it
! 179: must all still be the same.
! 180:
! 181: With the help of FAM or gamin you can use kernel events to assure that
! 182: your stat cache is up to date. ::
! 183:
! 184: server.stat-cache-engine = "fam" # either fam, simple or disabled
! 185:
! 186:
! 187: Platform-Specific Notes
! 188: =======================
! 189:
! 190: Linux
! 191: -----
! 192:
! 193: For Linux 2.4.x you should think about compiling lighttpd with the option
! 194: ``--disable-lfs`` to disable the support for files larger than 2GB. lighttpd will
! 195: fall back to the ``writev() + mmap()`` network calls which is ok, but not as
! 196: fast as possible but support files larger than 2GB.
! 197:
! 198: Disabling the TCP options reduces the overhead of each TCP packet and might
! 199: help to get the last few percent of performance out of the server. Be aware that
! 200: disabling these options most likely decreases performance for high-latency and lossy
! 201: links.
! 202:
! 203: - net.ipv4.tcp_sack = 0
! 204: - net.ipv4.tcp_timestamps = 0
! 205:
! 206: Increasing the TCP send and receive buffers will increase the performance a
! 207: lot if (and only if) you have a lot of large files to send.
! 208:
! 209: - net.ipv4.tcp_wmem = 4096 65536 524288
! 210: - net.core.wmem_max = 1048576
! 211:
! 212: If you have a lot of large file uploads, increasing the receive buffers will help.
! 213:
! 214: - net.ipv4.tcp_rmem = 4096 87380 524288
! 215: - net.core.rmem_max = 1048576
! 216:
! 217: Keep in mind that every TCP connection uses the configured amount of memory for socket
! 218: buffers. If you've got many connections this can quickly drain the available memory.
! 219:
! 220: See http://www.acc.umu.se/~maswan/linux-netperf.txt for more information on these parameters.
! 221:
! 222: FreeBSD
! 223: -------
! 224:
! 225: On FreeBSD you might gain some performance by enabling accept filters. Just
! 226: compile your kernel with: ::
! 227:
! 228: options ACCEPT_FILTER_HTTP
! 229:
! 230: For more ideas about tuning FreeBSD read: tuning(7)
! 231:
! 232: Reducing the recvspace should always be ok if the server only handles HTTP
! 233: requests without large uploads. Increasing the sendspace would reduce the
! 234: system load if you have a lot of large files to be sent, but keep in mind that
! 235: you have to provide the memory in the kernel for each connection. 1024 * 64KB
! 236: would mean 64MB of kernel RAM. Keep this in mind.
! 237:
! 238: - net.inet.tcp.recvspace = 4096
! 239:
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to performance.txt CVS log ![[TXT]](/icons/cvsweb/text.gif){kind=icon}
![[DIR]](/icons/cvsweb/dir.gif){kind=icon}
Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / lighttpd / doc / outdated