Preparing for a HUGE traffic spike. Help.
Permalink
We had a 3rd party vendor build a site for us on concrete5. It works fine and I'm managing it now. My organization is having a HUGE online event soon. It's not, but lets just pretend it's the Superbowl. We need to prepare our site for a massive traffic spike and make sure the site/database doesn't crash. We have no idea what numbers to expect but we could see 10,000 visitors in just a few minutes.
We are about to have our IT people do some load testing on the server, but what steps should be taken within Concrete5 to prepare our site? I've already got caching enabled. Would "Emergency Cache Mode" more or less bypass the database stress? Other than preparations on our server, is there anything else to do within Concrete5?
---------------------
RELATED 2ND QUESTION:
There will be one particular page, other than the homepage, that will garner the most traffic. Would it be better for us to create this 2nd page as a static HTML page on the server, OUTSIDE OF CONCRETE5? Would that help lessen the burden on our entire the system? And if so, is there a "safe" location on the server where I should place such a static page file, or will I be fine as long as I use a unique page name in the root directory?
Thanks!
We are about to have our IT people do some load testing on the server, but what steps should be taken within Concrete5 to prepare our site? I've already got caching enabled. Would "Emergency Cache Mode" more or less bypass the database stress? Other than preparations on our server, is there anything else to do within Concrete5?
---------------------
RELATED 2ND QUESTION:
There will be one particular page, other than the homepage, that will garner the most traffic. Would it be better for us to create this 2nd page as a static HTML page on the server, OUTSIDE OF CONCRETE5? Would that help lessen the burden on our entire the system? And if so, is there a "safe" location on the server where I should place such a static page file, or will I be fine as long as I use a unique page name in the root directory?
Thanks!
Thanks. I'll look into those other suggestions too, but I was confused by the 5.5 version. First, I can't actually find where my version is displayed. But under System & Maintenance > Update it says to download the update "Version: 5.4.2.1. Release Date: August 31, 2011". I'm used to WordPress (and Drupal to a lesser degree) where it will always display the latest available version. This would make me think that 5.4.2.1 is the latest version, but you're saying that 5.5 (or higher) is out. That has me a little confused.
Also, (in general because I know I can search the forums) how is upgrading done. Again with WordPress, I'm used to a one-button automatic upgrade (after backing up of course). The text about downloading sounds like this is not an automatic process.
Also, (in general because I know I can search the forums) how is upgrading done. Again with WordPress, I'm used to a one-button automatic upgrade (after backing up of course). The text about downloading sounds like this is not an automatic process.
it is usually a one click deal. but 5.5 is beta so far, so you need to upgrade manually. seehttp://www.concrete5.org/documentation/how-tos/developers/update-ve...
That's a really hard question to answer. Much will depend on the server specification, how it's been configured etc. You also don't say if you are using caching libraries like APC or Memcache. If not you probably should consider them.
Re the 2nd question, you shouldn't need to do this, but to answer the point a real file will get served wherever you put it in the public root.
Re the 2nd question, you shouldn't need to do this, but to answer the point a real file will get served wherever you put it in the public root.
If this is stuff that I would see under "Add Functionality" then no, I see noting installed that has the word Cache in it. (Something called "SQL Buddy 1.0"under Packages, and then a bunch of "Core Block Types" too.) Do these improve upon the default caching system?
Ollie is referring to something that isn't available as an installable package - to use APC or Memcached, you would need to have them available on the server (something the host sets up) and then you manually edit your /config/site.php files.
In particular you would place:
or
after the rest of your config settings. If the cache library you choose isn't available, your site will error straight away.
I've not used apc, but I use a host with memcached and it makes a noticeable improvement to speed.
In particular you would place:
define('CACHE_LIBRARY', 'apc');
or
define('CACHE_LIBRARY', 'memcached');
after the rest of your config settings. If the cache library you choose isn't available, your site will error straight away.
I've not used apc, but I use a host with memcached and it makes a noticeable improvement to speed.
My thinking with this is that if you are going to receive VERY large amounts of traffic, serving content from static files is the way to go.
Although I'm imagining the full page caching would help greatly, and optimising resource is important, there is still the overhead of the server having to process the request through PHP, loading up many libraries and resources. I'm thinking about processor time and memory usage here.
One thing I can offer is a small extra caching system that I whipped up (based on an existing file caching system). I actually released it many months ago but it was more an experiment so it was pretty flakey. Recently I reworked much of it, fixed lots of bugs and now I'm using it on three production sites very successfully. I get static-like speeds.
In essence it wraps around c5, and serves cached files of pages. It's as close to static as it can be (I think) while still being able to use and edit the system as normal. I think that if this couldn't handle the traffic, than the server/bandwidth is more the concern. I've used it more to speed up sites that are running on slower servers, but the thinking is the same.
http://www.mesuva.com.au/blog/technical-notes/an-extra-cache-for-co...
(I have tested this on 5.4.2.2, but not 5.5)
Although I'm imagining the full page caching would help greatly, and optimising resource is important, there is still the overhead of the server having to process the request through PHP, loading up many libraries and resources. I'm thinking about processor time and memory usage here.
One thing I can offer is a small extra caching system that I whipped up (based on an existing file caching system). I actually released it many months ago but it was more an experiment so it was pretty flakey. Recently I reworked much of it, fixed lots of bugs and now I'm using it on three production sites very successfully. I get static-like speeds.
In essence it wraps around c5, and serves cached files of pages. It's as close to static as it can be (I think) while still being able to use and edit the system as normal. I think that if this couldn't handle the traffic, than the server/bandwidth is more the concern. I've used it more to speed up sites that are running on slower servers, but the thinking is the same.
http://www.mesuva.com.au/blog/technical-notes/an-extra-cache-for-co...
(I have tested this on 5.4.2.2, but not 5.5)
5.4.2.2 is the latest STABLE verion. 5.5 is out, but it's a significant update and lots of things have changed (in particular the interface).
I would personally aim to stick with 5.4.2.2 until 5.5.1 comes out for bug fixes. It's pretty safe to update the system to 5.4.2.2, but for 5.5 you'd want to do a lot of testing offline first, as plugins you have installed may need to be updated as well.
With the update process there are two ways to go about it - the automatic approach is available when you go into the dashboard, sitewide setting and then 'connect to the community'. Once that is set up, you should get one click style auto-updating of c5 and the plugins you've installed.
The other approach is a manual update - it's pretty easy. You just download the new version and follow these instructions:
http://www.concrete5.org/community/forums/installation/is-it-save-t...
(check the link in this thread, plus my post where I try and be very specific)
I would personally aim to stick with 5.4.2.2 until 5.5.1 comes out for bug fixes. It's pretty safe to update the system to 5.4.2.2, but for 5.5 you'd want to do a lot of testing offline first, as plugins you have installed may need to be updated as well.
With the update process there are two ways to go about it - the automatic approach is available when you go into the dashboard, sitewide setting and then 'connect to the community'. Once that is set up, you should get one click style auto-updating of c5 and the plugins you've installed.
The other approach is a manual update - it's pretty easy. You just download the new version and follow these instructions:
http://www.concrete5.org/community/forums/installation/is-it-save-t...
(check the link in this thread, plus my post where I try and be very specific)
is the event already done ?
and what is your result ?
if not yet please look at 5.5.0 which I read more stable than 5.5.1
and what is your result ?
if not yet please look at 5.5.0 which I read more stable than 5.5.1
The event is February 1st, so no final results. But we did some load testing. First we installed APC. Here were our results, but bear in mind that this is highly dependent on our specific server configuration.
<< from IT >>
I was able to get a maximum of 14.5 requests per second out of any page on the site. This is a reasonable but fairly slow rate of service.
I tested from 10 up to 250 concurrent connections.
[graphic of results attached]
As you can see, the number of concurrent sessions is the main important variable here.
Important things to note:
• Requests started to fail at 200 concurrent requests, and failed at a rate of about 1% (23/2000) at 250 concurrent requests.
• At 200 concurrent requests, each request averaged 15 seconds to complete.
• At 250 concurrent requests, the average doubled to 30 seconds.
• The longest request more than tripled from 40 seconds to 155 seconds between 160 and 200 concurrent connections.
• The CPU usage of the server stayed low throughout.
Conclusions:
• The server can handle a reasonably high load of concurrent requests.
• You can expect the site to slow down significantly under high load but I do not expect it to crash.
• Page loads seem slow, but are consistent with what others have found using Concrete5. (8-15 requests per second.)
<< end IT >>
What we decided to do was to spread the load out, by having the main page that most traffic should end up on, be served on a different server, created only in basic HTML (no CMS, no PHP). Concrete5 will still get a ton of traffic but the "event page" will be independent. We'll see on February 1 how well it all works out.
<< from IT >>
I was able to get a maximum of 14.5 requests per second out of any page on the site. This is a reasonable but fairly slow rate of service.
I tested from 10 up to 250 concurrent connections.
[graphic of results attached]
As you can see, the number of concurrent sessions is the main important variable here.
Important things to note:
• Requests started to fail at 200 concurrent requests, and failed at a rate of about 1% (23/2000) at 250 concurrent requests.
• At 200 concurrent requests, each request averaged 15 seconds to complete.
• At 250 concurrent requests, the average doubled to 30 seconds.
• The longest request more than tripled from 40 seconds to 155 seconds between 160 and 200 concurrent connections.
• The CPU usage of the server stayed low throughout.
Conclusions:
• The server can handle a reasonably high load of concurrent requests.
• You can expect the site to slow down significantly under high load but I do not expect it to crash.
• Page loads seem slow, but are consistent with what others have found using Concrete5. (8-15 requests per second.)
<< end IT >>
What we decided to do was to spread the load out, by having the main page that most traffic should end up on, be served on a different server, created only in basic HTML (no CMS, no PHP). Concrete5 will still get a ton of traffic but the "event page" will be independent. We'll see on February 1 how well it all works out.
1) enable full page caching. that should speed up the site.
2) upgrade to 5.5. it has some huge speed improvements.
3) consider installing a speed booster. if its a non commercial site, try miserhttp://www.concrete5.org/community/forums/customizing_c5/miser-web-... if not, then try my solutionhttps://github.com/12345j/Tinifier-Concrete5-Optimiser...
4) you shouldn't need to go to static html if the full page cache is on. if you feel like you do though for some reason,http://www.concrete5.org/community/forums/installation/concrete5-wi... will probably help.