Performance Tuning
Permalink 1 user found helpful
Hello all,
I've been doing some load testing exploration on Concrete5, and I wanted to see what others were getting with regard to performance. Specifically I'm wondering whether anyone is able to achieve more than 100 users whilst maintaining acceptable performance outside of super computers. Can anyone here tell me what sort of concurrent usage they're able to acheive with Concrete 5 on their servers with reasonable response times?
Box: RedHat - 6GB RAM - 4 Cores server. MySQL 5, PHP 5.3, Apache 2 + APC installed and running.
Ideal Scenario: 200+ users at once getting an average of < 2 second page load time.
Current Findings: 90~ users before 2 seconds is breached on average load.
Bottleneck: It seems that although the mysql slow queries isn't highlighting anything, the bottleneck does appear to be MySQL with a high (138%) CPU usage. Of particular note is the Handler_read_rnd_next, which is sky high, showing we're doing a lot of table scans on each request (poor indexing in C5?).
Concrete5 Findings: Emergency cache has absolutely no noticable effect on the response times I'm seeing, against basic cache settings. All using APC (which, by the way, gave us at least double the performance already to make even these stats possible!).
MySQL (5.0.77) Findings: Bizarrely query cache is quite unreliable, we were seeing 50-100 failed and timedout requests to our server once it was switched on through the lifetime of our load test.
Has anyone else investigated the performance of Concrete5?
I'd love to spark a discussion on performance tuning, and if anyone is interested in this discussion then I've attached one of my many load test reports with full cache.
Cheers,
Mark
I've been doing some load testing exploration on Concrete5, and I wanted to see what others were getting with regard to performance. Specifically I'm wondering whether anyone is able to achieve more than 100 users whilst maintaining acceptable performance outside of super computers. Can anyone here tell me what sort of concurrent usage they're able to acheive with Concrete 5 on their servers with reasonable response times?
Box: RedHat - 6GB RAM - 4 Cores server. MySQL 5, PHP 5.3, Apache 2 + APC installed and running.
Ideal Scenario: 200+ users at once getting an average of < 2 second page load time.
Current Findings: 90~ users before 2 seconds is breached on average load.
Bottleneck: It seems that although the mysql slow queries isn't highlighting anything, the bottleneck does appear to be MySQL with a high (138%) CPU usage. Of particular note is the Handler_read_rnd_next, which is sky high, showing we're doing a lot of table scans on each request (poor indexing in C5?).
Concrete5 Findings: Emergency cache has absolutely no noticable effect on the response times I'm seeing, against basic cache settings. All using APC (which, by the way, gave us at least double the performance already to make even these stats possible!).
MySQL (5.0.77) Findings: Bizarrely query cache is quite unreliable, we were seeing 50-100 failed and timedout requests to our server once it was switched on through the lifetime of our load test.
Has anyone else investigated the performance of Concrete5?
I'd love to spark a discussion on performance tuning, and if anyone is interested in this discussion then I've attached one of my many load test reports with full cache.
Cheers,
Mark
how about turn off the autonav block? i mean do not use autonav block in your page. i get 30% improvment with this. just curios :)
You should have full page caching(for blocks that support it) enabled. If you made any custom blocks make sure they are written to use caching.
Don't write autonav into the theme. Either do what @fastcrash did and make it html or write a new more specific autonav block(just do a page list, with the nav helper).
Make sure you don't have any curl(rss etc) blocks that aren't caching per hour at least.
You're comment about emergency cache feels like there are some custom blocks(or page type theme code) that is heavy.
I've seen custom sites with a lot of code in the page type theme view grinding down a site.
The biggest I've seen with slow sites is blocks that do large amounts of queries and don't cache. Especially custom ones. Stuff like getting ever page in an array and then search it. One bad block/addon can kill a whole site.
If you're getting that MySQL you aren't caching enough. C5 needs to be cached a lot for moderate traffic no matter what anyone tries to tell you that's really the only solution. Cache cache cache.
Also, you should might want to use memcached for a site that site.
Don't write autonav into the theme. Either do what @fastcrash did and make it html or write a new more specific autonav block(just do a page list, with the nav helper).
Make sure you don't have any curl(rss etc) blocks that aren't caching per hour at least.
You're comment about emergency cache feels like there are some custom blocks(or page type theme code) that is heavy.
I've seen custom sites with a lot of code in the page type theme view grinding down a site.
The biggest I've seen with slow sites is blocks that do large amounts of queries and don't cache. Especially custom ones. Stuff like getting ever page in an array and then search it. One bad block/addon can kill a whole site.
If you're getting that MySQL you aren't caching enough. C5 needs to be cached a lot for moderate traffic no matter what anyone tries to tell you that's really the only solution. Cache cache cache.
Also, you should might want to use memcached for a site that site.
Wow! Who knew that such a simple change could make such a difference in site performance. I've got a new site I just launched on 5.4.2.2. I changed the auto-nav for the header navigation from being hard-coded into the theme file like this:
To creating a Scrapbook for the Global Nav, adding the auto-nav block to the Scrapbook, and then putting THIS into my theme file:
Combined with turning on the full page caching and being sure that any custom blocks I created have the blockCaching variables set has made a noticeable improvement in site performance.
Thanks, guys! Big help!
- John
<?php $navBT = BlockType::getByHandle('autonav'); $navBT->controller->displayPages = 'top'; $navBT->controller->orderBy = 'display_asc'; $navBT->controller->displaySubPages = 'all'; $navBT->controller->displaySubPageLevels = 'all'; $navBT->render('view'); ?>
To creating a Scrapbook for the Global Nav, adding the auto-nav block to the Scrapbook, and then putting THIS into my theme file:
<?php Block::getByName("name_of_scrapbook_block_goes_here")->display(); ?>
Combined with turning on the full page caching and being sure that any custom blocks I created have the blockCaching variables set has made a noticeable improvement in site performance.
Thanks, guys! Big help!
- John
Top tip! thanks arrestingdevelopment.
If you want to do the same using Stacks see the code below.. it's subtly different
If you want to do the same using Stacks see the code below.. it's subtly different
<nav>
<?php
$ga = new GlobalArea('Main AutoNav');
$ga->display();
//Block::getByName("Main AutoNav")->display();
?>
<?php
/*$bt = BlockType::getByHandle('autonav');
$bt->controller->displayPages = 'top';
$bt->controller->orderBy = 'display_asc';
$bt->controller->displaySubPages = 'all';
$bt->controller->displaySubPageLevels = 'custom';
$bt->controller->displaySubPageLevelsNum = 1;
$bt->render('templates/slate_main_nav');
*/Viewing 15 lines of 16 lines. View entire code block.
