Docs

SMP and lighty

Overview
lighty is a single-threaded, single-process, event-based, non-blocking-IO web server. While
this is perfect for the performance it doesn't scale very well over !"s. In most cases yo#
don't have to care abo#t it as lighty will #s#ally not be able to #tili$e the f#ll !" to
fill the network-pipe. %ll the heavy &obs are moved to e'ternal applications (see mod)fastcgi*.
+#t there are several cases where it makes sense to have several processes r#nning and
since ,.-.' we have s#pport to spawn several processes to listen on a single socket.
Read this -> server.max-workers
server.max-worker = 8 # this may break many things
CPU-Bound
It has been shown that lighty scales mostly linearly on m#lticore, m#lti-processor bo'es if yo#
set the n#mber of workers e/#al to two times the n#mber of cores if yo# are !" bo#nd (heavy rewrites,
heavy pro'ying*.
"s#ally yo# don't have to care abo#t !"-bo#nd processing.
IO-Bound
If yo# have to serve a lot of large files with a high conc#rrency, yo# will notice that yo# will be IO-bo#nd
to yo#r hard-drive. lighty will spend most of the time waiting for the hard-drive to seek to the right
sector to send o#t the file.
%s lighty will wait for the disk, all connections in the process will have to wait. In order to process more
re/#ests conc#rrently, yo# sho#ld create - to ,0 work processes. 1his will allow yo# to both send and wait
for data at the same time.
2ee http.33blog.lighttpd.net3articles345563,,3,,3optimi$ing-lighty-for-high-conc#rrent-large-file-
downloads for more information.
NFS
"sing 782 is basically the same as being IO-bo#nd. most of the time is spent waiting on the remote system
to deliver the content or to stat(*3open(* a file. In those cases yo# want to incl#de the n#mber of workers
to spread the probability over several processes.
server.max-worker = 8 # this may break many things
% val#e between 9 and ,0 sho#ld handle most set#ps.
Problems
+y r#nning 4 or more processes on the same socket yo# will have a better conc#rrency, b#t will have a few
drawbacks that yo# have to be aware of.
mod)accesslog might create broken access logs, as the same file is opened twice and is 7O1
synchroni$ed.
mod)stat#s will have :n; separate co#nters, one set for each process.
mod)rrdtool will fail as it receives the same timestamp twice.
mod)#ploadprogress will not show correct stat#s.