|
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/
|
