Caching, page reloads, and better ways to keep content from recompiling on less trafficed sites

Next topic

Author	Message
Jonathan Dillon-Hayes	Monday 28 March 2005 2:10:47 am Hey all: Just to repond to the question about why a site was slow for a client that appeared here some weeks back. We took a look at the issue for this client... The problem is a common one with sites that don't get a great deal of traffic. The site's cache was expiring as it was sometimes quite a long time between page loags. Therefore when you first hit the page, it was very, very slow while it recompiled the page (2-3 second delay). When a request comes in to eZ Publish, it compares the date on the server with the date on the document. If it's older than a few minutes it will rebuild the page for you. This is a common problem. In order to eliminate the problem, we simply pointed a cron lynx entry to the home page so that it would stay "fresh" in the eZ Cache. This is a very easy way to get around the problem. On a busy production website, these pages would not expire. In some cases (like for example, news sites, where the content changes only periodically), it's also possible to do a cache like squid or the like. Another interesting thing I found while working on this problem... I was working on a site when all of the sudden the CPU usage spiked despite my doing nothing. Curious, I started watching the logs. It turned out there was some kind of spider walking the tree on some uncached (old, not very popular) content on the site I was working on, and it was causing eZ to go absolutely crazy trying to generate those requests. It was very interesting. On really broad, deep, or old sites, I wonder how much of a concern this could be. I mean, you could get really killed if this happened on a really HUGE site with a multithreaded aggressive spider. Is there a better way to do this with internal eZ configuration? J --------- FireBright provides advanced eZ deployment with root access http://www.FireBright.com/
Bård Farstad	Wednesday 20 April 2005 2:48:58 am Jonathan, the expiry can indeed be a problem in some configurations. I guess that the new static cache features would fit the sites you are describing perfectly. Using this technique you have a pure HTML version of the page stored on disk. This will be served directly from Apache until the page is re-published and content is changed. The static cache does not work on personalized content though. As all users get the same page, but for many sites this is just fine. --bård Documentation: http://ez.no/doc

Author

Message

Monday 28 March 2005 2:10:47 am

Hey all:

Just to repond to the question about why a site was slow for a client that appeared here some weeks back. We took a look at the issue for this client...

The problem is a common one with sites that don't get a great deal of traffic. The site's cache was expiring as it was sometimes quite a long time between page loags. Therefore when you first hit the page, it was very, very slow while it recompiled the page (2-3 second delay).

When a request comes in to eZ Publish, it compares the date on the server with the date on the document. If it's older than a few minutes it will rebuild the page for you.

This is a common problem. In order to eliminate the problem, we simply pointed a cron lynx entry to the home page so that it would stay "fresh" in the eZ Cache. This is a very easy way to get around the problem. On a busy production website, these pages would not expire.

In some cases (like for example, news sites, where the content changes only periodically), it's also possible to do a cache like squid or the like.

Another interesting thing I found while working on this problem... I was working on a site when all of the sudden the CPU usage spiked despite my doing nothing. Curious, I started watching the logs. It turned out there was some kind of spider walking the tree on some uncached (old, not very popular) content on the site I was working on, and it was causing eZ to go absolutely crazy trying to generate those requests. It was very interesting. On really broad, deep, or old sites, I wonder how much of a concern this could be. I mean, you could get really killed if this happened on a really HUGE site with a multithreaded aggressive spider.

Is there a better way to do this with internal eZ configuration?

---------
FireBright provides advanced eZ deployment with root access
http://www.FireBright.com/

Bård Farstad

Wednesday 20 April 2005 2:48:58 am

Jonathan,

the expiry can indeed be a problem in some configurations. I guess that the new static cache features would fit the sites you are describing perfectly. Using this technique you have a pure HTML version of the page stored on disk. This will be served directly from Apache until the page is re-published and content is changed.

The static cache does not work on personalized content though. As all users get the same page, but for many sites this is just fine.

--bård

Documentation: http://ez.no/doc