Ard Schrijvers wrote:
Vadim,
I think you are reasoning from a POV of the cocoon cache, but I think you are
in the minority compared to the number of users which are using EHCache.
Yes because it is stable and works better and at the time I last looked into it
JCS was really not an option (it was working with O(n) complexity at the time),
and EHCache was not completely implemented (as it still the case).
Configurable Store registration with StoreJanitor alleviates somewhat that
problem, but not solves completely as you still have to properly configure all
your cache sizes correctly to avoid OOM.
I think you can try combining Cocoon's MRU cache and EHCache to get best of both
worlds.
I tried to explain the inevitable OOM of the StoreJanitor in combination of
EHCache and
the event registry in a high volume site.
That's only highlights that current cocoon default config is not a viable
option.
--------o0o--------
2) use a different store for repository binary sources
which has only a disk store part and no memory part
(cached-binary: protocol added)
Doesn't it result in some frequently used binary resource
always read from the disk?
not because as you said, if you also use Apache HTTPD for binary files *and* a reader with expires.
I would be surprised to have a 1.000 concurrent users hitting ctrl-f5 at a large binary at the same time :-)
Gotcha.
3) use a different store for repository sources then for pipeline
cache
Hm, what are the benefits?
because my repository sources are expensive compared to pipeline cache entries. If
people do not construct proper pipelines, the pipeline cache entries can flood the cache.
True.
By using a different store for my repository sources, I make sure, wrong
constructed pipelines
do not harm me by evicting expensive repository sources.
I doubt that it is possible at all to make any programming system robust enough
to withstand bad code. You can try though.
Do realize that I am talking about high volume sites with many visitors and
editor running live.
Of course. You don't need caching for low volume sites anyway ;)
Vadim
