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 really sure. But, I suspect(ed...i am in doubt now :-) ) > the writing mainly because it seems to be only happening on Windows > machines. While profiling, I see a lot of cpu time in > > org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevel > CachePageMap.put(Page) > > See http://people.apache.org/~ard/cpu-profile.html > > There I have 2 times > > org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevel > CachePageMap.put(Page) > > One of 47% and one of 42%. But, as indicated, this very well might all > just be the serialization part (I now also see some time spend in > logging for undetached models, oooppsss). Perhaps I was to early with my > conclusion, but still do not get why Linux machines do not seem the > suffer from this behavior. Anyway, if it would be the serialization > only, and not the writing, I would be seeing the (almost) same > statistics for the Terracotta in memory page store, right? > >> profiled this a lot and the serialization takes >> signifficantly more time than writing the stuff to disk. But >> the serialization is necessary, plus the overhead is there >> only until you run your application in clustered environment. > > The overhead of serializing is only there when running clustered? The > 'page back' functionality also uses it, isn't, so I thought it wasn't > only for clustered environments (and then specifically for clustering > without sticky sessions, right?) That's not quite what I meant. First it is strongly recommended to use sticky sessions when using wicket on cluster. Without sticky sessions you have to use redirect to render (instead of redirect to buffer) and that certainly won't help your performance.
Also on cluster you probably want to have failover (must have if you don't use sticky sessions). In that case the changes needs to be distributed across cluster. Thus the page must be serialized. Wicket reuses the serialized data from the serializaton is diskpagestore so on cluster the page is only serialized once (instead of twice - once in diskpagestore and for session replication). -Matej > > -Ard > >> >> -Matej >> >> > Regards Ard >> > >> >> Serialization takes a significant part of request processing, but >> >> that is necessary. >> >> >> >> -Matej >> >> >> >> On Fri, Oct 3, 2008 at 3:21 PM, 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 >> >> > happens to be quite a large cpu bottleneck for Windows >> users AFAICS. >> >> > >> >> > So, before starting to implement one, just wondering >> >> whether somebody >> >> > has experience on a memory page store version, >> >> > >> >> > Thx for any pointers, >> >> > >> >> > Regards Ard >> >> > >> >> > [EMAIL PROTECTED] - [EMAIL PROTECTED] - www.onehippo.com >> >> > ------------------------------------------------------------- >> >> > Amsterdam - Hippo B.V. Oosteinde 11 1017 WT Amsterdam >> >> +31(0)20-5224466 >> >> > San Francisco - Hippo USA Inc. 101 H Street, suite Q Petaluma CA >> >> > 94952-3329 +1 (707) 773-4646 >> >> > ------------------------------------------------------------- >> >> > >> >> > >> >> >> --------------------------------------------------------------------- >> >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> > For additional commands, e-mail: [EMAIL PROTECTED] >> >> > >> >> > >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> > >> > >> --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
