Lighttpd

• Table of contents
• server.max-worker option
• Overview
• CPU-Bound
• I/O-Bound
• NFS
• Limitations

server.max-worker option¶

server.max-worker = 0 - number of worker processes to spawn (default: 0)

server.max-worker = 0 is strongly recommended on modern systems which employ sendfile().
server.max-worker = 0 often uses the least resources and is often the most performant setting, except in specific uses cases.

Overview¶

lighttpd is a single-threaded, single-process, event-based, non-blocking-I/O web server. In many usage scenarios, a single lighttpd process is more than sufficient to handle requests. Bottlenecks are usually the (external) heavyweight backends to which lighttpd connects via modules such as mod_fastcgi. Still, there are several cases where it may make sense to have several lighttpd worker processes running, but please be aware of some limitations when using server.max-worker.

server.max-worker = 0 is strongly recommended unless changing server.max-worker makes a measurable performance difference for your specific usage scenario. Please test and measure on your own system.

This strongly worded recommendation is repeated since changing server.max-worker is often not necessary or helpful, but changing server.max-worker does introduce some limitations when using server.max-worker. In the spirit of "the principle of least surprise", please do not blindly change server.max-worker. If there is a problem you think changing server.max-worker might help, then it is prudent to test and measure the impact of changing server.max-worker.

CPU-Bound¶

If lighttpd is CPU-bound, perhaps due to a surge in socket connections and TLS negotiation, try setting server.max-worker = 4 or to the number of cores in the system.

I/O-Bound¶

When serving many large files with high concurrency and using a slow spinning disk (not an SSD) on a system without sufficient memory for filesystem caching, the system performance may be limited by I/O waits to the hard drive. In this case, lighttpd may spend most of its time waiting for the disk to seek to the right sector in order to read and send files. As lighttpd waits for the disk, all connections in the process have to wait. In order to process more requests concurrently, you might create 4 to 16 lighttpd worker processes.

NFS¶

Using NFS is basically the same as being I/O-bound: most of the time is spent waiting on the remote system to deliver the content or to stat()/open() a file.
In those cases you may want to raise the number of workers to spread the waits across several processes: server.max-worker = 8
A value between 8 and 16 should handle most setups.

Limitations¶

lighttpd workers are independent, other than sharing listening sockets. There is no way to choose which lighttpd worker process to which to connect to make a request. Most lighttpd modules operate well with multiple lighttpd workers. However, some modules will not operate as expected since each lighttpd worker process is independent, and does not share information with other lighttpd workers.

• mod_status will have <n> separate counters, one set for each process.
  Retrieving statistics is valid for the single lighttpd worker process that processes the status request, but statistics among all processes are not aggregated.
• mod_evasive may not work as expected since the connection limit will be applied per process, so the connection limit is actually (limit * number of lighttpd workers).
• mod_rrdtool will fail since rrdtool will receive the same timestamp twice.
• mod_uploadprogress might not show the correct status since the download might be occurring from another lighttpd worker process.