Server max-workerDetails » History » Revision 14
Revision 13 (gstrauss, 2021-07-30 00:03) → Revision 14/16 (CCormier, 2021-07-30 03:01)
{{>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
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 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, lighttpd lightpd may spend most of its the time waiting for the disk to seek to the right sector in order to read and send files. As lighttpd 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 raise 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 is no way to choose which lighttpd worker process to which to connect to make a request. Most lighttpd modules operate well with in multiple lighttpd workers. However, some modules will not operate as expected with multiple lighttpd workers since each lighttpd worker process 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 the connection limit will be applied per process, so the 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 the correct status since the download might be occurring from another lighttpd worker process.