Does MODx's PHP use thread safe libraries? Using httpd worker (MPM)

per my prev. post, my server is not holding up to heavy traffic. I’ve been reading about running Apache v2 using the "worker" option so we can fork apache processes and hopefully get more out of our hardware, but I understand PHP requires a couple things for that to happen: it’s gotta be compiled to run in cgi or fast-cgi mode (which it’s not currently on my box), and more importantly, moving over to MPM will cause any existing PHP code will have problems if it’s not using thread safe libraries. See http://ivan.gudangbaca.com/installing_apache2_and_php5_using_mod_fcgid

So the big question is: does MODx 0.9.6.3 use thread safe libraries?

Thread safety really has nothing to do with MODx and everything to do with PHP, the web server, the OS, etc. Read Jason Lester’s comment at the bottom of this page here:

http://neosmart.net/blog/2008/dont-believe-the-lies-php-isnt-thread-safe-yet/#comment-392079

Might also run through this perspective:

http://brian.moonspot.net/2008/02/13/apache-worker-and-php/

As for any real advice on these topics, I’ll have to defer to a real server administrator. I know we get quite a lot of traffic on our single massive box that is hosting modxcms.com (and a handful of other sites with PHP/MySQL-based applications, yes, mostly MODx) and we are running both an Apache 1.3 and an Apache 2 instance using server API, both prefork, with the same compile of PHP (thread safety disabled), and we’re running pretty smoothly, save for the occasional traffic peaks (usually a lame DDOS attempt) causing us to run out of db connections.

Ultimately though, it depends on the requests per second you need to be able to handle, i.e. if all of your traffic is concentrated into a small amount of time, your going to need more than a single box to handle it, and that means a lot of additional issues and constraints. If this traffic is spread out and you are having problems, I would venture to say it may be application specific (maybe a slow query? have you tried turning on the mysql slow_query_log feature for instance?).

I’m gonna investigate the slow query log and see if I can get fast cgi going. We’re getting sustained hits over time... 40+ requests per second for a couple hours. Peaks at over 100 requests per second.

I’d love to hear from someone running MODx on a MPM (threaded httpd = worker) configuration. Anyone done this?

Quote from: Everett at May 08, 2009, 05:09 PM

I’m gonna investigate the slow query log and see if I can get fast cgi going. We’re getting sustained hits over time... 40+ requests per second for a couple hours. Peaks at over 100 requests per second.

I’d love to hear from someone running MODx on a MPM (threaded httpd = worker) configuration. Anyone done this?

In my experience, about 50 simultaneous users is all a single web server with a PHP application like MODx is going to be able to handle gracefully (assuming you are caching most everything you can), even with op-code caching. After that, you need load-balancing and potentially, a lot more caching functionality (memcached?), something we’re building into Revolution, but would not serve you well in older releases.

That’s a useful metric and consistent with what we’re experiencing on the box... things start browning out around 50 hits/sec.

Yeah, the question is if and when do we get a dedicated db server... then at least we can optimize the webserver for io operations and the db server for disk reads.... dot dot dot <insert really intelligent things here>

This is definitely a learning experience.

Quote from: Everett at May 08, 2009, 05:58 PM

Yeah, the question is if and when do we get a dedicated db server... then at least we can optimize the webserver for io operations and the db server for disk reads.... dot dot dot <insert really intelligent things here>

This is definitely a learning experience.

Beware of thinking that having a dedicated database server is going to help because as soon as you separate the database server from the web server, you have added CPU load to the web server for each request as it must now open a socket to connect to/communicate with the remote database. This added load and latency will pretty much make up for the gain you thought you would get by offloading the database server.

This added load and latency will pretty much make up for the gain you thought you would get

Ah... such an optimist.

Actually, since it’s a media heavy site (lots of videos), I’m wondering if we might get better results out of a streaming server. We gotta do something though... get a cluster together or something...

Quote from: Everett at May 08, 2009, 05:58 PM

That’s a useful metric and consistent with what we’re experiencing on the box... things start browning out around 50 hits/sec.

<info type=background>I am the guy that does the sysadmin duties for modxcms.com (and a bunch of other sites). Jason is definitely the guru when it comes to the modx codebase, but I know a thing or two about server infrastructure</info>

Before you run off and start firing up additional database servers and whatnot, the very first thing I’d recommend is to spend some time profiling your app and see exactly where the bottlenecks are. Are you running out of CPU? RAM? Swap space? Or do things take a long time for some other reason (a project I was recently involved in increased their app throughput but several magnitudes when they realized that a bad hostname was in a DB config, and thus there’s was a DNS timeout waiting period for every DB request).

My point is that before you do anything, identify the biggest problem and work on that. Otherwise, you may just end up doing stuff that masks that problem, and it’ll come back and bite you in the ass much harder way down the road.

vbrilon, YES!!! I’d LOVE to know what is going on! I’m not a good enough sysadmin to figure it out... I’m not really sure where it’s bottle-necking... I’m just twiddling with some of more common knobs, but I’m not even sure how much effect they’re having -- we saw some better performance of MySQL today after I used the mysqltune.pl script... but that’s not exactly empirical testing. If you are available for contract work, please message me -- we’ll hire you immediately to sniff around for a few hours. I don’t think it’s that hard to see what’s going on, but it requires skills that I just don’t have.

You’re absolutely right: it’s ridiculous to recommend to the investors that we buy more hardware when we’re not sure what’s going on yet. More hardware won’t make us any smarter.

If you can give me pointers as far as utilities to use and/or how to read the reports I’m seeing, that would be a huge help. So far I’ve been initiated into the "w" command (ie. uptime), and I’ve looked at top and vmstat and sar (although I couldn’t spot a trainwreck if I saw it... thus my problem).

Hi Everett,

I am working with Jason to diagnose any potential bottlenecks in modx and how they could be fixed in the next release. He and I just worked together on a *large* scale project that helped us identify a bunch of places where modx (and the surrounding infra) could be improved. Unfortunately that’s doesn’t help you with the current project you have of course

Let’s talk offline and I’d be glad to give any pointers in your specific case, and if there’s some specific things I can help with I might be able to help with some consulting work (depending on the time commitment needed). I’ll PM you my contact info and I suggest that whatever we can diagnose to help you improve your site’s performance, we can write up and give back to the modx community. Sound good?