Major slow down...

When asked, a support team suggested that mysql_pconnect was what was causing really long loading times (front-end and back-end).

I didn’t get any responses asking on a thread what that was about, so did not do anything else with it.

MODx Revo does not use the mysql extension at all, so mysql_pconnect is irrelevant. And MODx specifically does not use the persistent connections via the PDO driver either.

I know it’s alot to ask but having read that a server needs to be configured for PDO is there anything in particular I should be configuring?

I now have a new server...

Quad Core Intel Xeon X3430 i5
2.4 GHz 8MB cache
2 x 300 GB SAS 15k rpm
Dell PowerEdge

Running centOS 5.5

Has suphp caused any issues for people before here? I hope someone can give me some ideas what kind of configuration I should have for PDO since I don’t really know.

Thanks for all your input, I’m sure others will find it helpful.

Hi Rosco,

Did you check the php manual?
http://php.net/manual/en/book.pdo.php

Nope, that will help when coming to coding. I meant for server config, is there anything I should enable or disable to make sure I get the best out the server for modx? Some clients are developers who develop in modx and might not understand the cache system and might effect the server until I notice issues.

If MODx doesn’t use the persistent connections via the PDO driver than maybe you have another CMS or app that’s wasting resources. Any chance you can get more information on who’s using those mysql_pconnect connections?

It was in the DBapi of evo I think but there was nothing calling on the evo sites on my server while the spikes happened so I doubt it’s related. There is no persistent cpu usage on the server, just when I mainly launch a rev site.

I just enabled suphp on the new server and it spikes to 60% cpu for 1 person viewing a page in Rev with snippets cached. The page does have the rev gallery on there with phpthumb but it’s only about 10 images which surely should be cached on the server? Funny thing is, I have thumbnails created by rev gallery called in via JS and a json feed and they appear to load in to the browser as if they are not cached, not sure if it’s cause the elements are created by JS or not and delayed loading? Maybe this is the spike cos they are regenerating each load?

According to the process manager it’s the index.php and connector.php that spike the most.

I took suphp off again as it’s just not playing ball with what I have put together and the cpu usage is lower by a great deal but I still get a spike of about 10%.

I will install the 2.6 tomorrow and see if that helps any.

Hello,

If you have more than one site on the server (you are using it for reselling basically) you want to be running phpsuexec, it provides better resource tracking (to help with abuse), better security and such.

Running PHP as PDO is faster if I recall correctly, and you could setup something like eaccelerator to help with the load. I suspect there is some tweaking you can do in MODx to help with the load issues. You might also look into this post: http://www.jasoncoward.com/technology/2010/10/simple-content-caching-with-getcache.html

It may give you a start in the right direction. Do you also have cPanel or another control panel system running on the server?

Yes I use cpanel on there. I would like to use suphp but it caused my dual core dedicated server with 4gb to hit 100% cpu and not it’s hitting about 60% with the new quad core one so I have disabled it.

It does seem a little odd. I don’t know what else to do to check what the issue could be. I still have to install the latest rev that was released the other day but I suspect it won’t be much different in terms of cpu usage.

phpthumb is very processor intensive, so I’d be willing to bet that is part of the problem. But you should also make sure you are running an opcode cache, like APC or eAccelerator so PHP does not have to load all of the classes for MODx/xPDO on every request. This will make the single biggest difference in your performance with regard to CPU and I/O utilization.