Annotation of embedaddon/lighttpd/doc/outdated/performance.txt, revision 1.1.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