Why is first pageload always so slow?
Permalink 1 user found helpful
Hi fellow c5'ers
During the last couple days I've been wondering why a concrete5 site I have as a test install, and therefore not heavily visited, is always slow on first pageload:
http://c5.webmatros.dk/
I have caching enabled, and it seems to do its work, but not on the first pageload, even though I've specified in the prefs that it should keep the cache until manually emptied...
I have a Textpattern based site on the same server, with no caching enabled, and it loads fast on every load, also the initial one:
http://www.cityhelse.dk/
Please note, that if several people from the forum load the page in question, the site may not exhibit the slowness, since it only happens when the site's been idle for a while. My guess is around 15 mins or so... then it takes it a while to "wake up" on the first pageload...
During the last couple days I've been wondering why a concrete5 site I have as a test install, and therefore not heavily visited, is always slow on first pageload:
http://c5.webmatros.dk/
I have caching enabled, and it seems to do its work, but not on the first pageload, even though I've specified in the prefs that it should keep the cache until manually emptied...
I have a Textpattern based site on the same server, with no caching enabled, and it loads fast on every load, also the initial one:
http://www.cityhelse.dk/
Please note, that if several people from the forum load the page in question, the site may not exhibit the slowness, since it only happens when the site's been idle for a while. My guess is around 15 mins or so... then it takes it a while to "wake up" on the first pageload...
Have you tried following the steps in this how-to yet to see if it gets better?http://www.concrete5.org/documentation/how-tos/developers/five-easy...
Hi.
I have som sites at a host that is super slow. (shared hosting).
I have som others with another host that works very well. (Also shared hosting).
It would be interesting to know what causes this behaviour.
It's the same with my slow sites. Takes forever first time. Then it's a bit faster when it's woke up.
The slow ones I have moved the database to new servers at the host. But it does not help.
The host (Loopia) blames Concrete5. But I have a Wordpress on same server that also is slow (a little faster than C5)
Regardfs
Olle
I have som sites at a host that is super slow. (shared hosting).
I have som others with another host that works very well. (Also shared hosting).
It would be interesting to know what causes this behaviour.
It's the same with my slow sites. Takes forever first time. Then it's a bit faster when it's woke up.
The slow ones I have moved the database to new servers at the host. But it does not help.
The host (Loopia) blames Concrete5. But I have a Wordpress on same server that also is slow (a little faster than C5)
Regardfs
Olle
Judging from your words it is most likely that your host has some crappy servers.
I suggest you try the points in the how-to and if that doesn't work, test one of those sites with your other host. if the speed improves by switching hosts then pull everything away from that host or show them proof so they can fix it.
I suggest you try the points in the how-to and if that doesn't work, test one of those sites with your other host. if the speed improves by switching hosts then pull everything away from that host or show them proof so they can fix it.
I've now swithed theme, from the standard one that comes with c5 (and yes the slidehow is rather heavy) to a pretty minimal theme. But the site still exhibits the same problem. First pageload after site has been idle for a while (10-15 mins or so) is 10-15 secs...
This is not about the host being slow, since subsequent pages are loaded at a decent speed. It seems more like there are some slow queries or that the cache gets flushed every 10 mins, no matter what the cache flush interval is set to in the prefs...
PS: I now about the optimization tips and have done them before on live c5 sites. This is a demo install meant for prospective clients to play with. First pageload should not be that slow... Makes for a terrible landing page when running AdWords for example...
This is not about the host being slow, since subsequent pages are loaded at a decent speed. It seems more like there are some slow queries or that the cache gets flushed every 10 mins, no matter what the cache flush interval is set to in the prefs...
PS: I now about the optimization tips and have done them before on live c5 sites. This is a demo install meant for prospective clients to play with. First pageload should not be that slow... Makes for a terrible landing page when running AdWords for example...
Hi
Yes, that is what I had to do with one of the sites.
I did put up a exact copy at another host that runs fast.
The problem host admitted that it was a problem at their end (after many emails).
Could be good to know what is causing this delay for the first page. So we know what to watch out for. Or what to tell problem hosts.
Regards
Olle
Yes, that is what I had to do with one of the sites.
I did put up a exact copy at another host that runs fast.
The problem host admitted that it was a problem at their end (after many emails).
Could be good to know what is causing this delay for the first page. So we know what to watch out for. Or what to tell problem hosts.
Regards
Olle
I was curious so I had a look, 9.42secs for me.
Strangely the longest thing to load was the typography.ccs file at 7.44secs and everything else seemed fairly normal for C5.
I would suggest you try pauls suggestion and check out the emergency caching and see if it helps at all.
I also had a look at the Home page for concrete5.org that was a slightly faster 8.49secs but they have loads of stuff loading and I am guessing I am lots of hops away from them.
I have a site that loads a gallery in 23secs, thank god for caching or the whole site would have been in the bin.
Strangely the longest thing to load was the typography.ccs file at 7.44secs and everything else seemed fairly normal for C5.
I would suggest you try pauls suggestion and check out the emergency caching and see if it helps at all.
I also had a look at the Home page for concrete5.org that was a slightly faster 8.49secs but they have loads of stuff loading and I am guessing I am lots of hops away from them.
I have a site that loads a gallery in 23secs, thank god for caching or the whole site would have been in the bin.
Have you tried "Emergency Cache Mode" just to see how it affects first page load and compares with the other cache settings you have tested so far?
I set it in emergency caching mode an hour or so ago, right now it isn't slow, but it's hard to judge since I assume it "wakes up" when people from this forum visits it from time to time.
Well thats a big improvement, I now see it at 3.99secs. Emergency caching should always be awake so it should stay around that speed.
There is of course downsides to having it on so you might want to try setting just that page to 'Until manually cleared' in the page properties and remember to delete the cache when/if changes to that page are made.
Update: Just hit the page a few more times and got it to 2.43secs. Heading in the right direction I hope.
There is of course downsides to having it on so you might want to try setting just that page to 'Until manually cleared' in the page properties and remember to delete the cache when/if changes to that page are made.
Update: Just hit the page a few more times and got it to 2.43secs. Heading in the right direction I hope.
Yeah, but having the site in emergency caching mode, even on a page by page basis is not very client friendly, and should not be needed for a small business site... this ain't CNN.com you know;-)
To me it seems (I'm guessing here) the real problem is two-fold:
My guess is that when the cache is set to the middle setting (not emergency) the cache is not used when the site's been idle for 10 mins or so, even though I've specified it should remain active til manually emptied.
Second is the fact that concrete5 is very database heavy, I read an estimate somewhere that a c5 page may easily require 300+ queries to load, so when the cache fails to do its job the database getting hit. Especially if some of those queries are slow.
In comparison, a typical WordPress page requires around 30 queries to load.
Still, I don't see why the concrete5 site should be so slow uncached. This sitehttp://www.hellelaursen.dk is on the same server, WordPress, served uncached, and not slow...
To me it seems (I'm guessing here) the real problem is two-fold:
My guess is that when the cache is set to the middle setting (not emergency) the cache is not used when the site's been idle for 10 mins or so, even though I've specified it should remain active til manually emptied.
Second is the fact that concrete5 is very database heavy, I read an estimate somewhere that a c5 page may easily require 300+ queries to load, so when the cache fails to do its job the database getting hit. Especially if some of those queries are slow.
In comparison, a typical WordPress page requires around 30 queries to load.
Still, I don't see why the concrete5 site should be so slow uncached. This sitehttp://www.hellelaursen.dk is on the same server, WordPress, served uncached, and not slow...
There are various combinations of caching you can use in C5 but I get where you are coming from, why do we have to rely on it so much.
I have seen many posts on the topic and the common answer I see is blaming the hoster. I am sure this is the case lots of times but C5 has never been the fastest and if it was not for the cache I would have had to move to another CMS.
Having said that C5 is fantastically flexible and is so much easier to use than other CMS's out there and fill a nice niche for the small to medium business, perhaps even big ones too with some Core team tweaking.
It's a topic that wont go away totally for a while but I am guessing the developers will do what they can to change things.
Not much else to say on the topic for now, I hope your site works out and you keep the C5 faith.
I have seen many posts on the topic and the common answer I see is blaming the hoster. I am sure this is the case lots of times but C5 has never been the fastest and if it was not for the cache I would have had to move to another CMS.
Having said that C5 is fantastically flexible and is so much easier to use than other CMS's out there and fill a nice niche for the small to medium business, perhaps even big ones too with some Core team tweaking.
It's a topic that wont go away totally for a while but I am guessing the developers will do what they can to change things.
Not much else to say on the topic for now, I hope your site works out and you keep the C5 faith.
Thanks for your words.
Though if only the caching would work reliably, which it doesn't for me, it would be okay.
On my host all of these: WordPress, Textpattern, Drupal, MODx, Joomla, all work fine.
I've also used concrete5 on the server a year ago, with much better results, it seems there's something wrong, maybe a bug, in the current version...
Though if only the caching would work reliably, which it doesn't for me, it would be okay.
On my host all of these: WordPress, Textpattern, Drupal, MODx, Joomla, all work fine.
I've also used concrete5 on the server a year ago, with much better results, it seems there's something wrong, maybe a bug, in the current version...
If it does work out, perhaps a better way to set the cache settings would be on a per page basis by going to the page properties and changing the speed settings/Full page caching to cache the page for a custom amount of time or until manually cleared.
Strange as hell... Now I deactivated the caching system altogether, and emptied it... Now the site loads faster, and more consistently... what gives??
Reality is stranger than fiction sometimes;-)
Reality is stranger than fiction sometimes;-)
Hi
Exactly what I also just did. And I get better performance.
With emergency cache or other cache super slow.
Without cache, acceptable.
I also set up a cron job to call the page every 5 minutes to have it stay awake. It looks like the first page load is even better.
Compare the two
http://www.rosierose.se/ (with cron and cache off)
http://www.gosavin.se/ (just cache off)
So theese two I had to wait 10 sec ore more with cache on.
Both are still a bit slow during high traffic times.
Regards
Olle
Exactly what I also just did. And I get better performance.
With emergency cache or other cache super slow.
Without cache, acceptable.
I also set up a cron job to call the page every 5 minutes to have it stay awake. It looks like the first page load is even better.
Compare the two
http://www.rosierose.se/ (with cron and cache off)
http://www.gosavin.se/ (just cache off)
So theese two I had to wait 10 sec ore more with cache on.
Both are still a bit slow during high traffic times.
Regards
Olle
Hey Olle
Brilliant thinking with the cron job keeping the page awake. Indeed the page with the cron job was around 50% of the loading time of the other one, which had to be "woken up"...
Would be interesting to know the technical reason as to why a concrete5 site needs to be woken up like that... at least on our servers...
Brilliant thinking with the cron job keeping the page awake. Indeed the page with the cron job was around 50% of the loading time of the other one, which had to be "woken up"...
Would be interesting to know the technical reason as to why a concrete5 site needs to be woken up like that... at least on our servers...
Gentlemen
A thank you to both of you.
I was curious about the no cache option you mentioned so gave it ago on a site I am working on and things do seem faster than with cache enabled.
I enabled it in the first place as it is a image heavy site and I thought the cache would boost the speed but never tried it without a cache.
Dammed if I know why but it has speeded up.
The lesson I think I have learned here is to test cache on and off on each site I do and go for what works best.
Thanks again and this is one of the reason I like this community, it makes you think and try stuff other people use.
A thank you to both of you.
I was curious about the no cache option you mentioned so gave it ago on a site I am working on and things do seem faster than with cache enabled.
I enabled it in the first place as it is a image heavy site and I thought the cache would boost the speed but never tried it without a cache.
Dammed if I know why but it has speeded up.
The lesson I think I have learned here is to test cache on and off on each site I do and go for what works best.
Thanks again and this is one of the reason I like this community, it makes you think and try stuff other people use.
Yeah, and it's even stranger because I'm on a cloud server, where the database is non-localhost, which is why database action can typically be a little slow... So when I enable disk-caching on my WordPress sites, it is very fast.
Weird that the caching in concrete5 works the opposite way then...
The full page caching is a recent addition to concrete5 version 4.1 I think, so maybe it's not totally bugfree?
It would be nice to read what the c5 team can conclude from this... I'm willing to test and supply logs etc, if they want to work on this, cause it sure is weird (and unintended I assume) that the caching is so detrimental to our concrete5 installs??
Weird that the caching in concrete5 works the opposite way then...
The full page caching is a recent addition to concrete5 version 4.1 I think, so maybe it's not totally bugfree?
It would be nice to read what the c5 team can conclude from this... I'm willing to test and supply logs etc, if they want to work on this, cause it sure is weird (and unintended I assume) that the caching is so detrimental to our concrete5 installs??
Same thing for me. At your suggestion I turned OFF page caching. MUCH MUCH faster now. Thanks!
Yes, but with caching off, your database will be raped when you experience any significant traffic, unless you have a really beefy (and expensive) server.
There is no real reason why caching ON should be slower than caching OFF unless:
* Your database is so much quicker than the RewriteRules of the .htaccess file.
* Caching is so appallingly bad in Concrete5 that it takes longer to find the right file than it does to read the database.
* Concrete5 is really bad at recognising that the cache hasn't yet expired so it always goes to the database anyway and also spends some time updating the cache as well.
* Your database is so much quicker than the RewriteRules of the .htaccess file.
* Caching is so appallingly bad in Concrete5 that it takes longer to find the right file than it does to read the database.
* Concrete5 is really bad at recognising that the cache hasn't yet expired so it always goes to the database anyway and also spends some time updating the cache as well.
I have two sites hosted by the same provider and I had the same problem on both, very slow first load.
I deactivated and emptied caches with the same effect on both, they run much faster, in particular first load which now is almost instant.
I deactivated and emptied caches with the same effect on both, they run much faster, in particular first load which now is almost instant.
Ok initial page load being slow could be the result of many things. You have all mentioned some of them.
Initial connection time to the server.
- The visitors browser opens a connection/session with the server on the first visit. This is known to add a delay on the first request to the server.
Static content header expiration set to not cache (client side)
- There are lots of things to tweak here from your web server. I would recommend looking into them.
Slow server, with many HTTP calls (CSS, JS , Images, Etc.)
- If your page requires a lot of linked files it can drastically increase the perceived load time.
- This effect is worsened when you web server is slow with returning requests. Shared Hosting slow?...always.
- Try moving your js calls to the bottom of the page and reducing the number of files needed to load the page.
- Sadly a lot of Blocks in the marketplace are IMHO bloat-ware.
These are just a few performance issues not related to caching. Caching is super critical though.
Rendering PHP pages takes up CPU cycles. On a shared environment you have very little of those to spread around. When you are op-code caching pages you reduce significantly the load on the CPUs. But remember that where the cache is stored will determine how fast the cached op-code can be retrieved.
What type of caching are you using?
File Based? Memory?
If you are using file-based caching expect to be limited by the file read/write speed of your server. In a shared environment it will be slow.
Memory based op-code caching is definitely the speediest. The best option in my opinion in memcache. It is used by many high-profile sites like facebook.com, twitter.com, etc.
Also you may want to increase the full page cache expiration duration. By default it is rather short. Try 24 hours to start with or even higher.
When the expiration time is short that means that as soon as the cache is expired the page will have to be cached again. This means that first request after a cleared/expired cache will take longer to load because the cache is rebuilding. Longer intervals between expiration will means fewer requests requiring cache rebuild.
When a block or page is updated it will invalidate any its cache store and will be current to visitors.
There is more to be said I'm sure but these are a few things that came to mind.
To get a really good idea of where the delay is coming from use a performance tool like the developer tools in safari or firefox to track the response time of the server for each resource and then the download time.
Initial connection time to the server.
- The visitors browser opens a connection/session with the server on the first visit. This is known to add a delay on the first request to the server.
Static content header expiration set to not cache (client side)
- There are lots of things to tweak here from your web server. I would recommend looking into them.
Slow server, with many HTTP calls (CSS, JS , Images, Etc.)
- If your page requires a lot of linked files it can drastically increase the perceived load time.
- This effect is worsened when you web server is slow with returning requests. Shared Hosting slow?...always.
- Try moving your js calls to the bottom of the page and reducing the number of files needed to load the page.
- Sadly a lot of Blocks in the marketplace are IMHO bloat-ware.
These are just a few performance issues not related to caching. Caching is super critical though.
Rendering PHP pages takes up CPU cycles. On a shared environment you have very little of those to spread around. When you are op-code caching pages you reduce significantly the load on the CPUs. But remember that where the cache is stored will determine how fast the cached op-code can be retrieved.
What type of caching are you using?
File Based? Memory?
If you are using file-based caching expect to be limited by the file read/write speed of your server. In a shared environment it will be slow.
Memory based op-code caching is definitely the speediest. The best option in my opinion in memcache. It is used by many high-profile sites like facebook.com, twitter.com, etc.
Also you may want to increase the full page cache expiration duration. By default it is rather short. Try 24 hours to start with or even higher.
When the expiration time is short that means that as soon as the cache is expired the page will have to be cached again. This means that first request after a cleared/expired cache will take longer to load because the cache is rebuilding. Longer intervals between expiration will means fewer requests requiring cache rebuild.
When a block or page is updated it will invalidate any its cache store and will be current to visitors.
There is more to be said I'm sure but these are a few things that came to mind.
To get a really good idea of where the delay is coming from use a performance tool like the developer tools in safari or firefox to track the response time of the server for each resource and then the download time.
Thanks for your reply ppcc.
I agree with you on most points. However, I still ask myself, why this is primarily a
The c5 test site in question, c5.webmatros.dk, has way less http requests thanhttp://www.cityhelse.dk yet the latter is much faster. And totally uncached. Andhttp://www.bryllupskanalen.tv on the same server, is not slow in the same way.
When troubleshooting the c5 site in Safari Dev Tools, the first pageload is slow due to the first bar being long, ie. it takes a long time for the site to begin doing anything at all. The http requests load fine... when they eventually load...
I already tried setting the cache expiration to a long expiration time, yet it seems to not use the cache after 10 mins or so...
I currently run Zend Optimizer, but also have APC installed, but currently deactivated.
I agree with you on most points. However, I still ask myself, why this is primarily a
The c5 test site in question, c5.webmatros.dk, has way less http requests thanhttp://www.cityhelse.dk yet the latter is much faster. And totally uncached. Andhttp://www.bryllupskanalen.tv on the same server, is not slow in the same way.
When troubleshooting the c5 site in Safari Dev Tools, the first pageload is slow due to the first bar being long, ie. it takes a long time for the site to begin doing anything at all. The http requests load fine... when they eventually load...
I already tried setting the cache expiration to a long expiration time, yet it seems to not use the cache after 10 mins or so...
I currently run Zend Optimizer, but also have APC installed, but currently deactivated.
webmatros, i visit back to your site c5.webmatros.dk, and it's seems to be normal, not heavy loaded like before. what you have done? it's because turn-off cache?
oh yes, that http://bryllupskanalen.tv is sure fast! i like it. what this site cms build from?
i look out to view source, but there is only js script.
Thanks.
oh yes, that http://bryllupskanalen.tv is sure fast! i like it. what this site cms build from?
i look out to view source, but there is only js script.
Thanks.
Yeah the c5.webmatros.dk page is now uncached, which on my server means faster than cached. It's strange 'cause whenever I cache WordPress, Drupal or MojoMotor sites, they get faster than when uncached, so it's very strange that Concrete5 doesn't work for me with caching on, as I'd still consider it slow, when uncached.
Bryllupskanalen.tv is built on WordPress, and is served uncached, apart from the fact that the html is minified (spaces and linebreaks are removed).
Bryllupskanalen.tv is built on WordPress, and is served uncached, apart from the fact that the html is minified (spaces and linebreaks are removed).
I'm having this exact same problem on one of my test sites. cache doesn't seem to make much difference, but initial page load is SLOOWWW. Can be up to 30 seconds. After the initial load the site runs fine, even going back to the home page. like described in this thread, feels like the site has to "wake up" first. My provider said it was the htaccess file - just the pretty url dialogue
Hmm, strange. Have you tried disabling the pretty urls?
Where are you hosted? What kind og hosting? Shared, virtual, dedicated, cloud?
Where are you hosted? What kind og hosting? Shared, virtual, dedicated, cloud?
I'm glad to have found this thread and to read all these comments here, because i'm experiencing exactly the same problem. I suspect the "intelligent" cache system to cause that issue. I'm running a handfull of TYPO3 diven sites without any lack of performance on a shared host. It's only concrete5 (test-)sites that have performance issues with first time page loads, exactly as described above. That still keeps me from using concrete5 for production. It would be great, if the developers would read this thread, i think this issue is a serious and very annoying one.
Yep, I'm having the exact same problem for my site http://www.gryc.com.au
If if hasn't been looked at for a while, it takes up to 10 seconds to load, then each page load after that is under a second.. I've done lots of things to optimise it, remove jquery, etc. I had to consider the site for dial-up users, so even with a full page refresh it loads the site's resources pretty quickly. It is definitely an issue when the site hasn't been looked at for a bit.
It would be great if this could be looked at in more detail. C5 is such a great product, with this 'bug' being the only thing I would change about it!
If if hasn't been looked at for a while, it takes up to 10 seconds to load, then each page load after that is under a second.. I've done lots of things to optimise it, remove jquery, etc. I had to consider the site for dial-up users, so even with a full page refresh it loads the site's resources pretty quickly. It is definitely an issue when the site hasn't been looked at for a bit.
It would be great if this could be looked at in more detail. C5 is such a great product, with this 'bug' being the only thing I would change about it!
Yeah...I turned off all cacheing and my site speeded up too.
Weird.
I was thinking that C5 is just too slow for my tastes but this has rescued it such that I will continue with it (for now).
Thanks.
Carlos
Weird.
I was thinking that C5 is just too slow for my tastes but this has rescued it such that I will continue with it (for now).
Thanks.
Carlos
I have the same problem and made some investigations with xdebug and chrome. First i blamed the host, chrome reported a waiting time of 2-3 sec every time a page loaded. Then images and html-files of the page was loaded in an instant.
So i tried on my local setup using xampp. Chrome reported a waiting time of 0,5-1,5 sec. That's damn long time on the same machine.
I activated xdebug and used WinCacheGrind to analyse the output. The files that took the longest to load from dispatcher.php was
file_types.php - 95 ms (types.php and localization.php)
app.php - 93 ms (config.php and localization.php)
view.php - 91 ms (page_not_found.php, concrete.php, loader.php)
(DB) loader.php - 74 ms
(lib) loader.php - 37 ms (localization.php)
Except from the DB loader, the localization is the big time theif here. That's my findings so far. I haven't looked in to it more than that.
I feel a bit bad about a quite angry mail i sent to the host. But they are partialy to blame. If they have problem with the storage and jam packed accounts on the servers it can get really slow.
/Chris
So i tried on my local setup using xampp. Chrome reported a waiting time of 0,5-1,5 sec. That's damn long time on the same machine.
I activated xdebug and used WinCacheGrind to analyse the output. The files that took the longest to load from dispatcher.php was
file_types.php - 95 ms (types.php and localization.php)
app.php - 93 ms (config.php and localization.php)
view.php - 91 ms (page_not_found.php, concrete.php, loader.php)
(DB) loader.php - 74 ms
(lib) loader.php - 37 ms (localization.php)
Except from the DB loader, the localization is the big time theif here. That's my findings so far. I haven't looked in to it more than that.
I feel a bit bad about a quite angry mail i sent to the host. But they are partialy to blame. If they have problem with the storage and jam packed accounts on the servers it can get really slow.
/Chris
Interesting findings.
I'm thinking this could also be related to the caching using file locking?
Below is a quotation from my hosts forum:
"If your site is using "file locking" when it creates its cache, then that could be the source of the issue. The (gs) Grid-Service uses NFS (Network File System) to access the web directories. NFS and large numbers of locked files are detrimental to the performance and life space of the disk drive in this type of environment.
If you have the option, you'll want to ensure that your site's cache system is not using file locks to. You may also want to consult with the ExpressionEngine community to find out if the PHP function "flock()" is used in conjunction with the cache system, and if there is anything you can do to disable it."
I'm thinking this could also be related to the caching using file locking?
Below is a quotation from my hosts forum:
"If your site is using "file locking" when it creates its cache, then that could be the source of the issue. The (gs) Grid-Service uses NFS (Network File System) to access the web directories. NFS and large numbers of locked files are detrimental to the performance and life space of the disk drive in this type of environment.
If you have the option, you'll want to ensure that your site's cache system is not using file locks to. You may also want to consult with the ExpressionEngine community to find out if the PHP function "flock()" is used in conjunction with the cache system, and if there is anything you can do to disable it."
So, is concrete5 actually using file locking for the caching?
I think it is, but someone more concrete5 / php-skilled should be able to answer that with certainty. Anyone?
The flock() PHP function is used in the 3rdparty libraries for adodb and zend. The most clear text cache related i found was this file.
"\concrete\libraries\3rdparty\Zend\Cache\Backend\File.php"
When i follow the process tree in WinCacheGrind, File.php i can say that webmatros was right on the money. Many (maybe all) of the requests that takes up the time ends in calling the function "_fileGetContents()" that utilize flock().
If it a real and common problem, here is something to start experiment with.
"\concrete\libraries\3rdparty\Zend\Cache\Backend\File.php"
When i follow the process tree in WinCacheGrind, File.php i can say that webmatros was right on the money. Many (maybe all) of the requests that takes up the time ends in calling the function "_fileGetContents()" that utilize flock().
If it a real and common problem, here is something to start experiment with.
I did some tests yesterday, i found that in File.php you can disable the file lock option (at line 92).
First on my local machine but that didn't show any difference. Then i uploaded to the live server, cleared the cache and tested some pages with chrome, first load to time took a moment, but after that i was a bit surprised. I don't know if my host just made some upgrades or if it was a low load at the moment. The wait time when the page was loaded was betweed 500-800 ms. Before it was 2-3 seconds. Major improvements.
Definitly worth a try, but depending on the host i guess there will be different outcomes. Would love to hear other results.
First on my local machine but that didn't show any difference. Then i uploaded to the live server, cleared the cache and tested some pages with chrome, first load to time took a moment, but after that i was a bit surprised. I don't know if my host just made some upgrades or if it was a low load at the moment. The wait time when the page was loaded was betweed 500-800 ms. Before it was 2-3 seconds. Major improvements.
Definitly worth a try, but depending on the host i guess there will be different outcomes. Would love to hear other results.
I've tried this now on my test site, yet still as slow with caching ON as with caching OFF, at least for me. Initial connection / page load waiting time for a simple simple simple site with no js etc, is between 2 and 5 seconds.
I'm coming to the conclusion that concrete5 is just a heavy system, and that the devs have done what they can to make it as "light" as possible.
I'm coming to the conclusion that concrete5 is just a heavy system, and that the devs have done what they can to make it as "light" as possible.
Speaking of it being a heavy system...that doesn't surprise me. I was actually rather surprised when I uploaded my first C5 site to make it live when I discovered over 3000 files being uploaded! That was a first.
Carlos
Carlos
Yeah this is one of the perils of using third party libraries, but I'd say it's an acceptable tradeoff. I'd say 80% of the code that we include with concrete5 are things we haven't even written ourselves: TinyMCE, our Zend Framework libraries (including Zend_Locale, which is a big one), ADODB and all its tests, etc...
Which isn't to say that concrete5 doesn't have a lot of code behind it – we definitely do, we're just reusing a lot of components to save ourselves time and to minimize errors.
Which isn't to say that concrete5 doesn't have a lot of code behind it – we definitely do, we're just reusing a lot of components to save ourselves time and to minimize errors.
I think we might be reaching some of the limits of what your hosting environment can support. It is true that concrete5 is a heavier system than some other cms platforms out there - that is some of the trade-off that comes with being a bit more customizable and flexible (plus our reliance on some Zend libraries has increased our typical memory usage) - but many servers will render a concrete5 page must faster than what you're experiencing. Sorry that you're having trouble with it.
Well, heavy system or not, any file system cache should actually work nicely. I would tend to say, if it doesn't, there's something wrong. With TYPO3 for example, i'm always using the option of caching at file system level, instead of database level, and this works perfectly, while you might agree with me, that TYPO3 is also a "heavy" system.
I think, what causes that slow "first page load" must be caused by the particular concept of the concrete5 cache system itself.
While I really appreciate that Andrew is finally posting a comment, i'm a bit surprised by the message itself. Is that all that can be said? I think, this thread - containing already 40 comments - should be questioned and evaluated seriousely.
@carlos:
3000 files - i believe that the amount of files of a cms doesn't say much about performance. take my example of TYPO3 with file system based cache: for my own and for my client's sites i haven't experienced any performance issues so far, even on a low-priced shared server (www.world4you.com).
i always wonder, why there are constantly added new files by concrete5 to that files/cache/ folder, even while nothing has changed and the cache lifetime has been set to forever!
I think, what causes that slow "first page load" must be caused by the particular concept of the concrete5 cache system itself.
While I really appreciate that Andrew is finally posting a comment, i'm a bit surprised by the message itself. Is that all that can be said? I think, this thread - containing already 40 comments - should be questioned and evaluated seriousely.
@carlos:
3000 files - i believe that the amount of files of a cms doesn't say much about performance. take my example of TYPO3 with file system based cache: for my own and for my client's sites i haven't experienced any performance issues so far, even on a low-priced shared server (www.world4you.com).
i always wonder, why there are constantly added new files by concrete5 to that files/cache/ folder, even while nothing has changed and the cache lifetime has been set to forever!
I guess that such complex systems take time to improve and optimise.
For me, the performance tweaking issues are sort of offset by how feature rich the system is, how easy it is to develop a site and how easy it for clients to use. I think C5 has got it right is so many ways and the devs should be congratulated!
This being said the, slow start up time IS clearly a problem and it does need to be looked at. I've too wondered at the large number of cached files that are created, it doesn't seem like a normal use of resources. I'm sure the C5 team are taking note of this thread.
In the meantime, I've extended the CACHE_LIFETIME and added the CACHE_BACKEND_OPTIONS as per webchris's suggestion. One at least one site these things help and I'm not experiencing as long a delay I had before, but it is hard to judge on shared servers.
For me, the performance tweaking issues are sort of offset by how feature rich the system is, how easy it is to develop a site and how easy it for clients to use. I think C5 has got it right is so many ways and the devs should be congratulated!
This being said the, slow start up time IS clearly a problem and it does need to be looked at. I've too wondered at the large number of cached files that are created, it doesn't seem like a normal use of resources. I'm sure the C5 team are taking note of this thread.
In the meantime, I've extended the CACHE_LIFETIME and added the CACHE_BACKEND_OPTIONS as per webchris's suggestion. One at least one site these things help and I'm not experiencing as long a delay I had before, but it is hard to judge on shared servers.
Concrete5 is fast! Zend is not, both cache and localization have issues that makes the pages load slowly. That's what needs to be adressed. I don't gives a rats a** about other systems, there is plenty to choose from but none of them have what concrete5 have.
Concrete5 is a great product and many thanks to Andrew and the team. As with everything, you need to learn the system and tweak it to your liking. Improvments will be made, i think the dev-team don't like it as much as we do.
Concrete5 is a great product and many thanks to Andrew and the team. As with everything, you need to learn the system and tweak it to your liking. Improvments will be made, i think the dev-team don't like it as much as we do.
Let's be straight, concrete5 is not fast. It is rather complex, and therefore not especially fast.
I remember reading in the docs somewhere that one should ALWAYS use an opcode cache, at least Zend, and maybe APC. I've tried both, and concrete5 is slow using both.
I remember reading in the docs somewhere that one should ALWAYS use an opcode cache, at least Zend, and maybe APC. I've tried both, and concrete5 is slow using both.
See, this is where I disagree. I've just moved a concrete5 site between hosts. Not to a dedicated server, but to another shared host. All of my speed issues are now gone and there is no 'warm up' delay I experienced on the old host.
The new site doesn't have any optimizing modules turned on at the moment, and it's blazing. Something about Concrete5 is sensitive with hosting, but it's not slow as such. I can't work it out!
The new site doesn't have any optimizing modules turned on at the moment, and it's blazing. Something about Concrete5 is sensitive with hosting, but it's not slow as such. I can't work it out!
For a website to "wake-up" it depends on 3 criteria. The time for a DNS lookup, the time for the server to respond and the time before the browser can start to display content.
Concrete isn't particularly fast at the latter, but it's not the code overhead, it's fragmentation of the page (intermingled JavaScript, style sheets etc.) because modules are added ad-hoc to the header and the browser cannot start to render until nearly all the page is loaded. The more blocks you add to your page (especially with external content), the worse it gets. But this should be constant (unless you change the contents of a page).
The way to really see what's happening is to run a web-page test. If the DNS lookup or time to the first byte is long, then you need to get in touch with the provider (I recently had to do this after the time to the first byte shot up from 1-2 secs to >15). If the time between the first byte and the start of rendering is long, then that is concrete. this will tell you where the problem lies.
It is more than likely that if you are seeing inconsistent/intermittent page load times, then it is the time to receive the first byte that is the culprit (i.e the provider) rather than concrete. And if you find it is concrete, then it is also very likely that one or more of your blocks has external content which is taking longer than usual to respond.
Concrete isn't particularly fast at the latter, but it's not the code overhead, it's fragmentation of the page (intermingled JavaScript, style sheets etc.) because modules are added ad-hoc to the header and the browser cannot start to render until nearly all the page is loaded. The more blocks you add to your page (especially with external content), the worse it gets. But this should be constant (unless you change the contents of a page).
The way to really see what's happening is to run a web-page test. If the DNS lookup or time to the first byte is long, then you need to get in touch with the provider (I recently had to do this after the time to the first byte shot up from 1-2 secs to >15). If the time between the first byte and the start of rendering is long, then that is concrete. this will tell you where the problem lies.
It is more than likely that if you are seeing inconsistent/intermittent page load times, then it is the time to receive the first byte that is the culprit (i.e the provider) rather than concrete. And if you find it is concrete, then it is also very likely that one or more of your blocks has external content which is taking longer than usual to respond.
Well, concrete5 is much slower to first byte than WordPress or MojoMotor or Textpattern or Joomla sites on the same hosting account. At least for me. I've verified it again and again via tools.pingdom.com.
Ok, I'm starting to see what you mean. Perhaps I'm just on a good/free server at the moment. I'm just concerned about using Concrete5 in the future, for something like a school website, or something that will get some higher traffic.
I wonder if some kind of ultra simple cache could be put in front of the whole system, I've done that before for some custom projects. (I did read ideas of that elsewhere on here)
PS- I hadn't ever come across pingdom tools before, really handy/interesting!
I wonder if some kind of ultra simple cache could be put in front of the whole system, I've done that before for some custom projects. (I did read ideas of that elsewhere on here)
PS- I hadn't ever come across pingdom tools before, really handy/interesting!
Of course I hope it may be due to server settings, which, once nailed down, can alleviate the problem for many people.
But, it may also just be because your new shared hosting account is on a server that's not full yet, so not running at full load. I've experienced that many times. That's why a new gloryful host is often "way better than the old host" - when, a month or two after signing up, the problems come back, the "new fast host" becomes the "old slow host"...
Important though:
If your shared server is not very crowded, you may utilize a lot more resources, hence a much faster concrete5. But what many people seem to forget is these two factors:
1.
It will not be scalable if you want to run more than one concrete5 website on the same machine. Concrete5 "costs" more resources (in the end "money") to run. Literally. Just look at the prices for concrete5 hosting by the concrete5 team.
2.
If your site suddenly sees a spike in traffic, your concrete5 site will cripple the server much faster than say, a WordPress site would. Or a MojoMotor site. The latter being very lean and fast. There's a big difference as to whether your server would give up after 50 or 500 hits. You don't want to loose such an opportunity.
PS: When I say "you" in the above I don't particularly mean YOU, it's more meant as a generalization in the context of your post;-)
But, it may also just be because your new shared hosting account is on a server that's not full yet, so not running at full load. I've experienced that many times. That's why a new gloryful host is often "way better than the old host" - when, a month or two after signing up, the problems come back, the "new fast host" becomes the "old slow host"...
Important though:
If your shared server is not very crowded, you may utilize a lot more resources, hence a much faster concrete5. But what many people seem to forget is these two factors:
1.
It will not be scalable if you want to run more than one concrete5 website on the same machine. Concrete5 "costs" more resources (in the end "money") to run. Literally. Just look at the prices for concrete5 hosting by the concrete5 team.
2.
If your site suddenly sees a spike in traffic, your concrete5 site will cripple the server much faster than say, a WordPress site would. Or a MojoMotor site. The latter being very lean and fast. There's a big difference as to whether your server would give up after 50 or 500 hits. You don't want to loose such an opportunity.
PS: When I say "you" in the above I don't particularly mean YOU, it's more meant as a generalization in the context of your post;-)
A screenshot of the cache folder after accessing a test site after two hours. Just to illustrate that there are always new files written to the cache, even when nothing has changed. Why?
Please note, that this procedure takes 6 seconds (from 09:15:08 to 09:15:14)!
Please note, that this procedure takes 6 seconds (from 09:15:08 to 09:15:14)!
Yes, that is indeed strange. What's the purpose of a cache that works against its purpose?
Just to emphasize what i mean: my impression is, that concrete5 isn't generally slow, it's just the first page load that is slow. Please take a look at that sceenshot of the cache folder (as provided above), taken via ftp, two hours after (exclusively) accessing a test site: even while nothing has changed in the meantime, after calling exactly the same pages as two hours before, i find that concrete5 has added some new cache files. Why does it do that?
Calling exactly the same two (empty) pages - "Home" and another one - some minutes later again, generates 20 (!) new cache files!
Every time i click the two menu links, 14 cache files are updated again! When i click only "Home" - my ftp client shows 10 updated files.
The content of those files looks like that:
Each access to a concrete5 site produces new or updated cache files in the "cache" folder... why?
Calling exactly the same two (empty) pages - "Home" and another one - some minutes later again, generates 20 (!) new cache files!
Every time i click the two menu links, 14 cache files are updated again! When i click only "Home" - my ftp client shows 10 updated files.
The content of those files looks like that:
a:4:{s:4:"hash";i:-154489654;s:5:"mtime";i:1301140416;s:6:"expire";i:1302004416;s:4:"tags";a:1:{i:0;s:25:"page_permission_set_guest";}}
Each access to a concrete5 site produces new or updated cache files in the "cache" folder... why?
This thread seems to have solved my problem with slow loading of the first page:
http://www.concrete5.org/community/forums/chat/concrete-on-steroids...
So far, i'm quite happy with my test site's performance, using that tool called "miser" and cache turned off (!).
That approach is definitely worth a look!
http://www.concrete5.org/community/forums/chat/concrete-on-steroids...
So far, i'm quite happy with my test site's performance, using that tool called "miser" and cache turned off (!).
That approach is definitely worth a look!
I was experiencing the exact same problems onhttp://www.tuinfun.nl.
With emergency full page caching on:
When pages are cached they load almost instant. But when they are not cached it can take up to 20 seconds to load a page.
After reading this thread I've tested with the cache off entirely. This way the 20 second loads are gone. Page loads take about 2 seconds consistently.
This server is running two websites, and there is very little traffic atm since the sites are just new and have not really been published yet. It's running a xeon 3220 quad-core cpu with 6gb ram and apc opcode caching. So with this little traffic performance should not be an issue.
Something with the cache systems seems to be really broken. It should never make initial page loads this much slower.
I read here zend is slow etc.. We've built many websites based on the zend framework with zf's front controller and Zend_Cache as caching backend. Those sites are definately not slow. This includes big sites with high traffic and sites on comparable servers running shared hosting with 200+ websites on the same server. So just saying zend is slow, is kind of stupid imho. Something seems to be really broken in c5's cacheing system.
For now I'll leave the caching off, this way at least we get consistent page loading times. I'm planning on testing the concrete on steroids modification, to see if that helps the loading time some more.
With emergency full page caching on:
When pages are cached they load almost instant. But when they are not cached it can take up to 20 seconds to load a page.
After reading this thread I've tested with the cache off entirely. This way the 20 second loads are gone. Page loads take about 2 seconds consistently.
This server is running two websites, and there is very little traffic atm since the sites are just new and have not really been published yet. It's running a xeon 3220 quad-core cpu with 6gb ram and apc opcode caching. So with this little traffic performance should not be an issue.
Something with the cache systems seems to be really broken. It should never make initial page loads this much slower.
I read here zend is slow etc.. We've built many websites based on the zend framework with zf's front controller and Zend_Cache as caching backend. Those sites are definately not slow. This includes big sites with high traffic and sites on comparable servers running shared hosting with 200+ websites on the same server. So just saying zend is slow, is kind of stupid imho. Something seems to be really broken in c5's cacheing system.
For now I'll leave the caching off, this way at least we get consistent page loading times. I'm planning on testing the concrete on steroids modification, to see if that helps the loading time some more.
I just installed miser 1.5.0 (concrete on steroids). This helped some more with the performance.
Now page loading times are acceptable (<2sec) and comparable to other cms'es.
Still strange that you can get extremely long loading times by enabling cache...
Now page loading times are acceptable (<2sec) and comparable to other cms'es.
Still strange that you can get extremely long loading times by enabling cache...
We're still looking into ways to tune the cache. I think some of our options are conflicting with each other. For example, the default block-level cache lifetime is independent (defined in block_controller.php) and is lower than the main one. I've updated this in github to respect the global CACHE_LIFETIME variable (although individual blocks can override it.)
I'm also looking at why certain other cache entries appear in the files/cache directory even when the lifetime is set to 0.
I'm also looking at why certain other cache entries appear in the files/cache directory even when the lifetime is set to 0.
I have also had the same sorts of troubles with the first page loading slowly for my site:
http://www.systemsbiology.co.uk...
which would take anywhere up to 30 seconds or more to load.
Two changes I have made are that I have set cache timeout to 1440 minutes (or 24 hours in other words) and I have switched OFF Pretty URLs. If you think about it, each page loads as many as 30 files from the server and every one has to be converted to a pretty URL by the server. I think this is quite a slow process with Apache and so if you can deal with having that index.php in your URL, turn them off and it makes the site much quicker (or at least I think that's what's made the biggest difference).
I know the host are to blame for slow servers really, but they were cheap, so what can you complain about really?
I did have a theory as to why the very first page load is slow, and this is partly because your browser is establishing a new connection with the server and also because, if the server uses hard drive power saving and the database hasn't been accessed in some time, it's probably quite likely that the server needs to spin up the hard drives that store your data which can take about 3 or 4 seconds to get the disk mounted again.
http://www.systemsbiology.co.uk...
which would take anywhere up to 30 seconds or more to load.
Two changes I have made are that I have set cache timeout to 1440 minutes (or 24 hours in other words) and I have switched OFF Pretty URLs. If you think about it, each page loads as many as 30 files from the server and every one has to be converted to a pretty URL by the server. I think this is quite a slow process with Apache and so if you can deal with having that index.php in your URL, turn them off and it makes the site much quicker (or at least I think that's what's made the biggest difference).
I know the host are to blame for slow servers really, but they were cheap, so what can you complain about really?
I did have a theory as to why the very first page load is slow, and this is partly because your browser is establishing a new connection with the server and also because, if the server uses hard drive power saving and the database hasn't been accessed in some time, it's probably quite likely that the server needs to spin up the hard drives that store your data which can take about 3 or 4 seconds to get the disk mounted again.
In fact - I have been investigating further and have a feeling there's some recursion going on when Pretty URLs are enabled. Basically, the page gets called by:
http://www.yourdomain.com/page/subpage/...
and the rewrite function then changes this (invisibly) into:
http://www.yourdomain.com/index.php/page/subpage/...
BUT -- if a request is made to a resource with the index.php part already in, then something like this happens (I think). You request:
http://www.yourdomain.com/index.php/page/subpage...
which gets converted into:
http://www.yourdomain.com/index.php/index.php/page/subpage...
Which gets turned into:
http://www.yourdomain.com/index.php/index.php/index.php/page/subpag...
and so on .... this is all theory, I am in no way an expert on mod_rewrite ... but one way to make 100% sure this isn't happening is to change your .htaccess file so that, rather than reading something like this:
You add a line in above the RewriteRule so that your file looks like this:
That extra RewriteCond ensures that any URL to be rewritten doesn't already have the index.php in its name and prevents recursion.
It works for me anyway!!
http://www.yourdomain.com/page/subpage/...
and the rewrite function then changes this (invisibly) into:
http://www.yourdomain.com/index.php/page/subpage/...
BUT -- if a request is made to a resource with the index.php part already in, then something like this happens (I think). You request:
http://www.yourdomain.com/index.php/page/subpage...
which gets converted into:
http://www.yourdomain.com/index.php/index.php/page/subpage...
Which gets turned into:
http://www.yourdomain.com/index.php/index.php/index.php/page/subpag...
and so on .... this is all theory, I am in no way an expert on mod_rewrite ... but one way to make 100% sure this isn't happening is to change your .htaccess file so that, rather than reading something like this:
# -- concrete5 urls start -- <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ index.php/$1 [L] </IfModule> # -- concrete5 urls end --
You add a line in above the RewriteRule so that your file looks like this:
# -- concrete5 urls start -- <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteCond $1 !^index.php RewriteRule ^(.*)$ index.php/$1 [L] </IfModule> # -- concrete5 urls end --
That extra RewriteCond ensures that any URL to be rewritten doesn't already have the index.php in its name and prevents recursion.
It works for me anyway!!
I've found that although preventing recursion of the .htaccess rules does help, the slow down on the first page is in fact caused by my hosts PHP interpreter being particularly slow on the first load. I am with PacificHost and it seems that every site that relies on PHP on that server is slow on the first page load. It's not Concrete5 specific.
I'm still not sure why only the first page is slow, but for example, I have this Wordpress pagehttp://www.systemsbiology.co.uk... and I have a Concrete5 site athttp://c5themes.bespokedesigner.co.uk... and they are both equally slow to load the first page if the site hasn't been accessed in a short while. They are on exactly the same server as each other.
Theories I have as to why it is slow include that the hard drives storing the information perhaps go to sleep on the server and have to be woken up before the site can be served. Perhaps this applies to the database as well? Impossible to tell as I obviously only have limited access to the server.
I'm still not sure why only the first page is slow, but for example, I have this Wordpress pagehttp://www.systemsbiology.co.uk... and I have a Concrete5 site athttp://c5themes.bespokedesigner.co.uk... and they are both equally slow to load the first page if the site hasn't been accessed in a short while. They are on exactly the same server as each other.
Theories I have as to why it is slow include that the hard drives storing the information perhaps go to sleep on the server and have to be woken up before the site can be served. Perhaps this applies to the database as well? Impossible to tell as I obviously only have limited access to the server.
Not true. When I loaded your two pages, the WordPress site loaded within around 5 seconds, while the c5 site took 30 seconds or more. I expected it to time out, but after around 30 seconds it loaded.
Not good.
Not good.
No, it's not good and no-one wants to take responsibility. I personally find that the WordPress site can also be very slow to kick in after some time of inactivity, but I had opened it shortly after posting and so that's probably why it worked quickly for you.
What is a real shame is that the only reason I chose PacificHost is that they were recommended to me by Concrete5 (see the hosting section). I'm not sure they're ready to be hosting Concrete5 yet. I know that the underlying cause MIGHT be the inefficiency of Concrete5, but the direct cause is obviously that the hosting environment is not as fast as you might hope for. This is absolutely definite because the C5 site runs ultra quick when on my local machine indicating that it can run fast if there's enough power there for it to do so.
What is a real shame is that the only reason I chose PacificHost is that they were recommended to me by Concrete5 (see the hosting section). I'm not sure they're ready to be hosting Concrete5 yet. I know that the underlying cause MIGHT be the inefficiency of Concrete5, but the direct cause is obviously that the hosting environment is not as fast as you might hope for. This is absolutely definite because the C5 site runs ultra quick when on my local machine indicating that it can run fast if there's enough power there for it to do so.
To be fair, I gotta add:
I just put both of your sites throughhttp://loadimpact.com and the c5 site took 50 concurrent users at 10.5 seconds.
The WordPress site could only take 30 concurrent at 18 seconds.
But nevertheless, something weird is up with c5 and loading. If only it could be sorted out, I would be all over c5.
I just put both of your sites throughhttp://loadimpact.com and the c5 site took 50 concurrent users at 10.5 seconds.
The WordPress site could only take 30 concurrent at 18 seconds.
But nevertheless, something weird is up with c5 and loading. If only it could be sorted out, I would be all over c5.
Does anyone know if you get a faster page load with multiple content blocks or one big content block?
Hi Adeang (I am thankful that the forum put names back on by default so that I can easily see who I am responding to :)),
That depends...
If you have 10 mini content blocks that are really small in content size and one huge content block that has 3 MB's of content...well...the mini blocks will probably load and render faster.
But all else being equal one content block will tend to load faster than several.
Why?
Every content block likely ends up causing an HTTP request to the server (not always I think in that browser can request two items per actual request I think).
That HTTP request takes time to make the round trip between the browser and the server and has some overhead associated with it.
So those three mini-blocks may involve at least two if not three HTTP requests.
The one block only involves one.
The real issue is whether the overhead of the extra HTTP requests (and the need to render 3 separate blocks in the browser) is more time consuming with respect to page loading than the one HTTP request for the one block.
Hmmm...that's not quite true actually.
There is also the factor of the 3 mini-blocks likely making 3 different mySQL query requests to the database as well (on the server side) before the content is returned to the browser and displayed.
That too takes a bit of time. As opposed to making just one mySQL request for the one big block.
So it's both the excess HTTP requests and the extra MySQL database requests that ultimately determine for the most part whether one big block will render faster than multiple blocks.
I personally would not worry about it and would just advise you to go ahead and use whatever blocks you need or want. After your site is running like you want it...then might be a good time to run a profiler (code in a program) that allows you to see where the site is slowest. At which point you can focus on speeding up the slow part...whatever is causing that slowness.
I hope that makes sense.
Carlos
That depends...
If you have 10 mini content blocks that are really small in content size and one huge content block that has 3 MB's of content...well...the mini blocks will probably load and render faster.
But all else being equal one content block will tend to load faster than several.
Why?
Every content block likely ends up causing an HTTP request to the server (not always I think in that browser can request two items per actual request I think).
That HTTP request takes time to make the round trip between the browser and the server and has some overhead associated with it.
So those three mini-blocks may involve at least two if not three HTTP requests.
The one block only involves one.
The real issue is whether the overhead of the extra HTTP requests (and the need to render 3 separate blocks in the browser) is more time consuming with respect to page loading than the one HTTP request for the one block.
Hmmm...that's not quite true actually.
There is also the factor of the 3 mini-blocks likely making 3 different mySQL query requests to the database as well (on the server side) before the content is returned to the browser and displayed.
That too takes a bit of time. As opposed to making just one mySQL request for the one big block.
So it's both the excess HTTP requests and the extra MySQL database requests that ultimately determine for the most part whether one big block will render faster than multiple blocks.
I personally would not worry about it and would just advise you to go ahead and use whatever blocks you need or want. After your site is running like you want it...then might be a good time to run a profiler (code in a program) that allows you to see where the site is slowest. At which point you can focus on speeding up the slow part...whatever is causing that slowness.
I hope that makes sense.
Carlos
Thank you Carlos. It does make sense, I guess my main worry was that a content block with a few paragraphs of text and some photos would take longer to load then say three content blocks each with a paragraph and a picture.
Glad you got something out of what I said.
As for the scenario you describe it's impossible to tell from the general description of one content block with several paragraphs of text and some photos and several content blocks with one of each.
It would all depend on the size of the photos, the amount of text, how many HTTP requests would be needed to satisfy the request for the page on which the content block(s) is(are) found, and the number of MySQL queries involved to pull up the content required.
Oh...and which browser you used in that some browsers do better cacheing and faster rendering than others.
Best thing is to create the very blocks you speak of, insert them into a page on a C5 site, and then create a small PHP code script to call that page repeatedly for 1000 times let's say (you could use the wget() function to get the page...you don't even need a browser for that). Timing it's execution.
That will tell you definitively as to which approach is faster and whether the speed difference makes any...well...difference at all to a potential real user in that the speed difference might be so minimal for a single page load time as to not even consider it. Take away the photos and run the same test. Use the same paragraph, etc.. Through a series of such testing you should be able to tell what is faster than what else in rendering the page.
Carlos
As for the scenario you describe it's impossible to tell from the general description of one content block with several paragraphs of text and some photos and several content blocks with one of each.
It would all depend on the size of the photos, the amount of text, how many HTTP requests would be needed to satisfy the request for the page on which the content block(s) is(are) found, and the number of MySQL queries involved to pull up the content required.
Oh...and which browser you used in that some browsers do better cacheing and faster rendering than others.
Best thing is to create the very blocks you speak of, insert them into a page on a C5 site, and then create a small PHP code script to call that page repeatedly for 1000 times let's say (you could use the wget() function to get the page...you don't even need a browser for that). Timing it's execution.
That will tell you definitively as to which approach is faster and whether the speed difference makes any...well...difference at all to a potential real user in that the speed difference might be so minimal for a single page load time as to not even consider it. Take away the photos and run the same test. Use the same paragraph, etc.. Through a series of such testing you should be able to tell what is faster than what else in rendering the page.
Carlos
Thanks for the reply.
Just want to add my two cents here...
I don't believe that further blocks on a page increases the number of HTTP requests. There is only one request for the HTML of a page, and then a request for each resource on the page returned, such as stylesheets, javascript files and images. No different than any other website, static or otherwise.
Carlos is right about the database queries though, more blocks are going to increase the number of hits on the database. There is also further (but tiny) processing and memory overheads as C5 is having to instiate the code for each block and process it, as opposed to doing that once and simply outputting more content.
But in the bigger picture, three content blocks versus one block that contains all the content will make pretty much no difference. It's amazing how many database queries can take place in fractions of a second on a modern server. I think if you are just using C5 as a CMS, you shouldn't ever have to think about database queries/speed. It's only if you are doing custom development where you might create a custom page that hits the database repeatedly, where you might need to profile and optimise.
For interest sake, if you want to see how many database queries happen for a page load, on a development version of C5, add the following lines of code to the header file of a theme:
I was surprised myself, but it's pretty normal for a modern CMS or web application.
I don't believe that further blocks on a page increases the number of HTTP requests. There is only one request for the HTML of a page, and then a request for each resource on the page returned, such as stylesheets, javascript files and images. No different than any other website, static or otherwise.
Carlos is right about the database queries though, more blocks are going to increase the number of hits on the database. There is also further (but tiny) processing and memory overheads as C5 is having to instiate the code for each block and process it, as opposed to doing that once and simply outputting more content.
But in the bigger picture, three content blocks versus one block that contains all the content will make pretty much no difference. It's amazing how many database queries can take place in fractions of a second on a modern server. I think if you are just using C5 as a CMS, you shouldn't ever have to think about database queries/speed. It's only if you are doing custom development where you might create a custom page that hits the database repeatedly, where you might need to profile and optimise.
For interest sake, if you want to see how many database queries happen for a page load, on a development version of C5, add the following lines of code to the header file of a theme:
$db = Loader::db(); $db->setDebug(true);
I was surprised myself, but it's pretty normal for a modern CMS or web application.
Thank you Mesuva. I have run into another problem, now none of my images show up and the header images says image not found. Any suggestions?
Hi there. Just 2c here - as i have been struggling with a problem that showed all symptoms described here and hopefully my findings will help somebody (as I was following this thread closely). Everything was as described, except I am working with a Drupal based site. Anyway - was about to throw in a towel when finally found something that allowed to stay with caching enabled as best practices suggest and get the performance on that first page load for authenticated users where there is a lot of DB activity (this is crucial as the site is small and will go periods at a time with visitors - so always has to be warm).
My configuration is VPS with 1G RAM Debian Lenny, MySQL, Apache2 with mod_php and APC enabled. It actually was giving me worst numbers then my current shared hosting plan without APC on that first page load - once was rolling, VPS was a better choice.
What finally did make a difference was 3 things. First two gave 2 fold improvement and worth the money spent on VPS and last one made the site fly. The load time went down from 18-20 seconds on first load (11-12 seconds subsequent) to ~3+ seconds. Anyhow...
1. Shared memory - Debian Lenny comes with a default 32MB (which is way too low). You can verify yours with # cat /proc/sys/kernel/shmax - i have increased mine to 128MB (that is in my case - yours could be different).
2. Main reason I played with shared memory - APC. I am not comfortable with default mmap (have enough RAM, why do i have to use file based cache?) when it is installed via PECL or deb. So, i have downloaded source and built it with a config option --enable-apc-mmap=no Once that was done - restarted Apache (off course one needs to pay attention to APC settings, specifically apc.shm_size).
So shared memory and APC using true RAM did what i needed - connections to warmed up Drupal site (i am also using cron to load and refresh caches) were without delays.
3. Not sure if any help here, but using Drupal6 and cache_backport with apc modules made the site just fly afterwards.
Hopefully these bit of info might help somebody struggling with the same issue.
My configuration is VPS with 1G RAM Debian Lenny, MySQL, Apache2 with mod_php and APC enabled. It actually was giving me worst numbers then my current shared hosting plan without APC on that first page load - once was rolling, VPS was a better choice.
What finally did make a difference was 3 things. First two gave 2 fold improvement and worth the money spent on VPS and last one made the site fly. The load time went down from 18-20 seconds on first load (11-12 seconds subsequent) to ~3+ seconds. Anyhow...
1. Shared memory - Debian Lenny comes with a default 32MB (which is way too low). You can verify yours with # cat /proc/sys/kernel/shmax - i have increased mine to 128MB (that is in my case - yours could be different).
2. Main reason I played with shared memory - APC. I am not comfortable with default mmap (have enough RAM, why do i have to use file based cache?) when it is installed via PECL or deb. So, i have downloaded source and built it with a config option --enable-apc-mmap=no Once that was done - restarted Apache (off course one needs to pay attention to APC settings, specifically apc.shm_size).
So shared memory and APC using true RAM did what i needed - connections to warmed up Drupal site (i am also using cron to load and refresh caches) were without delays.
3. Not sure if any help here, but using Drupal6 and cache_backport with apc modules made the site just fly afterwards.
Hopefully these bit of info might help somebody struggling with the same issue.
The shmax value of 32mb in debian is per shared memory block. It is however perfectly possible to use multiple 32mb blocks.
For example I have configured my apc installation to use 4 blocks of 32mb which will give me 128mb as well.
Unfortunately with concrete installs this doesn't seem to help me when caching is enabled. Disabling cacheing seems to give a much more consistant page load time (overall faster than with caching on)
I do have to add this is concrete 5.4.1.1 I have this experience with. Haven't tried the caching mechanism in concrete 5.4.2 yet.
For example I have configured my apc installation to use 4 blocks of 32mb which will give me 128mb as well.
Unfortunately with concrete installs this doesn't seem to help me when caching is enabled. Disabling cacheing seems to give a much more consistant page load time (overall faster than with caching on)
I do have to add this is concrete 5.4.1.1 I have this experience with. Haven't tried the caching mechanism in concrete 5.4.2 yet.
i check it, yes its slow on the first pageload
compare to this one
http://www.cityhelse.dk/
that slideshow is sure heavy..
well i test that slideshow in IE6, and it's to bloaded, always refreash page. You can see in CPU usage. hope there is better simple slideshow and do not include jquery if you don't need it
well, that just my opinion