Re: AbstractPageStore memory implementation instead of disk

2008-10-31 Thread Eelco Hillenius
Ok, I think I get it :-) One more questionL if I would have sticky sessions, and no page back functionality, would I still need wicket to serialize? Technically not, if you really don't need page back functionality (are you sure you can enforce that?), than it would suffice to just have the

Re: AbstractPageStore memory implementation instead of disk

2008-10-10 Thread Matej Knopp
On Wed, Oct 8, 2008 at 10:30 AM, Ard Schrijvers [EMAIL PROTECTED] wrote: Hello, Again, serialization and writing to filesystem are two completely different things. Are you *really* sure that the writing (which is done in separate thread btw) is really the bottleneck? I have No, I am not

RE: AbstractPageStore memory implementation instead of disk

2008-10-08 Thread Ard Schrijvers
Hello, Again, serialization and writing to filesystem are two completely different things. Are you *really* sure that the writing (which is done in separate thread btw) is really the bottleneck? I have No, I am not really sure. But, I suspect(ed...i am in doubt now :-) ) the writing mainly

RE: AbstractPageStore memory implementation instead of disk

2008-10-07 Thread Ard Schrijvers
Hello Igor and Timo, Sorry for my really way to late response, I was caught up entirely by some stressful tasks which needed to be finished. I currently do not have statistics, but I could have a cpu yourkit snapshot. I have seen up to 75% cpu in the serialization and deserialization. Recently

RE: AbstractPageStore memory implementation instead of disk

2008-10-07 Thread Ard Schrijvers
Thanks a lot Richard, I will take a look! Regards Ard The wicket integration with terracotta uses an in-memory page map. The code is here, but will soon be part of the terracotta wicket-tim. http://www.nabble.com/file/p19826206/TerracottaPageStore.java TerracottaPageStore.java

RE: AbstractPageStore memory implementation instead of disk

2008-10-07 Thread Ard Schrijvers
Hello Matej, I'd really be interested in how exactly did you come to conclusion that DiskPageStore writing to disk is the bottleneck. Unless your filesystem caching is broken :) Hmmm, don't think the filesystem cache is broken. I am working with filesystem caches and lucene a lot and don't

Re: AbstractPageStore memory implementation instead of disk

2008-10-07 Thread Johan Compagner
but serialization and writing to disk are 2 different things. On Tue, Oct 7, 2008 at 4:21 PM, Ard Schrijvers [EMAIL PROTECTED]wrote: Hello Igor and Timo, Sorry for my really way to late response, I was caught up entirely by some stressful tasks which needed to be finished. I currently do

RE: AbstractPageStore memory implementation instead of disk

2008-10-07 Thread richardwilko
I should say that the terracotta page map also does the page serialisation, but it does it all in memory. You could probably write out the serialisation bit quite easily, but it is required for terracotta. Ard Schrijvers-3 wrote: Thanks a lot Richard, I will take a look! Regards Ard

RE: AbstractPageStore memory implementation instead of disk

2008-10-07 Thread Ard Schrijvers
but serialization and writing to disk are 2 different things. Yes sorry for the confusion. I intertwine the serialization and disk performance (hence asking whether a memory page store exists) because AFAIU, it is the serialized pagemaps that are being written to filesystem. Indeed, when using

RE: AbstractPageStore memory implementation instead of disk

2008-10-07 Thread richardwilko
The HttpSessionStore is an in memory session store, so it has no disk writing bottleneck. It does however have some other problems, specifically with the back button i think. the terracotta page store works like this: protected ISessionStore newSessionStore() { return

RE: AbstractPageStore memory implementation instead of disk

2008-10-07 Thread Ard Schrijvers
Great, I'll check out the code for the TerracottaPageStore, Thanks a lot Richard, Regards Ard The HttpSessionStore is an in memory session store, so it has no disk writing bottleneck. It does however have some other problems, specifically with the back button i think. the terracotta

Re: AbstractPageStore memory implementation instead of disk

2008-10-07 Thread Matej Knopp
On Tue, Oct 7, 2008 at 4:24 PM, Ard Schrijvers [EMAIL PROTECTED] wrote: Hello Matej, I'd really be interested in how exactly did you come to conclusion that DiskPageStore writing to disk is the bottleneck. Unless your filesystem caching is broken :) Hmmm, don't think the filesystem cache is

Re: AbstractPageStore memory implementation instead of disk

2008-10-05 Thread richardwilko
The wicket integration with terracotta uses an in-memory page map. The code is here, but will soon be part of the terracotta wicket-tim. http://www.nabble.com/file/p19826206/TerracottaPageStore.java TerracottaPageStore.java Timo Rantalaiho wrote: On Fri, 03 Oct 2008, Igor Vaynberg wrote:

Re: AbstractPageStore memory implementation instead of disk

2008-10-05 Thread Matej Knopp
I'd really be interested in how exactly did you come to conclusion that DiskPageStore writing to disk is the bottleneck. Unless your filesystem caching is broken :) Serialization takes a significant part of request processing, but that is necessary. -Matej On Fri, Oct 3, 2008 at 3:21 PM, Ard

Re: AbstractPageStore memory implementation instead of disk

2008-10-03 Thread Igor Vaynberg
do you have some statistics for us? or some profiler timing screenshots? -igor On Fri, Oct 3, 2008 at 6:21 AM, Ard Schrijvers [EMAIL PROTECTED] wrote: Hello everybody, Did anybody perhaps ever implement a memory version of the AbstractPageStore. Currently, I only see a DiskPageStore, which

Re: AbstractPageStore memory implementation instead of disk

2008-10-03 Thread Timo Rantalaiho
On Fri, 03 Oct 2008, Igor Vaynberg wrote: do you have some statistics for us? or some profiler timing screenshots? While waiting for the reply from Ard... I remember hearing of a case where the pagemaps were stored to a directory that the virus scanner was monitoring, and the scanner hogged all