Server max-workerDetails » History » Revision 12
Revision 11 (gstrauss, 2021-07-17 02:02) → Revision 12/16 (gstrauss, 2021-07-17 02:05)
{{>toc}}
h2. 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.
h2. 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 [[lighttpd:Docs_ModFastCGI|mod_fastcgi]]. Still, there are several cases where it makes sense to have several lighttpd worker processes running, but please be aware of some [[Server_max-workerDetails#Limitations|limitations when using server.max-worker]].
@server.max-worker = 4@
h2. 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.
h2. 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":http://blog.lighttpd.net/articles/2005/11/11/optimizing-lighty-for-high-concurrent-large-file-downloads
h2. 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.
h2. Limitations
lighttpd workers are independent, other than sharing listening sockets. There sockets and 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.
* [[lighttpd:Docs_ModStatus|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.
* [[lighttpd:Docs_ModEvasive|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).
* [[lighttpd:Docs_ModRRDTool|mod_rrdtool]] will fail since rrdtool will receive the same timestamp twice.
* [[lighttpd:Docs_ModUploadProgress|mod_uploadprogress]] might not show correct status since the download might be occurring from another lighttpd worker process.
Note that [[lighttpd:Docs_ModStatus|mod_status]] does not provide aggregate statistics when @server.max-worker@ > 1. There are also limitations with some other, less frequently used modules, discussed in [[Docs_MultiProcessor|specific uses cases for multiple lighttpd workers]]