Server max-workerDetails » History » Revision 15
Revision 14 (CCormier, 2021-07-30 03:01) → Revision 15/16 (gstrauss, 2021-12-10 06:20)
{{>toc}}
h2. server.max-worker option
@server.max-worker = 0@ - number of worker processes to spawn (default: 0)
*@server.max-worker @server.max-worker = 0@ is strongly recommended* on modern systems which employ @sendfile()@.
@server.max-worker = 0@ recommended, often uses using the least resources and is often being the most performant setting, 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 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 may make 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
@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. 4@
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 [[Server_max-workerDetails#Limitations|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@.
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 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 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 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.
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 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.
* [[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.