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, often using the least resources and being the most performant, except in specific uses cases.

Overview¶

lighty 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. Bottleneck are usually the (external) heavyweight backends to which lighttpd connects via modules such as mod_fastcgi. Still, there are several cases where it makes sense to have several lighttpd worker processes running, but please be aware of some limitations when using server.max-worker.
server.max-worker = 4

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, lightpd may spend most of the time waiting for the disk to seek to the right sector in order to read and send files. As lightpd waits for the disk, all connections in the process have to wait. In order to process more requests concurrently, you should create 4 to 16 lighttpd worker processes. This is discussed further in Optimizing Lighty for High-concurrent, Large-file Downloads

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 want to include 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 in multiple lighttpd workers. However, some modules will not operate as expected with multiple lighttpd workers since each lighttpd worker processes 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 connection limit will be applied per process, so 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 correct status since the download might be occurring from another lighttpd worker process.