Thanks for the detailed description! I have uploaded a fix at: http://issues.ez.no/17096
This is pending internal review. Gunnstein On Wed, Aug 11, 2010 at 9:51 PM, Peter Keung <[email protected]> wrote: > Hi SDK, > > We've experienced the same cache problem on two large eZ DFS cluster > setups. The first request for a page loads successfully and quickly but > subsequent requests take a long time to respond. Then another page will > be quickly loaded, but subsequent requests again hang. This cycle only > needs to repeat a few times until server performance is severely > affected and a busy server will crash. > > How to reproduce the problem: > - Make successive page requests to a node that the current user does not > have the permission to view, resulting in an access denied (kernel 1) > error; for example "/users" > or > - Implement a server-side redirect operator within a full view template. > > Analysis: > > The first page request starts cache generation. However, in both of the > above scenarios, it appears that viewcache generation is not properly > completed with a full view of a node. For example, with the server-side > redirect operator, the request is redirected in the middle of viewcache > generation. And the "access denied" page, although is standard eZ > Publish functionality, doesn't seem to conform to what the eZ DFS cache > generation process is expecting. Thus, subsequent page requests are > waiting for a cache file to generate, but that cache file has already > stopped being generated. > > If you inspect the ezdfsfile table, you will find an entry similar to: > > INSERT INTO `ezdfsfile` VALUES > ('var/tao/cache/content/tao/5-9b676f6081843e14c8d5682a3647f38f.cache.generating', > 'var/tao/cache/content/tao/5-9b676f6081843e14c8d5682a3647f38f.cache.generating', > '588803514a4a26a99554e43762fa66cf', , , 0, 1281244184, 0, 0); > > Manually removing that entry solves the problem for one more page load, > but of course, the same entry will return and repeat the hanging cycle > all over again. > > Unsuccessful solutions: > > - Using {cache-ttl} blocks at the top of the full view template to "turn > off" viewcache. This still happens within what I'm calling the > "viewcache context" and thus the problem still occurs. > > - Using ViewCacheTweaks (site.ini), as this is only possible per node > and not feasible to maintain when needed to be applied per section, per > class, and similar. > > - Setting the NonExistantStaleCacheHandling values (file.ini) to > "generate" instead of "wait" appears to have no effect. Even if it did > help, it might affect site performance unintentionally if you only > wanted this setting to apply to certain nodes. > > > Is there a way to forcibly complete or end cache generation in an > operator in those cases within the current eZ DFS setup? > > Otherwise this seems like a critical bug - but we would like to get an > opinion on this before we proceed. > > > Peter > -- > Sdk-public mailing list > [email protected] > http://lists.ez.no/mailman/listinfo/sdk-public > -- Gunnstein Lye Product Support Engineer [email protected] | www.ez.no | eZ Systems -- Sdk-public mailing list [email protected] http://lists.ez.no/mailman/listinfo/sdk-public
