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
