Hi Upayavira,No, the check-ins don't fix it. CLI now uses the store ('cos now that Vadim has fixed it, it has to!), but the persistent store seems to take 10 times as long as the MRU store, and about the same amount of time as actually generating the page without caching.
I saw that you checked in some changes to the CLI using the Persistence store. Are the problems desribed below solved?
If not, I had a RT when reading your mail: What about an external memory store for CLI operations?
Regards, Upayavira
-----Original Message-----
From: Upayavira [mailto:[EMAIL PROTECTED] Sent: Saturday, August 16, 2003 4:16 PM
To: [EMAIL PROTECTED]
Subject: Persistent store seems slow
In looking into the caching system for the CLI, I found the fact that the caching system wasn't being correctly written to disc on shutdown.
Vadim fixed that.
So one would therefore expect pages that have been placed in the persistent store to be generated faster than previously, as page generation is no longer required - just reading from the cache.
However, this does not seem to be the case. From my investigations (by adding code to the CLI to report the duration spent generating each page), it seems that page generation is now _slower_, when the page has been put into the persistent store :-(
I notice that, in a pipeline that involves aggregation and the cocoon: protocol, you get multiple reads from the cache. Presumably only the last is actually used.
This is a very unfortunate response, as I was looking forward to the 10x performance improvements that the MRUMemoryStore offers!
Is there likely to be anything I can do to speed up the persistent store?
Would it be possible to just get the last modified date from the cache without the content, as in fact that is all I really want.
Hope you guys can help.
Regards, Upayavira
