Docs MultiProcessor » History » Revision 1
SMP and lighty ==============
lighty is a single-threaded, single-process, event-based, non-blocking-io webserver. While
this is perfect for the performance it doesn't scale very well over CPUs. In most cases you
don't have to care about it as lighty will usually not be able to utilize the full CPU to
fill the network-pipe. All the heavy jobs are moved to external applications (see [wiki:Docs:ModFastCGI]).
But there are several cases where it makes sense to have several processes running and
since 1.4.x we have support to spawn several processes to listen on a single socket: ::
server.max-worker = 8
It has been shown that lighty scales mostly linearly on multicore, multi-processor boxes if you
set the number of workers equal to two times the number of cores if you are CPU bound (heavy rewrites, heavy proxying).
Usually you don't have to care about CPU-bound processing.
If you have to serve alot large files with a high concurrency you will notice the you will get IO-bound
to you hard-drive. lighty will spend most of the time waiting for the hard-drive to seek to the right
sector to send out the file.
As lighty will wait for the disk, all connections in the process will have to wait. Here you should create 4-16 worker
processes to be able to handle accepting new connections, sending out data and waiting for data in the same run.
See http://blog.lighttpd.net/articles/2005/11/11/optimizing-lighty-for-high-concurrent-large-file-downloads for more information.
By running 2 or more processes on the same socket you will have a better concurrency, but will have a few drawback that you have
to be aware of:
- [wiki:Docs:ModAccessLog mod_accesslog] might create broken accesslogs as the same file is opened twice and is NOT synchonized * [wiki:Docs:ModStatus mod_status] will have <n> separate counters, one set for each process * [wiki:Docs:ModRRDtool mod_rrdtool] will fails as it receives the same timestamp twice