cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gerhard Froehlich" <g-froehl...@gmx.de>
Subject RE: [VOTE] adding Jisp based Store persistence to the Scratchpad
Date Wed, 12 Dec 2001 15:09:58 GMT
Adrian,
>From: Adrian Geissel [mailto:ageissel@zenark.com]
>
>----- Original Message -----
>From: Gerhard Froehlich <g-froehlich@gmx.de>
>To: <cocoon-dev@xml.apache.org>
>Sent: Wednesday, December 12, 2001 2:13 PM
>Subject: RE: [VOTE] adding Jisp based Store persistence to the Scratchpad
>
>
>> Vadim,
>> >From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
>> >
>> >
>> >What would be the benefits of using B-Tree indexed file vs filesystem
>> >directory?
>>
>> - When you have many files in one directory that can be problematic
>> for maintainence.
>> - Some Caching system like Squid split that up into the different
>> subdirectories, others hold the data in one file.
>> - With this Implementation we would be able to turn -if wished-
>> the MRUMemoryStore (or something equal) off and use only the Filesystem
>> for Storing. Maybe for machines with limited memory,.... For this approach
>> you need some speedy access for the data on the FS.
>
>If you are going to persue this thought process, bear in mind that storing
>large numbers of files in a single directory has serious performance
>considerations, unless you are using a specialized file system - I'm
>thinking of ReiserFS (for Linux) which advertises exceptional performance
>both for large numbers of files, especially for files <4k in size.

Yes, you're correct. In the current implementation the Cocoon objects are
serialized down the fs as they are. Zig little files on the filesystem.

To avoid this my idea is (just an idea) to store this objects in one data
file and using indexes to access this file.

>Also, my experience with disk-based caching is that it is inherently slower
>than memory-based, and so should only be used in situations where the data
>either needs to be guaranteed failsafe (QOS-type requirements), or where it
>is known in advance that the data will not be required for some time to
>come. In practice, I expect that it is cheaper and possibly more elegant to
>upgrade the physical memory, especially at current market prices.

That's right. But it uses the same Store Interface, therefor it is a 
elegant (elegant in fs context) alternative to a memory based storing. 
It's up to you using it.

Default this new Jisp based Store will be used combined with the 
MRUMemoryStore!

>Appologies for stepping on toes,

Didn't hurt ;-).

>Adrian

  Gerhard
 
-----------------------------------------------
Consciousness: that annoying time between naps.
-----------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message