(SOLVED) CPU Overload on Modx high traffic content update

Hi,
When we have Peaks of traffic on our website with hundreds of viewers at the same time - when we log in to manager and update, edit, or do almost anything our CPU goes very high and sometimes causing the server to crash.
While not logged in to manager everything works perfectly fine and cpu is Normal, also - when there is no Peak everything is fine as well.

Since it is a news website we sometimes need to update content immediately while there are a lot of viewers currently on the website.

Using Latest Modx 2.2.9

Is it a problem with the cache settings? server setup? any suggestions?

Again this only happens when there is a peak of traffic and we login to manager and create/update content.

Thank you


[ed. note: yaronyo last edited this post 10 years, 8 months ago.]

Depending on what kind of traffic levels you are talking about, this is likely a problem with optimizing your site to respond to uncached page requests fast enough to handle the traffic you are expecting. If you are going to be publishing during these peak traffic times, then your uncached page loads must be able to respond fast enough not to block the incoming traffic. If an uncached page takes 5 seconds to generate, and you are getting 5 requests per second for that page, you will have 25 visitors all attempting to regenerate the page cache at the same time, because until that first process builds the page and caches it to file, it does not exist in the cache. You can see how this can quickly get out of hand.

Content that is frequently published should really be stored separately from the site model in MODX and delegated to a few Resources that provide dynamic views into those content items. These views can then handle their own caching of the frequently published content. Ultimately, you do not want to clear your entire web site cache because you published a new news article or modified an existing one, especially in high-traffic sites.

That said, regardless of what kind of traffic levels you are talking about, it really should not be able to crash your server. If properly configured and tuned, a server should stop responding to requests before it crashes the database, web server and/or PHP processes. However, that takes quite a bit of knowledge and work to setup optimally and does little to improve your user experience other than allow it to automatically recover after peak periods make it partially unavailable to unlucky visitors.

I think I understand the problem
Right now we are just not logging in to manager when traffic is at Peak but that is not a good solution.
For example - If we have over 600 current viewers on the website at the same time and login to the manager and edit something the CPU rises and rises to over 80 until the website stops working, when we log out it gradually goes back down to below 1. This does not happen when there are below 400 Viewers.

Is there something we can do with the cache system settings that will help?
Where do you suggest we start in order to get this working properly as soon as possible? any reference to what you said about separating and views?

Thanks for your reply

check out:

refreshCache
xfpc

Interesting... Will give it a try and let you know what happens

Than you!

Hi,
Just Started trying out xfpc and seems that it is helping - still need to try it out on Peak time - will do soon.
One thing I noticed is these errors ever since I installed the plugin. How do I fix this?

(ERROR @ /core/cache/includes/elements/modplugin/15.include.cache.php : 106) PHP warning: Cannot modify header information - headers already sent by (output started at /core/model/modx/modresponse.class.php:189)

Thank You

It would be helpful to know more about the server and the website itself. If you are using phpthumb to generate thumbnails for example that could also be part of the problem. It could also be that your server isn't configured to handle higher connection loads, and adjusting the connection requirements of your site could resolve the problem. Every file loaded for your site is one connection request (css, js, the page itself, images, etc).

You could also look into using a frontend proxy either on or off server, in the case of an off server proxy CloudFlare is a great option. Again this all comes back to your site and server configuration as to what would work best.

You can also check out http://devries.jp/blog/2013/03/23/cash-in-big-with-modx-cacheing/ which has some great tips on caching.

In regards to the xFPC error, you can find it discussed more here: http://forums.modx.com/thread/?thread=80377&page=3 I am unaware of any solution. I suspect the code needs to be re-factored, but am unable to find a location to report any bugs on it.

Quote from: yaronyo at Sep 11, 2013, 03:01 PM

I think I understand the problem
Right now we are just not logging in to manager when traffic is at Peak but that is not a good solution.
For example - If we have over 600 current viewers on the website at the same time and login to the manager and edit something the CPU rises and rises to over 80 until the website stops working, when we log out it gradually goes back down to below 1. This does not happen when there are below 400 Viewers.

Is there something we can do with the cache system settings that will help?
Where do you suggest we start in order to get this working properly as soon as possible? any reference to what you said about separating and views?

Thanks for your reply

You might try the CacheMaster extra. When you save a resource in the Manager, MODX normally clears the entire resource cache, which slows down the site and results in a lot of extra DB calls as people visit pages and the cache is rebuilt. With CacheMaster, only the cache for the resource you're saving is cleared.

http://bobsguides.com/cachemaster-tutorial.html

Note that if you're doing something like using a cached getResources call on cached page, that page may be out of date with this method and new Resources may not show up in menus right away (unless you check the "Empty Cache" checkbox when you save them).

Hi,
So I gave xFPC a try - did speed up the site a bit but did not solve anything and gave me errors that i couldn't get rid of so turned it off for now.
Regarding Cachemaster - I tried this as well which showed me that the problem must be connected to the cache clearing on high traffic (a lot of connection requests).
The problem with cachemaster like you stated - our website uses getresources a lot on the home page and most other pages - all cached, so uploading a report and not seeing it on the home page does not solve it as well.. should I use cachemaster and call the getresources calls uncached on places that should always be up to date (a lot of places)? will the cache eventually clear itself? When?

Maybe it also has something to with DirectResize Revo plugin when clearing cache? - Does it clear all the images cache and regenerates them which contributes to the overload?

It could also be that our server is not configured correctly, or maybe there is a configuration that will prevent the overload somehow but will still clear all the cache?

This is the basic info:
Website - http://goo.gl/nh9FUQ
Using latest modx version - MODX Revolution 2.2.9-pl (traditional)
Server:
Our server has 8 processors of:
Intel(R) Xeon(R) CPU X5650 @ 2.67GHz
Speed 2660.000 MHz Cache 12288 KB

8 Gig Ram Memory

System:
Linux
mysql 5.1.66-cll
php 5.3.24
pdo enabled

What further info can help for you to examine the server configuration?

Thank You very much for your help

Anything dealing with images can bring a server to its knees. I'd recommend focusing on your image manipulation plugins and snippets.