High server load

Hi
I have a problem with excessive load on my server and your test seems to hold the key to where it occurs.

After everything has finished downloading, CPU utilization seem to remain way up near 100%.

[attachment=87]

Any suggestions on how I can get to the source of the problem?

Thanks
Carl

The CPU load on the client system shouldn’t have anything to do with the load on your server. From the looks of where the client CPU spikes it looks like there is some code in an onLoad handler that is pretty expensive to execute. You can drill into what is causing it by using dynaTrace Ajax Edition (and running a test against one of the dynaTrace test locations to get a capture file).

It would help to see the top of the waterfall but from the look of the graphs it looks like it took the server ~2.5 seconds to respond with the base page. If I were a betting man I’d say your load problem is caused by the code on the server side that generates the base page. If your site is built on top of one of the common CMS systems (drupal, wordpress, Joomla) you should look into things like server-side page caching and other options for tuning their performance (if you share what the CMS is I can point you to sites that can help). Most of them completely suck if you just use their out-of-the-box configuration.

-Pat

A quick peek at the page source reveals it’s Joomla 1.5. There’s a whole site dedicated to tuning the performance on a Joomla install: http://www.joomlaperformance.com/

You should probably just start by enabling Joomla’s own caching mechanism: http://kb.siteground.com/article/How_to_enable_cache_in_Joomla_15.html

Thanks Pat

I’m using Joomla and before you suggest joomlaperformance :slight_smile: my host, Rochen (the official Joomla hosts) pointed out that some of their advice is incorrect.

The test is at http://www.webpagetest.org/result/110224_Z0_1YQ9/

Surely the CPU ulitization shouldn’t stay way up there?

regards
Carl

You probably have 2 different problems going on.

The CPU utilization problem you see in the test results is happening on your uesr’s machines, not your servers. That’s going to be a javascript problem with something on your page (if I get a few minutes I’ll run a test with dynaTrace Ajax edition which will identify the culprit pretty quickly).

Your high server load is because of joomla itself and the processing it is doing to generate the pages and shows up in the first byte time of the page load (5.8 seconds is ludicrously long). I haven’t tuned a joomla site before but more often than not the biggest wins for that jind of system come from disabling modules that aren’t critical and enabling whatever server-side page caching is available. It looks like Joomla 1.5 has a facility for at least doing page caching which will help significantly (for your unauthenticated users). It SHOULD reduce the first byte time to well under a second (and significantly reduce the amount of work the server is doing).

-Pat

Thanks Pat, I really appreciate your pointers and would be most grateful for anything further.

I’ve tried using dynaTrace Ajax edition as you suggested and, impressive as it is, it’s probably too complex for a novice like me!

Regarding page caching, on Joomla 1.5 this seems to create more problems than it solves. Let’s hope Joomla 1.6 fares better.

Kind regards
Carl

Looking at the dynaTrace results, it looks like you have quite a few javascript modules that are attaching to onload to do their work. jtabs looks like it’s the most expensive to initialize but there’s also Fx Slide, mootools tooltips, and a couple of others. Replacing them with lighter implementations (or even css-based code) would help with the user-CPU load.

If you can’t do any tuning on joomla without breaking the site your only real option is to make sure the mysql database it connects to is crazy-fast because it’s usually a ton of queries to generate the page and the time for the queries is what backs things up. The databases are often the weak point for a shared hosting provider as well which probably isn’t helping. If you can’t enable the page caching, using a query cache of some kind might help (looks like there might only be one available and it’s not built-in).

-Pat