I’ve been using lighttpd for various projects with great results. A few days ago I had to optimize a server that was running lighttpd but has degraded its performance during the past weeks. I was able to see quite easily that the problem was IO bound as the number of files was growing very fast, while the folders were not arranged very well. Lighttpd was starting to slowdown while blocked on disk IO requests. We needed a quick solution to buy us some time while we improve the backend files layout.
Having used nginx for some time now on some bigger sites that this one, my first thought for a quick solution was to increase the number of lighttpd workers as I have done with nginx. Lighttpd supports this, but looking at their documentation page we can see: “DO NOT USE THIS OPTION IF YOU DON’T UNDERSTAND WHAT IT DOES DO NOT REPORT ERRORS OR BUGS IF YOU DID NOT TEST WITHOUT THIS OPTION SET THIS OPTION MOST LIKELY WILL NOT BOOST YOUR PERFORMANCE, ITS MOST LIKELY YOUR BACKEND” wow… talk about a warning ;-)
Increasing server.max-worker to the number of cores we had on the server (8):
has helped, and this should give us enough time until we will implement a better solution.
Here are the problems this will cause:
“By running 2 or more processes on the same socket you will have a better concurrency, but will have a few drawbacks that you have to be aware of:
- mod_accesslog might create broken access logs, as the same file is opened twice and is NOT synchronized.
- mod_status will have
our logs seem to be fine after this (but still I expect that we are loosing some hits, but it is impossible to see that), but we are no longer able to use mod_status and the cacti graphs we were creating, because each status call will get the result from another worker, and since they keep individual (not global) counters this becomes useless. Why would anyone need separate counters per process? you don’t even know what process you get the counters in the first place, as you will hit randomly one of them. The stats are gone, and we just disabled mod_status as it was useless now.
I can’t believe this is not working as expected and we will migrate this site to nginx asap; lighttpd developers should look at nginx that has a great support for more workers and even allow easy cpu_affinity setting for each worker if you would want to do that. As you can see I never compared this with apache, but with nginx, that is imo the direct competitor for lighttpd. Anyway… if you are going to use more workers with lighttpd, be aware of the limitations… as they describe it very well on their own pages: “DO NOT REPORT ERRORS OR BUGS”! and I would add: go choose a better software;-).