Is Revo OK for >1.000 Visitors/h?

Is Revo OK for >1.000 Visitors/h? We use Revo 2.1.3-pl and on having more than 1.000 Visitors/h for example after sending out a newsletter-mailing and save at this time a resource our modx-installation gets in trouble. Often it is ending in errors like this:

and


If we do not save a resource while we have lots of traffic on our sites everything runs perfectly.

Is there anything we can check in our settings which could be responsible for these problems? Maybe a certain cache-setting?

Or is there any diagnostic tool which we can use to find out the problem? Or is Revo on principle not the best choice for high-traffic-sites?

Letti [ed. note: lettis last edited this post 14 years, 10 months ago.]

This actually sounds like it might be an issue in your environment, specifically regarding the MySQL client/server. See http://bugs.mysql.com/bug.php?id=28359 for some clues on what might be going on.

MODX can be used for high traffic sites, though a typical dedicated server might only be able to handle 25 to 75 simultaneous connections. So if you are peaking at more than 50 requests per second, you might consider a more robust environment with proper load balancing and custom cache configurations.

Our phpinfo() says:

apache2handler
Timeouts Connection: 15 - Keep-Alive: 5

Are these the values you pointed out? If yes these values are much less than 50. Do you think we have to talk to our company which is responsible for our "dedicated server managed-product" and change these values?

It's not a PHP problem or even an Apache problem, it's a MySQL problem. You have three systems interacting to serve the pages being requested, Apache to receive and serve the pages, the PHP interpreter to handle the PHP code generating the page to be served, and the MySQL database to respond to PHP's queries for the data required to generate the page. With that heavy a load, especially the MySQL engine needs to be tuned, and various caching features need to be optimized - not just the MODx cache, but other server-side caching options, especially query optimization and caching.

http://dev.mysql.com/doc/refman/5.0/en/query-cache.html

When you save a resource, the MODx cache is cleared for all pages, and that means that menus and getResources calls all have to be run again, fetching the updated structures from the database. Revo is pretty flexible, but I'm just getting started working with it and I'm not sure if it's possible to just clear certain caches; for example if a new blog post only requires the getResources call creating the blog list to be re-run but not menus and getResources calls for other areas of the site? Could the blog be run in its own context, so updates to it would only refresh the caches for its context?

While storing the SESSION in the database rather than in files has advantages, with such a busy site and heavy load on the MySQL engine, you might want to consider storing the SESSION in files, since ever single page load must fetch the SESSION fresh from the database or the files for every page request for every user.

http://www.binarysludge.com/2011/01/13/redundant-and-fault-tolerant-php-session-storage/
http://php.net/manual/en/function.session-set-save-handler.php [ed. note: sottwell last edited this post 14 years, 10 months ago.]

I'm going to second the above, this is more an environment issue than a MODX issue. If you are currently using a Dedicated server you may want to add a second functioning as a database server.

It's hard to make configuration suggestions without the server stats, but you may want to look into running memcache and/or varnish to help lighten the load. If the pages can be served from cache instead of hitting the database that will help.

If you have munin installed on the server you could use it to evaluate where the "limits" are coming into play and making changes accordingly.

You may also want to consider using something like MailChimp to deliver your newsletter, or if you prefer a self hosted solution, you could setup a small vps server to handle the newsletter functionality. It could double as a backup server (as in backups not failover) to prevent "wasting" resources.