1
========================
2
Performance Improvements
3
========================
10
:Date: $Date: 2004/11/03 22:26:05 $
11
:Revision: $Revision: 1.3 $
14
handling performance issues in lighttpd
17
:keywords: lighttpd, performance
19
.. contents:: Table of Contents
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.
34
Disabling keep-alive might help your server if you suffer from a large
35
number of open file descriptors.
37
The defaults for the server are: ::
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
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.
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. ::
50
server.max-keep-alive-requests = 4
51
server.max-keep-alive-idle = 4
53
would release the connections earlier and would free file descriptors without a
54
detrimental performance loss.
56
Disabling keep-alive completely is the last resort if you are still short on file descriptors: ::
58
server.max-keep-alive-requests = 0
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.
67
============ ========== ===============
68
OS Method Config Value
69
============ ========== ===============
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
============ ========== ===============
79
For more information on this topic take a look at http://www.kegel.com/c10k.html
84
The event handler can be set by specifying the 'Config Value' from above
85
in the ``server.event-handler`` variable
89
server.event-handler = "linux-sysepoll"
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.
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
102
sendfile() minimizes the work in the application and pushes a file directly
103
into the network card (ideally).
105
lighttpd supports all major platform-specific calls:
107
========== ==========
109
========== ==========
113
Linux 2.6+ sendfile64
116
========== ==========
118
The best backend is selected at compile time. In case you want to use
119
another backend set: ::
121
server.network-backend = "writev"
123
You can find more information about network backend in:
125
http://blog.lighttpd.net/articles/2005/11/11/optimizing-lighty-for-high-concurrent-large-file-downloads
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).
134
If you are running a high-traffic site you might want to increase this limit
137
server.max-fds = 2048
139
This only works if lighttpd is started as root.
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:
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
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.
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
159
Under some circumstances you will see ::
161
... accept() failed: Too many open files
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.
168
Increasing the ``server.max-fds`` limit will reduce the probability of this
174
A stat(2) can be expensive; caching it saves time and context switches.
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.
181
With the help of FAM or gamin you can use kernel events to assure that
182
your stat cache is up to date. ::
184
server.stat-cache-engine = "fam" # either fam, simple or disabled
187
Platform-Specific Notes
188
=======================
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.
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
203
- net.ipv4.tcp_sack = 0
204
- net.ipv4.tcp_timestamps = 0
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.
209
- net.ipv4.tcp_wmem = 4096 65536 524288
210
- net.core.wmem_max = 1048576
212
If you have a lot of large file uploads, increasing the receive buffers will help.
214
- net.ipv4.tcp_rmem = 4096 87380 524288
215
- net.core.rmem_max = 1048576
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.
220
See http://www.acc.umu.se/~maswan/linux-netperf.txt for more information on these parameters.
225
On FreeBSD you might gain some performance by enabling accept filters. Just
226
compile your kernel with: ::
228
options ACCEPT_FILTER_HTTP
230
For more ideas about tuning FreeBSD read: tuning(7)
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.
238
- net.inet.tcp.recvspace = 4096
added
removed
doc/performance.txt
