3 ms·
The use case is handling 50 concurrent connections ...
by mandric 18y ago
The use case is handling 50 concurrent connections ...
- SwellJoe 18y agoYou could also make each connection finish faster. I'm not suggesting you don't need 50 Apache processes for what you're doing. Just that you might find other way to serve the same userbase, if having 50 processes is a problem for some reason. mod_fcgid is more efficient for some classes of problem than mod_php...though not "faster" by a huge amount, it does require a lot fewer resources including having a lower process count for the same workload. Switching to mod_fcgid for all PHP on your site would mean you could remove mod_php from your Apache process, which is a big memory savings. eaccelerator can speed up some PHP applications. Profiling your code and removing the bottlenecks would be another good option. Since PHP is historically not thread safe you probably can't switch to a lower process Apache concurrency model (though there seems to be the possibility to use a limited subset of PHP 5 in such an environment, I'd be hesitant to do so in production, and you'll spend an awful lot of time digging up the facts on whether the modules you're using are thread safe). While I've seen suggestions of running a lighter webserver for assets that don't need the full execution environment of Apache...I would instead suggest you make a lean VirtualHost section just for those assets. Yes, it will still be spawning Apache processes, but Apache can share a huge amount of resources with all the other Apache processes. It's hard to see in "top" and the like, because shared resource usage isn't very clearly dilineated, but overall resource usage of a single Apache installation (with many processes) is probably going to be less than that of Apache plus a second web server, particularly if you've already cleaned up your Apache and gotten rid of all of the unnecessary modules. Only real data can tell us for sure, but I'd be suspicious of any advice that seems certain that adding another webserver to the mix is the best solution, without having data about your particular deployment.
- mandric 18y ago"You could also make each connection finish faster." Well my I have set KeepAlive Off. Not sure what else I can do to close connections. "remove mod_php from your Apache process, which is a big memory savings." That's what I'm shooting for but php under mod_fcgid has proven to be unstable, or I have to dig deeper to find the problems. "Profiling your code and removing the bottlenecks would be another good option." I've never done this on php any hints would be appreciated. But I am not too crazy about digging through random client code, I'd rather be able to handle the average inefficiency. "I would instead suggest you make a lean VirtualHost section just for those assets." Well I'm not sure how to make a lean virtualhost. I thought I could only remove modules from the main apache config, not a vhost. So I don't understand how I can make a vhost leaner than the parent apache. I should look into this further, but any advice is appreciated.
- SwellJoe 18y agoWell I'm not sure how to make a lean virtualhost. I thought I could only remove modules from the main apache config, not a vhost. I mean, "with no interpreters, SSI, rewrites, proxies, etc." The process will always contain all the same modules. But, the execution path can be very different.
- foobaz 18y agoA lean VirtualHost won't help. All the Apache processes can serve a request for any VirtualHost sections. Eventually enough processes do a mod_php request and allocate a bunch of unshared memory. Running a second server (even another prefork Apache) keeps the two sets of processes separated.
- SwellJoe 18y agoI've clarified what I meant by that in my response. I didn't mean to imply that the Apache process could be made smaller for specific VirtualHosts.