Commenting on Monitoring Per-Process Memory Usage with Munin
If you've got an OpenID, you should use it to log in below. You'll be automatically registered, no fuss. And that means you won't have to wait for your comment to be moderated. You'll also be able to edit your comments.
Replying to:
-
I've experimented with both setups.
I found:
- Fcgid memory with mpm worker is highly configurable and predictable, and thus scalable.
The problem with fastcgi is its way of forking large amounts of requests.
This was very unreliable:
once i jammed up the concurrency on requests, there was a fair amount of requests not being served.
Also i saw a large performance drop when i was adding a session cookie for my app (and thus increasing mysql queries etc) with my siege benchmark.
Also theres a problem with running an opcode cache like APC, which memory is not shared on processes, thus the APC cache will be seperated for each thread, and quickly fill up.
This seems to be the way for xcache and eaccelerator in fastcgi aswell..
I ended up reverting back to apache prefork and mod_php with Varnish as a front end cache. This means i am using a fair amount of RAM,
and when demand increases, my server will start swapping, and on a constricted linode with already added RAM, i will definetly add even more RAM in the future.
However having 100% of requests served is more important for me, and apache prefork can be tuned to scale.
Ofcourse when the sites get hammered, i won't be able to serve the requests, so i have to keep adding ram + changing Apache config, but its still more reliable and recourse friendly than Fastcgi in my opinion
Milan
Sat, 16/1/10 – 5:24am
Reply