You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@wicket.apache.org by jamieballing <ja...@hotmail.com> on 2007/09/07 23:52:15 UTC

Disable the SecondLevelPageCache?

We are trying to do some performance troubleshooting and want to disable the
second level page cache.

Is there any way to do this?

Thanks,
Jamie
-- 
View this message in context: http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12563895
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Disable the SecondLevelPageCache?

Posted by Matej Knopp <ma...@gmail.com>.

Hi,

the benchmark was done against a very simple initial FilePageStore
that was rather primitive and didn't attempt to optimize things at
all. It was practically a proof of concept thing only.

Current DiskPageStore uses one file per pagemap and it optimizes the
stuff pretty well. It caches serialized page instances, so that when
you replicate sessions (because of clustering - if you expect very
high load) the page is serialized only once (which reduces the
overhead to secondlevelcachesessionstore almost down to zero in
clustered environment).

-Matej

On 9/9/07, Ryan Holmes <ry...@hyperstep.com> wrote:
> Hi Eelco,
>
> Thanks for the thorough response (as usual). We're almost done
> converting from Tap 4 to Wicket 1.2 and we'll look into migrating to
> 1.3 pretty soon. I was planning on reverting to the HttpSessionStore
> immediately because I assumed the new disk-based store(s) traded
> performance for memory efficiency (and we have the luxury of not
> really caring about RAM usage due to a limited number of users in a
> LAN-only environment).
>
> An old benchmark that Jonathan posted (http://www.jroller.com/
> JonathanLocke/entry/how_fast_is_wicket) suggested the
> HttpSessionStore was noticeably faster, but I know there have been a
> lot of performance improvements since then.
>
> I've been pretty cynical about the whole idea of a disk-based store,
> actually. It always seemed like "jumping a fence" into a servlet
> container/app server's area of responsibility (had a slightly nasty
> argument with Johan about that). While it always sounded like a cool
> and very powerful/useful *option* to build into the framework, I
> never thought it would be a clear winner over HttpSessionStore. My
> main fear was that it would lead to a kind of split between some
> people using one store and some the other, and that it might cascade
> further into the framework (e.g. design x is a better fit with SLCSS
> but design y is better for HttpSessionStore) ultimately becoming a
> big drag for you guys.
>
> So that's a long way of saying: damn, I'm impressed. Not only is
> 1-2ms negligible, it sounds like the SLCSS is a conceptually simpler
> approach. Oh, and sorry to Johan for being a skeptic. ;)
>
> -Ryan
>
> On Sep 8, 2007, at 2:27 PM, Eelco Hillenius wrote:
>
> > On 9/8/07, Ryan Holmes <ry...@hyperstep.com> wrote:
> >> Is it not recommended because the new disk-based session store is
> >> just a better all-around solution or because using the
> >> httpsessionstore is dangerous or broken in some way in 1.3?
> >
> > It is a better all-round solution: it is more efficient memory wise,
> > and the cost of serializing and saving is neglect-able in our
> > experience (like 1 or 2 miliseconds per request even without Matej's
> > recent optimizations). HttpSessionStore (in 1.3, but also in 1.2)
> > suffers from some limitations that the SLCSS doesn't have.
> > Particularly, back button history is limited, and while we don't
> > experience many real problems with it, we feel that recording change
> > objects isn't as robust as just serializing the page exactly as it is.
> > It sounds way more efficient to do just the change objects, but
> > compared to just serializing the page, it hardly seems to be in
> > practice.
> >
> > Eelco
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Disable the SecondLevelPageCache?

Posted by Matej Knopp <ma...@gmail.com>.

Even the regular DiskPageStore is optimized for use in clustered
environment, as it reuses serialized page instances when the session
is being replicated.

-Matej

On 9/9/07, Sean Sullivan <se...@seansullivan.com> wrote:
> On 9/8/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >
> > [...] Also thanks to Matej who recently
> > added a very, very optimized page store variant, *and* contributed an
> > efficient page store that can be used in a cluster.
>
> Which page store class are you referring to?
>
> org.apache.wicket.protocol.http.pagestore.DiskPageStore or something else?
>
>
> Sean
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Disable the SecondLevelPageCache?

Posted by Eelco Hillenius <ee...@gmail.com>.

On 9/9/07, Sean Sullivan <se...@seansullivan.com> wrote:
> On 9/8/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >
> > [...] Also thanks to Matej who recently
> > added a very, very optimized page store variant, *and* contributed an
> > efficient page store that can be used in a cluster.
>
> Which page store class are you referring to?
>
> org.apache.wicket.protocol.http.pagestore.DiskPageStore or something else?

I am referring to
org.apache.wicket.cluster.pagestore.ClusteredDiskPageStore, which is
in http://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicket-jetty-cluster-pagestore
and that needs http://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicket-jetty-cluster

Like you can see from the name, it is very specifically written for
Jetty, at least right now. We'll probably be working on this in the
next few weeks, and we might move it to e.g. a google code project
when we split it up in more projects.

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Disable the SecondLevelPageCache?

Posted by Sean Sullivan <se...@seansullivan.com>.

On 9/8/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> [...] Also thanks to Matej who recently
> added a very, very optimized page store variant, *and* contributed an
> efficient page store that can be used in a cluster.

Which page store class are you referring to?

org.apache.wicket.protocol.http.pagestore.DiskPageStore or something else?


Sean

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Disable the SecondLevelPageCache?

Posted by Eelco Hillenius <ee...@gmail.com>.

On 9/8/07, Ryan Holmes <ry...@hyperstep.com> wrote:
> Hi Eelco,
>
> Thanks for the thorough response (as usual). We're almost done
> converting from Tap 4 to Wicket 1.2 and we'll look into migrating to
> 1.3 pretty soon. I was planning on reverting to the HttpSessionStore
> immediately because I assumed the new disk-based store(s) traded
> performance for memory efficiency (and we have the luxury of not
> really caring about RAM usage due to a limited number of users in a
> LAN-only environment).
>
> An old benchmark that Jonathan posted (http://www.jroller.com/
> JonathanLocke/entry/how_fast_is_wicket) suggested the
> HttpSessionStore was noticeably faster, but I know there have been a
> lot of performance improvements since then.
>
> I've been pretty cynical about the whole idea of a disk-based store,
> actually. It always seemed like "jumping a fence" into a servlet
> container/app server's area of responsibility (had a slightly nasty
> argument with Johan about that). While it always sounded like a cool
> and very powerful/useful *option* to build into the framework, I
> never thought it would be a clear winner over HttpSessionStore. My
> main fear was that it would lead to a kind of split between some
> people using one store and some the other, and that it might cascade
> further into the framework (e.g. design x is a better fit with SLCSS
> but design y is better for HttpSessionStore) ultimately becoming a
> big drag for you guys.
>
> So that's a long way of saying: damn, I'm impressed. Not only is
> 1-2ms negligible, it sounds like the SLCSS is a conceptually simpler
> approach. Oh, and sorry to Johan for being a skeptic. ;)

I owe him an apology too in that sense, as I was one of the people
most opposed to it initially. That turned out to be a premature
optimization related fear I had. Also thanks to Matej who recently
added a very, very optimized page store variant, *and* contributed an
efficient page store that can be used in a cluster. And thanks for
both of them for doing some pretty smart optimizations on
serialization of pages (which I completely missed at first).

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Disable the SecondLevelPageCache?

Posted by Ryan Holmes <ry...@hyperstep.com>.

Hi Eelco,

Thanks for the thorough response (as usual). We're almost done  
converting from Tap 4 to Wicket 1.2 and we'll look into migrating to  
1.3 pretty soon. I was planning on reverting to the HttpSessionStore  
immediately because I assumed the new disk-based store(s) traded  
performance for memory efficiency (and we have the luxury of not  
really caring about RAM usage due to a limited number of users in a  
LAN-only environment).

An old benchmark that Jonathan posted (http://www.jroller.com/ 
JonathanLocke/entry/how_fast_is_wicket) suggested the  
HttpSessionStore was noticeably faster, but I know there have been a  
lot of performance improvements since then.

I've been pretty cynical about the whole idea of a disk-based store,  
actually. It always seemed like "jumping a fence" into a servlet  
container/app server's area of responsibility (had a slightly nasty  
argument with Johan about that). While it always sounded like a cool  
and very powerful/useful *option* to build into the framework, I  
never thought it would be a clear winner over HttpSessionStore. My  
main fear was that it would lead to a kind of split between some  
people using one store and some the other, and that it might cascade  
further into the framework (e.g. design x is a better fit with SLCSS  
but design y is better for HttpSessionStore) ultimately becoming a  
big drag for you guys.

So that's a long way of saying: damn, I'm impressed. Not only is  
1-2ms negligible, it sounds like the SLCSS is a conceptually simpler  
approach. Oh, and sorry to Johan for being a skeptic. ;)

-Ryan

On Sep 8, 2007, at 2:27 PM, Eelco Hillenius wrote:

> On 9/8/07, Ryan Holmes <ry...@hyperstep.com> wrote:
>> Is it not recommended because the new disk-based session store is
>> just a better all-around solution or because using the
>> httpsessionstore is dangerous or broken in some way in 1.3?
>
> It is a better all-round solution: it is more efficient memory wise,
> and the cost of serializing and saving is neglect-able in our
> experience (like 1 or 2 miliseconds per request even without Matej's
> recent optimizations). HttpSessionStore (in 1.3, but also in 1.2)
> suffers from some limitations that the SLCSS doesn't have.
> Particularly, back button history is limited, and while we don't
> experience many real problems with it, we feel that recording change
> objects isn't as robust as just serializing the page exactly as it is.
> It sounds way more efficient to do just the change objects, but
> compared to just serializing the page, it hardly seems to be in
> practice.
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Disable the SecondLevelPageCache?

Posted by Eelco Hillenius <ee...@gmail.com>.

On 9/8/07, Ryan Holmes <ry...@hyperstep.com> wrote:
> Is it not recommended because the new disk-based session store is
> just a better all-around solution or because using the
> httpsessionstore is dangerous or broken in some way in 1.3?

It is a better all-round solution: it is more efficient memory wise,
and the cost of serializing and saving is neglect-able in our
experience (like 1 or 2 miliseconds per request even without Matej's
recent optimizations). HttpSessionStore (in 1.3, but also in 1.2)
suffers from some limitations that the SLCSS doesn't have.
Particularly, back button history is limited, and while we don't
experience many real problems with it, we feel that recording change
objects isn't as robust as just serializing the page exactly as it is.
It sounds way more efficient to do just the change objects, but
compared to just serializing the page, it hardly seems to be in
practice.

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Disable the SecondLevelPageCache?

Posted by Ryan Holmes <ry...@hyperstep.com>.

Is it not recommended because the new disk-based session store is  
just a better all-around solution or because using the  
httpsessionstore is dangerous or broken in some way in 1.3?


Thanks,
-Ryan

On Sep 7, 2007, at 3:10 PM, Matej Knopp wrote:

> You can revert to httpsessionstore by changing
> Application.newSessionStore method. But that's not recommended. What
> are your performance problems? I doubt it is caused by the session
> store.
>
> -Matej
>
> On 9/7/07, jamieballing <ja...@hotmail.com> wrote:
>>
>> We are trying to do some performance troubleshooting and want to  
>> disable the
>> second level page cache.
>>
>> Is there any way to do this?
>>
>> Thanks,
>> Jamie
>> --
>> View this message in context: http://www.nabble.com/Disable-the- 
>> SecondLevelPageCache--tf4403977.html#a12563895
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Disable the SecondLevelPageCache?

Posted by Alex Objelean <al...@isdc.ro>.

Indeed, making the reference transient improves the responsiveness even with
the SecondSessionLevelStore. Anyway, I am curious, what is your advice for
this kind of applications? Keep using HttpSessionStore or switch to
SecondLevelSessionStore and make the most big objects transient? What is the
benefits of each method? Maybe my approach was a wrong one? 

Thank you for your replies!
Alex.


Matej Knopp-2 wrote:
> 
> You can make the reference transient. So it would no be serialized,
> bit it would be kept in memory as long as the page is the last
> accessed one. And if it eventually becomes null (when you e.g go to
> another page and return back), you can reinject it. Or you can just
> store it to session (outside the page). There are numerious
> possibilities, but you need to find out first where the bottleneck is.
> 
> -Matej
> 
> On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>>
>> Matej, how can I say to my model to serialize some objects and to not
>> others?
>> If I would detach the entire mode, that would mean that the next ajax
>> request would require again to call the  (very costly) service and this
>> is
>> not acceptable.
>>
>> Alex.
>>
>>
>> Matej Knopp-2 wrote:
>> >
>> > There seems to be something terribly weird going on. Your application
>> > looks like a corner case. On page like that, I wouldn't be surprised
>> > if there was penalty using SecondLevelCacheSessionStore, but the
>> > numbers you've posted are way too bad to be caused by wicket itself.
>> >
>> > My guess is that your model objects are extremely heavy. Maybe with
>> > references to your processing layer as well. Of course this will not
>> > work with 2nd level cache session store, as the whole thing is
>> > serialized. Normally you detach your models so the data kept in
>> > memory/session/disk is significantly reduced.
>> >
>> > I think secondlevelcachesessionstore should be usable for you as well,
>> > but that would require not serializing everyhing, rather then that
>> > just keep things in memory and "inject" the dependencies on
>> > deserialization.
>> >
>> > -Matej
>> >
>> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>> >>
>> >> Indeed, it is a very big component hierarchy (It contains at least 3
>> >> levels
>> >> of nested AjaxTabbedPanel components).
>> >>  The application is, in fact, a single page and it uses a lot of ajax
>> to
>> >> perform the updates. The model reflect the component hierarchy
>> >> (Appliction
>> >> has a single modelObject which nests another objects corresponding to
>> >> each
>> >> component). I do not have a lot of detaching logic, because it is
>> >> important
>> >> to have all the data in the model (caching), also because the services
>> >> are
>> >> very costly operations.
>> >>
>> >> If this description is not enough for replication, I will be glad to
>> help
>> >> by
>> >> giving you another details.
>> >>
>> >> Alex.
>> >>
>> >>
>> >> Martijn Dashorst wrote:
>> >> >
>> >> > How big is the page? Sounds like a really, really big component
>> >> > hierarchy. Then it sounds reasonable that the httpsession store is
>> >> > much faster: it keeps it in ram, and doesn't use serialization until
>> >> > the session is serialized (server shutting down, deciding to put
>> >> > session to disk or replication of session across cluster) iirc.
>> >> >
>> >> > I think we would appreciate some way of replicating your results. I
>> >> > assume you can't share the actual code, but could you share a
>> spin-off
>> >> > of the page's component structure and a Model that replicates the
>> data
>> >> > stuff's size (including the detach logic)?
>> >> >
>> >> > Martijn
>> >> >
>> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>> >> >>
>> >> >> If the pages wouldn't be serializable, it wouldn't work in
>> development
>> >> >> mode.
>> >> >> Is it right?
>> >> >>
>> >> >> I think that it is not necessarily about how large is application,
>> in
>> >> my
>> >> >> case it is about how large is the model I'm working with for that
>> >> >> specific
>> >> >> request (ajax request).
>> >> >>
>> >> >> My action was: fetch a subview of a very large table 300x300, each
>> >> cell
>> >> >> has
>> >> >> a heavy model object.
>> >> >>
>> >> >> Alex.
>> >> >>
>> >> >>
>> >> >> Johan Compagner wrote:
>> >> >> >
>> >> >> > that looks very strange to me. We have also a very large app here
>> >> and
>> >> >> we
>> >> >> > dont notice a difference
>> >> >> > So i am very curious what is happening at your place then. Are
>> you
>> >> sure
>> >> >> > for
>> >> >> > example that the pages
>> >> >> > are serializable ?  That we don't have constantly exceptions?
>> >> >> >
>> >> >> > johan
>> >> >> >
>> >> >> >
>> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>> >> >> >>
>> >> >> >>
>> >> >> >> Maybe the profiling was not a perfect one. But still, I have to
>> >> give
>> >> >> up
>> >> >> >> using
>> >> >> >> SecondSessionLevelStore just because the responsiveness of the
>> >> >> >> application
>> >> >> >> is very slow.
>> >> >> >>
>> >> >> >>
>> >> >> >> Johan Compagner wrote:
>> >> >> >> >
>> >> >> >> > invocation count 1??
>> >> >> >> >
>> >> >> >> > So you only do 1 request and you profile that?
>> >> >> >> > thats not a good test. You have to do plenty and multiply on 
>> the
>> >> >> same
>> >> >> >> > time
>> >> >> >> > (10 for 100 request or something like that)
>> >> >> >> > to really see the difference. (and have a warm up phase)
>> >> >> >> >
>> >> >> >> > johan
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> Matej, I must disagree with you regarding performance issues
>> of
>> >> the
>> >> >> >> >> SecondLevelSessionStore. I've reverted the
>> >> >> Application#newSessionStore
>> >> >> >> to
>> >> >> >> >> HttpSessionStore and this significantly improved the
>> application
>> >> >> >> overall
>> >> >> >> >> performance. Maybe this is not so obvious for small
>> >> applications,
>> >> >> but
>> >> >> >> >> when
>> >> >> >> >> it is about a large one - things changes.
>> >> >> >> >>
>> >> >> >> >> Below, you will find attached two images. The first one is a
>> >> >> profiling
>> >> >> >> of
>> >> >> >> >> an
>> >> >> >> >> action when working with HttpSessionStore, the second one is
>> a
>> >> >> >> profiling
>> >> >> >> >> for
>> >> >> >> >> the same action when using SecondSessionLevelStore. The
>> >> difference
>> >> >> is
>> >> >> >> >> huge:
>> >> >> >> >> 593ms vs 174420ms. I cannot explain what exactly is going on,
>> >> but
>> >> >> I've
>> >> >> >> >> noticed that by switching from default
>> SecondLevelSessionStore
>> >> to
>> >> >> the
>> >> >> >> >> HttpSessionStore improved a lot the responsiveness of the
>> >> >> application.
>> >> >> >> >>
>> >> >> >> >> Alex.
>> >> >> >> >>
>> >> >> >> >> http://www.nabble.com/file/p12588790/HttpSessionStore.jpg
>> >> >> >> >>
>> http://www.nabble.com/file/p12588790/SecondSessionLevelStore.jpg
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> Matej Knopp-2 wrote:
>> >> >> >> >> >
>> >> >> >> >> > You can revert to httpsessionstore by changing
>> >> >> >> >> > Application.newSessionStore method. But that's not
>> >> recommended.
>> >> >> What
>> >> >> >> >> > are your performance problems? I doubt it is caused by the
>> >> >> session
>> >> >> >> >> > store.
>> >> >> >> >> >
>> >> >> >> >> > -Matej
>> >> >> >> >> >
>> >> >> >> >> > On 9/7/07, jamieballing <ja...@hotmail.com> wrote:
>> >> >> >> >> >>
>> >> >> >> >> >> We are trying to do some performance troubleshooting and
>> want
>> >> to
>> >> >> >> >> disable
>> >> >> >> >> >> the
>> >> >> >> >> >> second level page cache.
>> >> >> >> >> >>
>> >> >> >> >> >> Is there any way to do this?
>> >> >> >> >> >>
>> >> >> >> >> >> Thanks,
>> >> >> >> >> >> Jamie
>> >> >> >> >> >> --
>> >> >> >> >> >> View this message in context:
>> >> >> >> >> >>
>> >> >> >> >>
>> >> >> >>
>> >> >>
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12563895
>> >> >> >> >> >> Sent from the Wicket - User mailing list archive at
>> >> Nabble.com.
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> >> >> To unsubscribe, e-mail:
>> users-unsubscribe@wicket.apache.org
>> >> >> >> >> >> For additional commands, e-mail:
>> users-help@wicket.apache.org
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >> >> > For additional commands, e-mail:
>> users-help@wicket.apache.org
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >>
>> >> >> >> >> --
>> >> >> >> >> View this message in context:
>> >> >> >> >>
>> >> >> >>
>> >> >>
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12588790
>> >> >> >> >> Sent from the Wicket - User mailing list archive at
>> Nabble.com.
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >
>> >> >> >> >
>> >> >> >>
>> >> >> >> --
>> >> >> >> View this message in context:
>> >> >> >>
>> >> >>
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589190
>> >> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> --
>> >> >> View this message in context:
>> >> >>
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589567
>> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >> >>
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > Buy Wicket in Action: http://manning.com/dashorst
>> >> > Apache Wicket 1.3.0-beta3 is released
>> >> > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
>> >> >
>> >> >
>> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12590414
>> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12590661
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12591440
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Disable the SecondLevelPageCache?

Posted by Matej Knopp <ma...@gmail.com>.

You can make the reference transient. So it would no be serialized,
bit it would be kept in memory as long as the page is the last
accessed one. And if it eventually becomes null (when you e.g go to
another page and return back), you can reinject it. Or you can just
store it to session (outside the page). There are numerious
possibilities, but you need to find out first where the bottleneck is.

-Matej

On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>
> Matej, how can I say to my model to serialize some objects and to not others?
> If I would detach the entire mode, that would mean that the next ajax
> request would require again to call the  (very costly) service and this is
> not acceptable.
>
> Alex.
>
>
> Matej Knopp-2 wrote:
> >
> > There seems to be something terribly weird going on. Your application
> > looks like a corner case. On page like that, I wouldn't be surprised
> > if there was penalty using SecondLevelCacheSessionStore, but the
> > numbers you've posted are way too bad to be caused by wicket itself.
> >
> > My guess is that your model objects are extremely heavy. Maybe with
> > references to your processing layer as well. Of course this will not
> > work with 2nd level cache session store, as the whole thing is
> > serialized. Normally you detach your models so the data kept in
> > memory/session/disk is significantly reduced.
> >
> > I think secondlevelcachesessionstore should be usable for you as well,
> > but that would require not serializing everyhing, rather then that
> > just keep things in memory and "inject" the dependencies on
> > deserialization.
> >
> > -Matej
> >
> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
> >>
> >> Indeed, it is a very big component hierarchy (It contains at least 3
> >> levels
> >> of nested AjaxTabbedPanel components).
> >>  The application is, in fact, a single page and it uses a lot of ajax to
> >> perform the updates. The model reflect the component hierarchy
> >> (Appliction
> >> has a single modelObject which nests another objects corresponding to
> >> each
> >> component). I do not have a lot of detaching logic, because it is
> >> important
> >> to have all the data in the model (caching), also because the services
> >> are
> >> very costly operations.
> >>
> >> If this description is not enough for replication, I will be glad to help
> >> by
> >> giving you another details.
> >>
> >> Alex.
> >>
> >>
> >> Martijn Dashorst wrote:
> >> >
> >> > How big is the page? Sounds like a really, really big component
> >> > hierarchy. Then it sounds reasonable that the httpsession store is
> >> > much faster: it keeps it in ram, and doesn't use serialization until
> >> > the session is serialized (server shutting down, deciding to put
> >> > session to disk or replication of session across cluster) iirc.
> >> >
> >> > I think we would appreciate some way of replicating your results. I
> >> > assume you can't share the actual code, but could you share a spin-off
> >> > of the page's component structure and a Model that replicates the data
> >> > stuff's size (including the detach logic)?
> >> >
> >> > Martijn
> >> >
> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
> >> >>
> >> >> If the pages wouldn't be serializable, it wouldn't work in development
> >> >> mode.
> >> >> Is it right?
> >> >>
> >> >> I think that it is not necessarily about how large is application, in
> >> my
> >> >> case it is about how large is the model I'm working with for that
> >> >> specific
> >> >> request (ajax request).
> >> >>
> >> >> My action was: fetch a subview of a very large table 300x300, each
> >> cell
> >> >> has
> >> >> a heavy model object.
> >> >>
> >> >> Alex.
> >> >>
> >> >>
> >> >> Johan Compagner wrote:
> >> >> >
> >> >> > that looks very strange to me. We have also a very large app here
> >> and
> >> >> we
> >> >> > dont notice a difference
> >> >> > So i am very curious what is happening at your place then. Are you
> >> sure
> >> >> > for
> >> >> > example that the pages
> >> >> > are serializable ?  That we don't have constantly exceptions?
> >> >> >
> >> >> > johan
> >> >> >
> >> >> >
> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
> >> >> >>
> >> >> >>
> >> >> >> Maybe the profiling was not a perfect one. But still, I have to
> >> give
> >> >> up
> >> >> >> using
> >> >> >> SecondSessionLevelStore just because the responsiveness of the
> >> >> >> application
> >> >> >> is very slow.
> >> >> >>
> >> >> >>
> >> >> >> Johan Compagner wrote:
> >> >> >> >
> >> >> >> > invocation count 1??
> >> >> >> >
> >> >> >> > So you only do 1 request and you profile that?
> >> >> >> > thats not a good test. You have to do plenty and multiply on  the
> >> >> same
> >> >> >> > time
> >> >> >> > (10 for 100 request or something like that)
> >> >> >> > to really see the difference. (and have a warm up phase)
> >> >> >> >
> >> >> >> > johan
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> Matej, I must disagree with you regarding performance issues of
> >> the
> >> >> >> >> SecondLevelSessionStore. I've reverted the
> >> >> Application#newSessionStore
> >> >> >> to
> >> >> >> >> HttpSessionStore and this significantly improved the application
> >> >> >> overall
> >> >> >> >> performance. Maybe this is not so obvious for small
> >> applications,
> >> >> but
> >> >> >> >> when
> >> >> >> >> it is about a large one - things changes.
> >> >> >> >>
> >> >> >> >> Below, you will find attached two images. The first one is a
> >> >> profiling
> >> >> >> of
> >> >> >> >> an
> >> >> >> >> action when working with HttpSessionStore, the second one is a
> >> >> >> profiling
> >> >> >> >> for
> >> >> >> >> the same action when using SecondSessionLevelStore. The
> >> difference
> >> >> is
> >> >> >> >> huge:
> >> >> >> >> 593ms vs 174420ms. I cannot explain what exactly is going on,
> >> but
> >> >> I've
> >> >> >> >> noticed that by switching from default SecondLevelSessionStore
> >> to
> >> >> the
> >> >> >> >> HttpSessionStore improved a lot the responsiveness of the
> >> >> application.
> >> >> >> >>
> >> >> >> >> Alex.
> >> >> >> >>
> >> >> >> >> http://www.nabble.com/file/p12588790/HttpSessionStore.jpg
> >> >> >> >> http://www.nabble.com/file/p12588790/SecondSessionLevelStore.jpg
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> Matej Knopp-2 wrote:
> >> >> >> >> >
> >> >> >> >> > You can revert to httpsessionstore by changing
> >> >> >> >> > Application.newSessionStore method. But that's not
> >> recommended.
> >> >> What
> >> >> >> >> > are your performance problems? I doubt it is caused by the
> >> >> session
> >> >> >> >> > store.
> >> >> >> >> >
> >> >> >> >> > -Matej
> >> >> >> >> >
> >> >> >> >> > On 9/7/07, jamieballing <ja...@hotmail.com> wrote:
> >> >> >> >> >>
> >> >> >> >> >> We are trying to do some performance troubleshooting and want
> >> to
> >> >> >> >> disable
> >> >> >> >> >> the
> >> >> >> >> >> second level page cache.
> >> >> >> >> >>
> >> >> >> >> >> Is there any way to do this?
> >> >> >> >> >>
> >> >> >> >> >> Thanks,
> >> >> >> >> >> Jamie
> >> >> >> >> >> --
> >> >> >> >> >> View this message in context:
> >> >> >> >> >>
> >> >> >> >>
> >> >> >>
> >> >>
> >> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12563895
> >> >> >> >> >> Sent from the Wicket - User mailing list archive at
> >> Nabble.com.
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >
> >> >> >> >> >
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >> --
> >> >> >> >> View this message in context:
> >> >> >> >>
> >> >> >>
> >> >>
> >> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12588790
> >> >> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >> --
> >> >> >> View this message in context:
> >> >> >>
> >> >>
> >> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589190
> >> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >> >> >>
> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> View this message in context:
> >> >>
> >> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589567
> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > Buy Wicket in Action: http://manning.com/dashorst
> >> > Apache Wicket 1.3.0-beta3 is released
> >> > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12590414
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12590661
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Disable the SecondLevelPageCache?

Posted by Alex Objelean <al...@isdc.ro>.

Matej, how can I say to my model to serialize some objects and to not others?
If I would detach the entire mode, that would mean that the next ajax
request would require again to call the  (very costly) service and this is
not acceptable.

Alex.


Matej Knopp-2 wrote:
> 
> There seems to be something terribly weird going on. Your application
> looks like a corner case. On page like that, I wouldn't be surprised
> if there was penalty using SecondLevelCacheSessionStore, but the
> numbers you've posted are way too bad to be caused by wicket itself.
> 
> My guess is that your model objects are extremely heavy. Maybe with
> references to your processing layer as well. Of course this will not
> work with 2nd level cache session store, as the whole thing is
> serialized. Normally you detach your models so the data kept in
> memory/session/disk is significantly reduced.
> 
> I think secondlevelcachesessionstore should be usable for you as well,
> but that would require not serializing everyhing, rather then that
> just keep things in memory and "inject" the dependencies on
> deserialization.
> 
> -Matej
> 
> On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>>
>> Indeed, it is a very big component hierarchy (It contains at least 3
>> levels
>> of nested AjaxTabbedPanel components).
>>  The application is, in fact, a single page and it uses a lot of ajax to
>> perform the updates. The model reflect the component hierarchy
>> (Appliction
>> has a single modelObject which nests another objects corresponding to
>> each
>> component). I do not have a lot of detaching logic, because it is
>> important
>> to have all the data in the model (caching), also because the services
>> are
>> very costly operations.
>>
>> If this description is not enough for replication, I will be glad to help
>> by
>> giving you another details.
>>
>> Alex.
>>
>>
>> Martijn Dashorst wrote:
>> >
>> > How big is the page? Sounds like a really, really big component
>> > hierarchy. Then it sounds reasonable that the httpsession store is
>> > much faster: it keeps it in ram, and doesn't use serialization until
>> > the session is serialized (server shutting down, deciding to put
>> > session to disk or replication of session across cluster) iirc.
>> >
>> > I think we would appreciate some way of replicating your results. I
>> > assume you can't share the actual code, but could you share a spin-off
>> > of the page's component structure and a Model that replicates the data
>> > stuff's size (including the detach logic)?
>> >
>> > Martijn
>> >
>> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>> >>
>> >> If the pages wouldn't be serializable, it wouldn't work in development
>> >> mode.
>> >> Is it right?
>> >>
>> >> I think that it is not necessarily about how large is application, in
>> my
>> >> case it is about how large is the model I'm working with for that
>> >> specific
>> >> request (ajax request).
>> >>
>> >> My action was: fetch a subview of a very large table 300x300, each
>> cell
>> >> has
>> >> a heavy model object.
>> >>
>> >> Alex.
>> >>
>> >>
>> >> Johan Compagner wrote:
>> >> >
>> >> > that looks very strange to me. We have also a very large app here
>> and
>> >> we
>> >> > dont notice a difference
>> >> > So i am very curious what is happening at your place then. Are you
>> sure
>> >> > for
>> >> > example that the pages
>> >> > are serializable ?  That we don't have constantly exceptions?
>> >> >
>> >> > johan
>> >> >
>> >> >
>> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>> >> >>
>> >> >>
>> >> >> Maybe the profiling was not a perfect one. But still, I have to
>> give
>> >> up
>> >> >> using
>> >> >> SecondSessionLevelStore just because the responsiveness of the
>> >> >> application
>> >> >> is very slow.
>> >> >>
>> >> >>
>> >> >> Johan Compagner wrote:
>> >> >> >
>> >> >> > invocation count 1??
>> >> >> >
>> >> >> > So you only do 1 request and you profile that?
>> >> >> > thats not a good test. You have to do plenty and multiply on  the
>> >> same
>> >> >> > time
>> >> >> > (10 for 100 request or something like that)
>> >> >> > to really see the difference. (and have a warm up phase)
>> >> >> >
>> >> >> > johan
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>> >> >> >>
>> >> >> >>
>> >> >> >> Matej, I must disagree with you regarding performance issues of
>> the
>> >> >> >> SecondLevelSessionStore. I've reverted the
>> >> Application#newSessionStore
>> >> >> to
>> >> >> >> HttpSessionStore and this significantly improved the application
>> >> >> overall
>> >> >> >> performance. Maybe this is not so obvious for small
>> applications,
>> >> but
>> >> >> >> when
>> >> >> >> it is about a large one - things changes.
>> >> >> >>
>> >> >> >> Below, you will find attached two images. The first one is a
>> >> profiling
>> >> >> of
>> >> >> >> an
>> >> >> >> action when working with HttpSessionStore, the second one is a
>> >> >> profiling
>> >> >> >> for
>> >> >> >> the same action when using SecondSessionLevelStore. The
>> difference
>> >> is
>> >> >> >> huge:
>> >> >> >> 593ms vs 174420ms. I cannot explain what exactly is going on,
>> but
>> >> I've
>> >> >> >> noticed that by switching from default SecondLevelSessionStore
>> to
>> >> the
>> >> >> >> HttpSessionStore improved a lot the responsiveness of the
>> >> application.
>> >> >> >>
>> >> >> >> Alex.
>> >> >> >>
>> >> >> >> http://www.nabble.com/file/p12588790/HttpSessionStore.jpg
>> >> >> >> http://www.nabble.com/file/p12588790/SecondSessionLevelStore.jpg
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> Matej Knopp-2 wrote:
>> >> >> >> >
>> >> >> >> > You can revert to httpsessionstore by changing
>> >> >> >> > Application.newSessionStore method. But that's not
>> recommended.
>> >> What
>> >> >> >> > are your performance problems? I doubt it is caused by the
>> >> session
>> >> >> >> > store.
>> >> >> >> >
>> >> >> >> > -Matej
>> >> >> >> >
>> >> >> >> > On 9/7/07, jamieballing <ja...@hotmail.com> wrote:
>> >> >> >> >>
>> >> >> >> >> We are trying to do some performance troubleshooting and want
>> to
>> >> >> >> disable
>> >> >> >> >> the
>> >> >> >> >> second level page cache.
>> >> >> >> >>
>> >> >> >> >> Is there any way to do this?
>> >> >> >> >>
>> >> >> >> >> Thanks,
>> >> >> >> >> Jamie
>> >> >> >> >> --
>> >> >> >> >> View this message in context:
>> >> >> >> >>
>> >> >> >>
>> >> >>
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12563895
>> >> >> >> >> Sent from the Wicket - User mailing list archive at
>> Nabble.com.
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >
>> >> >> >> >
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >>
>> >> >> >> --
>> >> >> >> View this message in context:
>> >> >> >>
>> >> >>
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12588790
>> >> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> --
>> >> >> View this message in context:
>> >> >>
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589190
>> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >> >>
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589567
>> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > Buy Wicket in Action: http://manning.com/dashorst
>> > Apache Wicket 1.3.0-beta3 is released
>> > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12590414
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12590661
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Disable the SecondLevelPageCache?

Posted by Matej Knopp <ma...@gmail.com>.

There seems to be something terribly weird going on. Your application
looks like a corner case. On page like that, I wouldn't be surprised
if there was penalty using SecondLevelCacheSessionStore, but the
numbers you've posted are way too bad to be caused by wicket itself.

My guess is that your model objects are extremely heavy. Maybe with
references to your processing layer as well. Of course this will not
work with 2nd level cache session store, as the whole thing is
serialized. Normally you detach your models so the data kept in
memory/session/disk is significantly reduced.

I think secondlevelcachesessionstore should be usable for you as well,
but that would require not serializing everyhing, rather then that
just keep things in memory and "inject" the dependencies on
deserialization.

-Matej

On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>
> Indeed, it is a very big component hierarchy (It contains at least 3 levels
> of nested AjaxTabbedPanel components).
>  The application is, in fact, a single page and it uses a lot of ajax to
> perform the updates. The model reflect the component hierarchy (Appliction
> has a single modelObject which nests another objects corresponding to each
> component). I do not have a lot of detaching logic, because it is important
> to have all the data in the model (caching), also because the services are
> very costly operations.
>
> If this description is not enough for replication, I will be glad to help by
> giving you another details.
>
> Alex.
>
>
> Martijn Dashorst wrote:
> >
> > How big is the page? Sounds like a really, really big component
> > hierarchy. Then it sounds reasonable that the httpsession store is
> > much faster: it keeps it in ram, and doesn't use serialization until
> > the session is serialized (server shutting down, deciding to put
> > session to disk or replication of session across cluster) iirc.
> >
> > I think we would appreciate some way of replicating your results. I
> > assume you can't share the actual code, but could you share a spin-off
> > of the page's component structure and a Model that replicates the data
> > stuff's size (including the detach logic)?
> >
> > Martijn
> >
> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
> >>
> >> If the pages wouldn't be serializable, it wouldn't work in development
> >> mode.
> >> Is it right?
> >>
> >> I think that it is not necessarily about how large is application, in my
> >> case it is about how large is the model I'm working with for that
> >> specific
> >> request (ajax request).
> >>
> >> My action was: fetch a subview of a very large table 300x300, each cell
> >> has
> >> a heavy model object.
> >>
> >> Alex.
> >>
> >>
> >> Johan Compagner wrote:
> >> >
> >> > that looks very strange to me. We have also a very large app here and
> >> we
> >> > dont notice a difference
> >> > So i am very curious what is happening at your place then. Are you sure
> >> > for
> >> > example that the pages
> >> > are serializable ?  That we don't have constantly exceptions?
> >> >
> >> > johan
> >> >
> >> >
> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
> >> >>
> >> >>
> >> >> Maybe the profiling was not a perfect one. But still, I have to give
> >> up
> >> >> using
> >> >> SecondSessionLevelStore just because the responsiveness of the
> >> >> application
> >> >> is very slow.
> >> >>
> >> >>
> >> >> Johan Compagner wrote:
> >> >> >
> >> >> > invocation count 1??
> >> >> >
> >> >> > So you only do 1 request and you profile that?
> >> >> > thats not a good test. You have to do plenty and multiply on  the
> >> same
> >> >> > time
> >> >> > (10 for 100 request or something like that)
> >> >> > to really see the difference. (and have a warm up phase)
> >> >> >
> >> >> > johan
> >> >> >
> >> >> >
> >> >> >
> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
> >> >> >>
> >> >> >>
> >> >> >> Matej, I must disagree with you regarding performance issues of the
> >> >> >> SecondLevelSessionStore. I've reverted the
> >> Application#newSessionStore
> >> >> to
> >> >> >> HttpSessionStore and this significantly improved the application
> >> >> overall
> >> >> >> performance. Maybe this is not so obvious for small applications,
> >> but
> >> >> >> when
> >> >> >> it is about a large one - things changes.
> >> >> >>
> >> >> >> Below, you will find attached two images. The first one is a
> >> profiling
> >> >> of
> >> >> >> an
> >> >> >> action when working with HttpSessionStore, the second one is a
> >> >> profiling
> >> >> >> for
> >> >> >> the same action when using SecondSessionLevelStore. The difference
> >> is
> >> >> >> huge:
> >> >> >> 593ms vs 174420ms. I cannot explain what exactly is going on, but
> >> I've
> >> >> >> noticed that by switching from default SecondLevelSessionStore to
> >> the
> >> >> >> HttpSessionStore improved a lot the responsiveness of the
> >> application.
> >> >> >>
> >> >> >> Alex.
> >> >> >>
> >> >> >> http://www.nabble.com/file/p12588790/HttpSessionStore.jpg
> >> >> >> http://www.nabble.com/file/p12588790/SecondSessionLevelStore.jpg
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> Matej Knopp-2 wrote:
> >> >> >> >
> >> >> >> > You can revert to httpsessionstore by changing
> >> >> >> > Application.newSessionStore method. But that's not recommended.
> >> What
> >> >> >> > are your performance problems? I doubt it is caused by the
> >> session
> >> >> >> > store.
> >> >> >> >
> >> >> >> > -Matej
> >> >> >> >
> >> >> >> > On 9/7/07, jamieballing <ja...@hotmail.com> wrote:
> >> >> >> >>
> >> >> >> >> We are trying to do some performance troubleshooting and want to
> >> >> >> disable
> >> >> >> >> the
> >> >> >> >> second level page cache.
> >> >> >> >>
> >> >> >> >> Is there any way to do this?
> >> >> >> >>
> >> >> >> >> Thanks,
> >> >> >> >> Jamie
> >> >> >> >> --
> >> >> >> >> View this message in context:
> >> >> >> >>
> >> >> >>
> >> >>
> >> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12563895
> >> >> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> ---------------------------------------------------------------------
> >> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >> --
> >> >> >> View this message in context:
> >> >> >>
> >> >>
> >> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12588790
> >> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >> >> >>
> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> View this message in context:
> >> >>
> >> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589190
> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589567
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
> > --
> > Buy Wicket in Action: http://manning.com/dashorst
> > Apache Wicket 1.3.0-beta3 is released
> > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12590414
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Disable the SecondLevelPageCache?

Posted by Martijn Dashorst <ma...@gmail.com>.

On 9/10/07, Johan Compagner <jc...@gmail.com> wrote:
> you got to be kidding me...32MB????
> really? Or is this a nice joke so in the middle of the day :)

Alex did warn us that it was a big page :)

Martijn

-- 
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0-beta3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Disable the SecondLevelPageCache?

Posted by Johan Compagner <jc...@gmail.com>.

>
> and also keep the ui state down to a minimum - which will make your app
> clusterable and thus scalable for the future.



the app is clusterable it could serialize it just fine ;)
32MB and everything is serializeable thats an accomplishment!


johan

Re: Disable the SecondLevelPageCache?

Posted by Igor Vaynberg <ig...@gmail.com>.

and one more advice, for you and people reading about this. if you have
large data like that that you want cached because retrieving it is slow, i
would use an external cache. caching it in wicket-models is not the right
place imho because as you can see wicket sometimes needs to serialize/clone
pages. so having something like ehcache glued to your application object
would work better for caching here. it will allow you the speed you need,
and also keep the ui state down to a minimum - which will make your app
clusterable and thus scalable for the future.

-igor


On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>
>
> Johan, Matej, Martijn,
> thank you all for help!
>
> PS: one more reason to love this community :)
>
>
> Johan Compagner wrote:
> >
> > if you just have 1 page with no back button support/all ajax
> > then httpsessionstore is fine
> >
> > johan
> >
> >
> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
> >>
> >>
> >> It is a intranet application, so the number of users for this
> application
> >> is
> >> at most ~30-40 users/day. A back button support is not needed, because
> >> there
> >> is a single page and also it doesn't make sense (since it is all ajax).
> >> I'm still wondering, what is best in this case:
> >> * Using HttpSessionStore
> >> * Use 2nd level session store and make transient heavy object
> references.
> >>
> >> Alex.
> >>
> >>
> >>
> >> Martijn Dashorst wrote:
> >> >
> >> > The only caveat you'll have is whether or not the backbutton is
> >> > supported long enough, and how many copies of that page you want to
> >> > have in memory.
> >> >
> >> > If the non-2nd level cache way works for you, then there is
> absolutely
> >> > nobody telling you to stop using it. The difference has mostly to do
> >> > with providing backbutton support and optimizing memory usage. In
> your
> >> > case it is probably best to limit the backbutton, as you claim to
> work
> >> > a lot with ajax. So the back button functionality is probably already
> >> > not working (users can press it, but they will leave your site, or go
> >> > back to the login page).
> >> >
> >> > Profile the memory usage, multiply with the number of users you
> expect
> >> > and ask if it still fits on the machine available for your budget.
> >> >
> >> > The second level cache will still keep the last rendered page in
> >> > memory as I understand it, so that 32MB will still be claimed,
> >> > whatever store you choose.
> >> >
> >> > Martijn
> >> >
> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
> >> >>
> >> >> :) Unfortunately it's not a joke, but I'm glad you're having fun :D.
> >> >> Actually, this is result of worst case scenario simulation (I told
> you
> >> >> that
> >> >> there are heavy objects in the model). After making transient some
> of
> >> the
> >> >> fields, the size of the page dropped dramatically.
> >> >>
> >> >> Alex.
> >> >>
> >> >>
> >> >> Johan Compagner wrote:
> >> >> >
> >> >> > you got to be kidding me...32MB????
> >> >> > really? Or is this a nice joke so in the middle of the day :)
> >> >> >
> >> >> > johan
> >> >> >
> >> >> >
> >> >> >
> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
> >> >> >>
> >> >> >>
> >> >> >> It is about 32MB. Kind a big page :)
> >> >> >>
> >> >> >>
> >> >> >> Matej Knopp-2 wrote:
> >> >> >> >
> >> >> >> > Turn on SecondLevelCacheSessionStore, and use FilePageStore as
> >> >> >> > IPageStore (specified in session store constructor). Then go to
> >> your
> >> >> >> > tmp dir and you should be able to find the serialized pages
> >> there.
> >> >> >> >
> >> >> >> > -Matej
> >> >> >> >
> >> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
> >> >> >> >>
> >> >> >> >> How can I figure it out?
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> Johan Compagner wrote:
> >> >> >> >> >
> >> >> >> >> > if you save the page to disk how big is it?
> >> >> >> >> >
> >> >> >> >> > johan
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro>
> wrote:
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >> Indeed, it is a very big component hierarchy (It contains
> at
> >> >> least
> >> >> >> 3
> >> >> >> >> >> levels
> >> >> >> >> >> of nested AjaxTabbedPanel components).
> >> >> >> >> >> The application is, in fact, a single page and it uses a
> lot
> >> of
> >> >> >> ajax
> >> >> >> >> to
> >> >> >> >> >> perform the updates. The model reflect the component
> >> hierarchy
> >> >> >> >> >> (Appliction
> >> >> >> >> >> has a single modelObject which nests another objects
> >> >> corresponding
> >> >> >> to
> >> >> >> >> >> each
> >> >> >> >> >> component). I do not have a lot of detaching logic, because
> >> it
> >> >> is
> >> >> >> >> >> important
> >> >> >> >> >> to have all the data in the model (caching), also because
> the
> >> >> >> services
> >> >> >> >> >> are
> >> >> >> >> >> very costly operations.
> >> >> >> >> >>
> >> >> >> >> >> If this description is not enough for replication, I will
> be
> >> >> glad
> >> >> >> to
> >> >> >> >> help
> >> >> >> >> >> by
> >> >> >> >> >> giving you another details.
> >> >> >> >> >>
> >> >> >> >> >> Alex.
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >> Martijn Dashorst wrote:
> >> >> >> >> >> >
> >> >> >> >> >> > How big is the page? Sounds like a really, really big
> >> >> component
> >> >> >> >> >> > hierarchy. Then it sounds reasonable that the httpsession
> >> >> store
> >> >> >> is
> >> >> >> >> >> > much faster: it keeps it in ram, and doesn't use
> >> serialization
> >> >> >> until
> >> >> >> >> >> > the session is serialized (server shutting down, deciding
> >> to
> >> >> put
> >> >> >> >> >> > session to disk or replication of session across cluster)
> >> >> iirc.
> >> >> >> >> >> >
> >> >> >> >> >> > I think we would appreciate some way of replicating your
> >> >> results.
> >> >> >> I
> >> >> >> >> >> > assume you can't share the actual code, but could you
> share
> >> a
> >> >> >> >> spin-off
> >> >> >> >> >> > of the page's component structure and a Model that
> >> replicates
> >> >> the
> >> >> >> >> data
> >> >> >> >> >> > stuff's size (including the detach logic)?
> >> >> >> >> >> >
> >> >> >> >> >> > Martijn
> >> >> >> >> >> >
> >> >> >> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro>
> >> wrote:
> >> >> >> >> >> >>
> >> >> >> >> >> >> If the pages wouldn't be serializable, it wouldn't work
> in
> >> >> >> >> development
> >> >> >> >> >> >> mode.
> >> >> >> >> >> >> Is it right?
> >> >> >> >> >> >>
> >> >> >> >> >> >> I think that it is not necessarily about how large is
> >> >> >> application,
> >> >> >> >> in
> >> >> >> >> >> my
> >> >> >> >> >> >> case it is about how large is the model I'm working with
> >> for
> >> >> >> that
> >> >> >> >> >> >> specific
> >> >> >> >> >> >> request (ajax request).
> >> >> >> >> >> >>
> >> >> >> >> >> >> My action was: fetch a subview of a very large table
> >> 300x300,
> >> >> >> each
> >> >> >> >> >> cell
> >> >> >> >> >> >> has
> >> >> >> >> >> >> a heavy model object.
> >> >> >> >> >> >>
> >> >> >> >> >> >> Alex.
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >> Johan Compagner wrote:
> >> >> >> >> >> >> >
> >> >> >> >> >> >> > that looks very strange to me. We have also a very
> large
> >> >> app
> >> >> >> here
> >> >> >> >> >> and
> >> >> >> >> >> >> we
> >> >> >> >> >> >> > dont notice a difference
> >> >> >> >> >> >> > So i am very curious what is happening at your place
> >> then.
> >> >> Are
> >> >> >> >> you
> >> >> >> >> >> sure
> >> >> >> >> >> >> > for
> >> >> >> >> >> >> > example that the pages
> >> >> >> >> >> >> > are serializable ?  That we don't have constantly
> >> >> exceptions?
> >> >> >> >> >> >> >
> >> >> >> >> >> >> > johan
> >> >> >> >> >> >> >
> >> >> >> >> >> >> >
> >> >> >> >> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro>
> >> >> wrote:
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> Maybe the profiling was not a perfect one. But still,
> I
> >> >> have
> >> >> >> to
> >> >> >> >> >> give
> >> >> >> >> >> >> up
> >> >> >> >> >> >> >> using
> >> >> >> >> >> >> >> SecondSessionLevelStore just because the
> responsiveness
> >> of
> >> >> >> the
> >> >> >> >> >> >> >> application
> >> >> >> >> >> >> >> is very slow.
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> Johan Compagner wrote:
> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> > invocation count 1??
> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> > So you only do 1 request and you profile that?
> >> >> >> >> >> >> >> > thats not a good test. You have to do plenty and
> >> >> multiply
> >> >> >> on
> >> >> >> >> the
> >> >> >> >> >> >> same
> >> >> >> >> >> >> >> > time
> >> >> >> >> >> >> >> > (10 for 100 request or something like that)
> >> >> >> >> >> >> >> > to really see the difference. (and have a warm up
> >> phase)
> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> > johan
> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> > On 9/10/07, Alex Objelean
> >> <al...@isdc.ro>
> >> >> >> wrote:
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> Matej, I must disagree with you regarding
> >> performance
> >> >> >> issues
> >> >> >> >> of
> >> >> >> >> >> the
> >> >> >> >> >> >> >> >> SecondLevelSessionStore. I've reverted the
> >> >> >> >> >> >> Application#newSessionStore
> >> >> >> >> >> >> >> to
> >> >> >> >> >> >> >> >> HttpSessionStore and this significantly improved
> the
> >> >> >> >> application
> >> >> >> >> >> >> >> overall
> >> >> >> >> >> >> >> >> performance. Maybe this is not so obvious for
> small
> >> >> >> >> >> applications,
> >> >> >> >> >> >> but
> >> >> >> >> >> >> >> >> when
> >> >> >> >> >> >> >> >> it is about a large one - things changes.
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> Below, you will find attached two images. The
> first
> >> one
> >> >> is
> >> >> >> a
> >> >> >> >> >> >> profiling
> >> >> >> >> >> >> >> of
> >> >> >> >> >> >> >> >> an
> >> >> >> >> >> >> >> >> action when working with HttpSessionStore, the
> >> second
> >> >> one
> >> >> >> is
> >> >> >> >> a
> >> >> >> >> >> >> >> profiling
> >> >> >> >> >> >> >> >> for
> >> >> >> >> >> >> >> >> the same action when using
> SecondSessionLevelStore.
> >> The
> >> >> >> >> >> difference
> >> >> >> >> >> >> is
> >> >> >> >> >> >> >> >> huge:
> >> >> >> >> >> >> >> >> 593ms vs 174420ms. I cannot explain what exactly
> is
> >> >> going
> >> >> >> on,
> >> >> >> >> >> but
> >> >> >> >> >> >> I've
> >> >> >> >> >> >> >> >> noticed that by switching from default
> >> >> >> >> SecondLevelSessionStore
> >> >> >> >> >> to
> >> >> >> >> >> >> the
> >> >> >> >> >> >> >> >> HttpSessionStore improved a lot the responsiveness
> >> of
> >> >> the
> >> >> >> >> >> >> application.
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> Alex.
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >>
> >> >> http://www.nabble.com/file/p12588790/HttpSessionStore.jpg
> >> >> >> >> >> >> >> >>
> >> >> >> >>
> http://www.nabble.com/file/p12588790/SecondSessionLevelStore.jpg
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> Matej Knopp-2 wrote:
> >> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> >> > You can revert to httpsessionstore by changing
> >> >> >> >> >> >> >> >> > Application.newSessionStore method. But that's
> not
> >> >> >> >> >> recommended.
> >> >> >> >> >> >> What
> >> >> >> >> >> >> >> >> > are your performance problems? I doubt it is
> >> caused
> >> >> by
> >> >> >> the
> >> >> >> >> >> >> session
> >> >> >> >> >> >> >> >> > store.
> >> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> >> > -Matej
> >> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> >> > On 9/7/07, jamieballing <
> jamieballing@hotmail.com>
> >> >> >> wrote:
> >> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> >> We are trying to do some performance
> >> troubleshooting
> >> >> >> and
> >> >> >> >> want
> >> >> >> >> >> to
> >> >> >> >> >> >> >> >> disable
> >> >> >> >> >> >> >> >> >> the
> >> >> >> >> >> >> >> >> >> second level page cache.
> >> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> >> Is there any way to do this?
> >> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> >> Thanks,
> >> >> >> >> >> >> >> >> >> Jamie
> >> >> >> >> >> >> >> >> >> --
> >> >> >> >> >> >> >> >> >> View this message in context:
> >> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >>
> >> >> >>
> >> >>
> >>
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12563895
> >> >> >> >> >> >> >> >> >> Sent from the Wicket - User mailing list
> archive
> >> at
> >> >> >> >> >> Nabble.com
> >> >> >> >> >> .
> >> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >> >> >> >> >> >> To unsubscribe, e-mail:
> >> >> >> >> users-unsubscribe@wicket.apache.org
> >> >> >> >> >> >> >> >> >> For additional commands, e-mail:
> >> >> >> >> users-help@wicket.apache.org
> >> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >> >> >> >> >> > To unsubscribe, e-mail:
> >> >> >> users-unsubscribe@wicket.apache.org
> >> >> >> >> >> >> >> >> > For additional commands, e-mail:
> >> >> >> >> users-help@wicket.apache.org
> >> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> --
> >> >> >> >> >> >> >> >> View this message in context:
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >>
> >> >> >>
> >> >>
> >>
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12588790
> >> >> >> >> >> >> >> >> Sent from the Wicket - User mailing list archive
> at
> >> >> >> >> Nabble.com.
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> >> >> >> >> >> >> To unsubscribe, e-mail:
> >> >> >> users-unsubscribe@wicket.apache.org
> >> >> >> >> >> >> >> >> For additional commands, e-mail:
> >> >> >> users-help@wicket.apache.org
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> --
> >> >> >> >> >> >> >> View this message in context:
> >> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >>
> >> >> >>
> >> >>
> >>
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589190
> >> >> >> >> >> >> >> Sent from the Wicket - User mailing list archive at
> >> >> >> Nabble.com
> >> >> >> .
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >> >> >> >> To unsubscribe, e-mail:
> >> >> users-unsubscribe@wicket.apache.org
> >> >> >> >> >> >> >> For additional commands, e-mail:
> >> >> users-help@wicket.apache.org
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >
> >> >> >> >> >> >> >
> >> >> >> >> >> >>
> >> >> >> >> >> >> --
> >> >> >> >> >> >> View this message in context:
> >> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >>
> >> >> >>
> >> >>
> >>
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589567
> >> >> >> >> >> >> Sent from the Wicket - User mailing list archive at
> >> >> Nabble.com.
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> >> >> >> >> To unsubscribe, e-mail:
> >> users-unsubscribe@wicket.apache.org
> >> >> >> >> >> >> For additional commands, e-mail:
> >> users-help@wicket.apache.org
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >> >> > --
> >> >> >> >> >> > Buy Wicket in Action: http://manning.com/dashorst
> >> >> >> >> >> > Apache Wicket 1.3.0-beta3 is released
> >> >> >> >> >> > Get it now:
> >> >> >> http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> >> >> >> > To unsubscribe, e-mail:
> users-unsubscribe@wicket.apache.org
> >> >> >> >> >> > For additional commands, e-mail:
> >> users-help@wicket.apache.org
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >> >>
> >> >> >> >> >> --
> >> >> >> >> >> View this message in context:
> >> >> >> >> >>
> >> >> >> >>
> >> >> >>
> >> >>
> >>
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12590414
> >> >> >> >> >> Sent from the Wicket - User mailing list archive at
> >> Nabble.com
> >> .
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> >> >> For additional commands, e-mail:
> users-help@wicket.apache.org
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >> --
> >> >> >> >> View this message in context:
> >> >> >> >>
> >> >> >>
> >> >>
> >>
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12590627
> >> >> >> >> Sent from the Wicket - User mailing list archive at Nabble.com
> .
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >>
> ---------------------------------------------------------------------
> >> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >> --
> >> >> >> View this message in context:
> >> >> >>
> >> >>
> >>
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12591276
> >> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >> >> >>
> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> View this message in context:
> >> >>
> >>
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12592522
> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > Buy Wicket in Action: http://manning.com/dashorst
> >> > Apache Wicket 1.3.0-beta3 is released
> >> > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12592818
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12593058
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

Re: Disable the SecondLevelPageCache?

Posted by Alex Objelean <al...@isdc.ro>.

Johan, Matej, Martijn, 
thank you all for help! 

PS: one more reason to love this community :)


Johan Compagner wrote:
> 
> if you just have 1 page with no back button support/all ajax
> then httpsessionstore is fine
> 
> johan
> 
> 
> On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>>
>>
>> It is a intranet application, so the number of users for this application
>> is
>> at most ~30-40 users/day. A back button support is not needed, because
>> there
>> is a single page and also it doesn't make sense (since it is all ajax).
>> I'm still wondering, what is best in this case:
>> * Using HttpSessionStore
>> * Use 2nd level session store and make transient heavy object references.
>>
>> Alex.
>>
>>
>>
>> Martijn Dashorst wrote:
>> >
>> > The only caveat you'll have is whether or not the backbutton is
>> > supported long enough, and how many copies of that page you want to
>> > have in memory.
>> >
>> > If the non-2nd level cache way works for you, then there is absolutely
>> > nobody telling you to stop using it. The difference has mostly to do
>> > with providing backbutton support and optimizing memory usage. In your
>> > case it is probably best to limit the backbutton, as you claim to work
>> > a lot with ajax. So the back button functionality is probably already
>> > not working (users can press it, but they will leave your site, or go
>> > back to the login page).
>> >
>> > Profile the memory usage, multiply with the number of users you expect
>> > and ask if it still fits on the machine available for your budget.
>> >
>> > The second level cache will still keep the last rendered page in
>> > memory as I understand it, so that 32MB will still be claimed,
>> > whatever store you choose.
>> >
>> > Martijn
>> >
>> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>> >>
>> >> :) Unfortunately it's not a joke, but I'm glad you're having fun :D.
>> >> Actually, this is result of worst case scenario simulation (I told you
>> >> that
>> >> there are heavy objects in the model). After making transient some of
>> the
>> >> fields, the size of the page dropped dramatically.
>> >>
>> >> Alex.
>> >>
>> >>
>> >> Johan Compagner wrote:
>> >> >
>> >> > you got to be kidding me...32MB????
>> >> > really? Or is this a nice joke so in the middle of the day :)
>> >> >
>> >> > johan
>> >> >
>> >> >
>> >> >
>> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>> >> >>
>> >> >>
>> >> >> It is about 32MB. Kind a big page :)
>> >> >>
>> >> >>
>> >> >> Matej Knopp-2 wrote:
>> >> >> >
>> >> >> > Turn on SecondLevelCacheSessionStore, and use FilePageStore as
>> >> >> > IPageStore (specified in session store constructor). Then go to
>> your
>> >> >> > tmp dir and you should be able to find the serialized pages
>> there.
>> >> >> >
>> >> >> > -Matej
>> >> >> >
>> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>> >> >> >>
>> >> >> >> How can I figure it out?
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> Johan Compagner wrote:
>> >> >> >> >
>> >> >> >> > if you save the page to disk how big is it?
>> >> >> >> >
>> >> >> >> > johan
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> Indeed, it is a very big component hierarchy (It contains at
>> >> least
>> >> >> 3
>> >> >> >> >> levels
>> >> >> >> >> of nested AjaxTabbedPanel components).
>> >> >> >> >> The application is, in fact, a single page and it uses a lot
>> of
>> >> >> ajax
>> >> >> >> to
>> >> >> >> >> perform the updates. The model reflect the component
>> hierarchy
>> >> >> >> >> (Appliction
>> >> >> >> >> has a single modelObject which nests another objects
>> >> corresponding
>> >> >> to
>> >> >> >> >> each
>> >> >> >> >> component). I do not have a lot of detaching logic, because
>> it
>> >> is
>> >> >> >> >> important
>> >> >> >> >> to have all the data in the model (caching), also because the
>> >> >> services
>> >> >> >> >> are
>> >> >> >> >> very costly operations.
>> >> >> >> >>
>> >> >> >> >> If this description is not enough for replication, I will be
>> >> glad
>> >> >> to
>> >> >> >> help
>> >> >> >> >> by
>> >> >> >> >> giving you another details.
>> >> >> >> >>
>> >> >> >> >> Alex.
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> Martijn Dashorst wrote:
>> >> >> >> >> >
>> >> >> >> >> > How big is the page? Sounds like a really, really big
>> >> component
>> >> >> >> >> > hierarchy. Then it sounds reasonable that the httpsession
>> >> store
>> >> >> is
>> >> >> >> >> > much faster: it keeps it in ram, and doesn't use
>> serialization
>> >> >> until
>> >> >> >> >> > the session is serialized (server shutting down, deciding
>> to
>> >> put
>> >> >> >> >> > session to disk or replication of session across cluster)
>> >> iirc.
>> >> >> >> >> >
>> >> >> >> >> > I think we would appreciate some way of replicating your
>> >> results.
>> >> >> I
>> >> >> >> >> > assume you can't share the actual code, but could you share
>> a
>> >> >> >> spin-off
>> >> >> >> >> > of the page's component structure and a Model that
>> replicates
>> >> the
>> >> >> >> data
>> >> >> >> >> > stuff's size (including the detach logic)?
>> >> >> >> >> >
>> >> >> >> >> > Martijn
>> >> >> >> >> >
>> >> >> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro>
>> wrote:
>> >> >> >> >> >>
>> >> >> >> >> >> If the pages wouldn't be serializable, it wouldn't work in
>> >> >> >> development
>> >> >> >> >> >> mode.
>> >> >> >> >> >> Is it right?
>> >> >> >> >> >>
>> >> >> >> >> >> I think that it is not necessarily about how large is
>> >> >> application,
>> >> >> >> in
>> >> >> >> >> my
>> >> >> >> >> >> case it is about how large is the model I'm working with
>> for
>> >> >> that
>> >> >> >> >> >> specific
>> >> >> >> >> >> request (ajax request).
>> >> >> >> >> >>
>> >> >> >> >> >> My action was: fetch a subview of a very large table
>> 300x300,
>> >> >> each
>> >> >> >> >> cell
>> >> >> >> >> >> has
>> >> >> >> >> >> a heavy model object.
>> >> >> >> >> >>
>> >> >> >> >> >> Alex.
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >> Johan Compagner wrote:
>> >> >> >> >> >> >
>> >> >> >> >> >> > that looks very strange to me. We have also a very large
>> >> app
>> >> >> here
>> >> >> >> >> and
>> >> >> >> >> >> we
>> >> >> >> >> >> > dont notice a difference
>> >> >> >> >> >> > So i am very curious what is happening at your place
>> then.
>> >> Are
>> >> >> >> you
>> >> >> >> >> sure
>> >> >> >> >> >> > for
>> >> >> >> >> >> > example that the pages
>> >> >> >> >> >> > are serializable ?  That we don't have constantly
>> >> exceptions?
>> >> >> >> >> >> >
>> >> >> >> >> >> > johan
>> >> >> >> >> >> >
>> >> >> >> >> >> >
>> >> >> >> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro>
>> >> wrote:
>> >> >> >> >> >> >>
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> Maybe the profiling was not a perfect one. But still, I
>> >> have
>> >> >> to
>> >> >> >> >> give
>> >> >> >> >> >> up
>> >> >> >> >> >> >> using
>> >> >> >> >> >> >> SecondSessionLevelStore just because the responsiveness
>> of
>> >> >> the
>> >> >> >> >> >> >> application
>> >> >> >> >> >> >> is very slow.
>> >> >> >> >> >> >>
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> Johan Compagner wrote:
>> >> >> >> >> >> >> >
>> >> >> >> >> >> >> > invocation count 1??
>> >> >> >> >> >> >> >
>> >> >> >> >> >> >> > So you only do 1 request and you profile that?
>> >> >> >> >> >> >> > thats not a good test. You have to do plenty and
>> >> multiply
>> >> >> on
>> >> >> >> the
>> >> >> >> >> >> same
>> >> >> >> >> >> >> > time
>> >> >> >> >> >> >> > (10 for 100 request or something like that)
>> >> >> >> >> >> >> > to really see the difference. (and have a warm up
>> phase)
>> >> >> >> >> >> >> >
>> >> >> >> >> >> >> > johan
>> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >
>> >> >> >> >> >> >> > On 9/10/07, Alex Objelean
>> <al...@isdc.ro>
>> >> >> wrote:
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> Matej, I must disagree with you regarding
>> performance
>> >> >> issues
>> >> >> >> of
>> >> >> >> >> the
>> >> >> >> >> >> >> >> SecondLevelSessionStore. I've reverted the
>> >> >> >> >> >> Application#newSessionStore
>> >> >> >> >> >> >> to
>> >> >> >> >> >> >> >> HttpSessionStore and this significantly improved the
>> >> >> >> application
>> >> >> >> >> >> >> overall
>> >> >> >> >> >> >> >> performance. Maybe this is not so obvious for small
>> >> >> >> >> applications,
>> >> >> >> >> >> but
>> >> >> >> >> >> >> >> when
>> >> >> >> >> >> >> >> it is about a large one - things changes.
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> Below, you will find attached two images. The first
>> one
>> >> is
>> >> >> a
>> >> >> >> >> >> profiling
>> >> >> >> >> >> >> of
>> >> >> >> >> >> >> >> an
>> >> >> >> >> >> >> >> action when working with HttpSessionStore, the
>> second
>> >> one
>> >> >> is
>> >> >> >> a
>> >> >> >> >> >> >> profiling
>> >> >> >> >> >> >> >> for
>> >> >> >> >> >> >> >> the same action when using SecondSessionLevelStore.
>> The
>> >> >> >> >> difference
>> >> >> >> >> >> is
>> >> >> >> >> >> >> >> huge:
>> >> >> >> >> >> >> >> 593ms vs 174420ms. I cannot explain what exactly is
>> >> going
>> >> >> on,
>> >> >> >> >> but
>> >> >> >> >> >> I've
>> >> >> >> >> >> >> >> noticed that by switching from default
>> >> >> >> SecondLevelSessionStore
>> >> >> >> >> to
>> >> >> >> >> >> the
>> >> >> >> >> >> >> >> HttpSessionStore improved a lot the responsiveness
>> of
>> >> the
>> >> >> >> >> >> application.
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> Alex.
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >>
>> >> http://www.nabble.com/file/p12588790/HttpSessionStore.jpg
>> >> >> >> >> >> >> >>
>> >> >> >> http://www.nabble.com/file/p12588790/SecondSessionLevelStore.jpg
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> Matej Knopp-2 wrote:
>> >> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >> > You can revert to httpsessionstore by changing
>> >> >> >> >> >> >> >> > Application.newSessionStore method. But that's not
>> >> >> >> >> recommended.
>> >> >> >> >> >> What
>> >> >> >> >> >> >> >> > are your performance problems? I doubt it is
>> caused
>> >> by
>> >> >> the
>> >> >> >> >> >> session
>> >> >> >> >> >> >> >> > store.
>> >> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >> > -Matej
>> >> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >> > On 9/7/07, jamieballing <ja...@hotmail.com>
>> >> >> wrote:
>> >> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> >> We are trying to do some performance
>> troubleshooting
>> >> >> and
>> >> >> >> want
>> >> >> >> >> to
>> >> >> >> >> >> >> >> disable
>> >> >> >> >> >> >> >> >> the
>> >> >> >> >> >> >> >> >> second level page cache.
>> >> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> >> Is there any way to do this?
>> >> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> >> Thanks,
>> >> >> >> >> >> >> >> >> Jamie
>> >> >> >> >> >> >> >> >> --
>> >> >> >> >> >> >> >> >> View this message in context:
>> >> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >>
>> >> >> >>
>> >> >>
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12563895
>> >> >> >> >> >> >> >> >> Sent from the Wicket - User mailing list archive
>> at
>> >> >> >> >> Nabble.com
>> >> >> >> >> .
>> >> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> >>
>> >> >> >> >> >> >>
>> >> >> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> >> >> >> >> >> To unsubscribe, e-mail:
>> >> >> >> users-unsubscribe@wicket.apache.org
>> >> >> >> >> >> >> >> >> For additional commands, e-mail:
>> >> >> >> users-help@wicket.apache.org
>> >> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >> >
>> >> >> >> >> >> >>
>> >> >> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> >> >> >> >> > To unsubscribe, e-mail:
>> >> >> users-unsubscribe@wicket.apache.org
>> >> >> >> >> >> >> >> > For additional commands, e-mail:
>> >> >> >> users-help@wicket.apache.org
>> >> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> --
>> >> >> >> >> >> >> >> View this message in context:
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >>
>> >> >> >>
>> >> >>
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12588790
>> >> >> >> >> >> >> >> Sent from the Wicket - User mailing list archive at
>> >> >> >> Nabble.com.
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> >> >> >> >> To unsubscribe, e-mail:
>> >> >> users-unsubscribe@wicket.apache.org
>> >> >> >> >> >> >> >> For additional commands, e-mail:
>> >> >> users-help@wicket.apache.org
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> --
>> >> >> >> >> >> >> View this message in context:
>> >> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >>
>> >> >> >>
>> >> >>
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589190
>> >> >> >> >> >> >> Sent from the Wicket - User mailing list archive at
>> >> >> Nabble.com
>> >> >> .
>> >> >> >> >> >> >>
>> >> >> >> >> >> >>
>> >> >> >> >> >> >>
>> >> >> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> >> >> >> To unsubscribe, e-mail:
>> >> users-unsubscribe@wicket.apache.org
>> >> >> >> >> >> >> For additional commands, e-mail:
>> >> users-help@wicket.apache.org
>> >> >> >> >> >> >>
>> >> >> >> >> >> >>
>> >> >> >> >> >> >
>> >> >> >> >> >> >
>> >> >> >> >> >>
>> >> >> >> >> >> --
>> >> >> >> >> >> View this message in context:
>> >> >> >> >> >>
>> >> >> >> >>
>> >> >> >>
>> >> >>
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589567
>> >> >> >> >> >> Sent from the Wicket - User mailing list archive at
>> >> Nabble.com.
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> >> >> To unsubscribe, e-mail:
>> users-unsubscribe@wicket.apache.org
>> >> >> >> >> >> For additional commands, e-mail:
>> users-help@wicket.apache.org
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> > --
>> >> >> >> >> > Buy Wicket in Action: http://manning.com/dashorst
>> >> >> >> >> > Apache Wicket 1.3.0-beta3 is released
>> >> >> >> >> > Get it now:
>> >> >> http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >> >> > For additional commands, e-mail:
>> users-help@wicket.apache.org
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >>
>> >> >> >> >> --
>> >> >> >> >> View this message in context:
>> >> >> >> >>
>> >> >> >>
>> >> >>
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12590414
>> >> >> >> >> Sent from the Wicket - User mailing list archive at
>> Nabble.com
>> .
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >
>> >> >> >> >
>> >> >> >>
>> >> >> >> --
>> >> >> >> View this message in context:
>> >> >> >>
>> >> >>
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12590627
>> >> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> ---------------------------------------------------------------------
>> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> --
>> >> >> View this message in context:
>> >> >>
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12591276
>> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >> >>
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12592522
>> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > Buy Wicket in Action: http://manning.com/dashorst
>> > Apache Wicket 1.3.0-beta3 is released
>> > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12592818
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
> 
> 

-- 
View this message in context: http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12593058
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Disable the SecondLevelPageCache?

Posted by Johan Compagner <jc...@gmail.com>.

if you just have 1 page with no back button support/all ajax
then httpsessionstore is fine

johan


On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>
>
> It is a intranet application, so the number of users for this application
> is
> at most ~30-40 users/day. A back button support is not needed, because
> there
> is a single page and also it doesn't make sense (since it is all ajax).
> I'm still wondering, what is best in this case:
> * Using HttpSessionStore
> * Use 2nd level session store and make transient heavy object references.
>
> Alex.
>
>
>
> Martijn Dashorst wrote:
> >
> > The only caveat you'll have is whether or not the backbutton is
> > supported long enough, and how many copies of that page you want to
> > have in memory.
> >
> > If the non-2nd level cache way works for you, then there is absolutely
> > nobody telling you to stop using it. The difference has mostly to do
> > with providing backbutton support and optimizing memory usage. In your
> > case it is probably best to limit the backbutton, as you claim to work
> > a lot with ajax. So the back button functionality is probably already
> > not working (users can press it, but they will leave your site, or go
> > back to the login page).
> >
> > Profile the memory usage, multiply with the number of users you expect
> > and ask if it still fits on the machine available for your budget.
> >
> > The second level cache will still keep the last rendered page in
> > memory as I understand it, so that 32MB will still be claimed,
> > whatever store you choose.
> >
> > Martijn
> >
> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
> >>
> >> :) Unfortunately it's not a joke, but I'm glad you're having fun :D.
> >> Actually, this is result of worst case scenario simulation (I told you
> >> that
> >> there are heavy objects in the model). After making transient some of
> the
> >> fields, the size of the page dropped dramatically.
> >>
> >> Alex.
> >>
> >>
> >> Johan Compagner wrote:
> >> >
> >> > you got to be kidding me...32MB????
> >> > really? Or is this a nice joke so in the middle of the day :)
> >> >
> >> > johan
> >> >
> >> >
> >> >
> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
> >> >>
> >> >>
> >> >> It is about 32MB. Kind a big page :)
> >> >>
> >> >>
> >> >> Matej Knopp-2 wrote:
> >> >> >
> >> >> > Turn on SecondLevelCacheSessionStore, and use FilePageStore as
> >> >> > IPageStore (specified in session store constructor). Then go to
> your
> >> >> > tmp dir and you should be able to find the serialized pages there.
> >> >> >
> >> >> > -Matej
> >> >> >
> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
> >> >> >>
> >> >> >> How can I figure it out?
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> Johan Compagner wrote:
> >> >> >> >
> >> >> >> > if you save the page to disk how big is it?
> >> >> >> >
> >> >> >> > johan
> >> >> >> >
> >> >> >> >
> >> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> Indeed, it is a very big component hierarchy (It contains at
> >> least
> >> >> 3
> >> >> >> >> levels
> >> >> >> >> of nested AjaxTabbedPanel components).
> >> >> >> >> The application is, in fact, a single page and it uses a lot
> of
> >> >> ajax
> >> >> >> to
> >> >> >> >> perform the updates. The model reflect the component hierarchy
> >> >> >> >> (Appliction
> >> >> >> >> has a single modelObject which nests another objects
> >> corresponding
> >> >> to
> >> >> >> >> each
> >> >> >> >> component). I do not have a lot of detaching logic, because it
> >> is
> >> >> >> >> important
> >> >> >> >> to have all the data in the model (caching), also because the
> >> >> services
> >> >> >> >> are
> >> >> >> >> very costly operations.
> >> >> >> >>
> >> >> >> >> If this description is not enough for replication, I will be
> >> glad
> >> >> to
> >> >> >> help
> >> >> >> >> by
> >> >> >> >> giving you another details.
> >> >> >> >>
> >> >> >> >> Alex.
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> Martijn Dashorst wrote:
> >> >> >> >> >
> >> >> >> >> > How big is the page? Sounds like a really, really big
> >> component
> >> >> >> >> > hierarchy. Then it sounds reasonable that the httpsession
> >> store
> >> >> is
> >> >> >> >> > much faster: it keeps it in ram, and doesn't use
> serialization
> >> >> until
> >> >> >> >> > the session is serialized (server shutting down, deciding to
> >> put
> >> >> >> >> > session to disk or replication of session across cluster)
> >> iirc.
> >> >> >> >> >
> >> >> >> >> > I think we would appreciate some way of replicating your
> >> results.
> >> >> I
> >> >> >> >> > assume you can't share the actual code, but could you share
> a
> >> >> >> spin-off
> >> >> >> >> > of the page's component structure and a Model that
> replicates
> >> the
> >> >> >> data
> >> >> >> >> > stuff's size (including the detach logic)?
> >> >> >> >> >
> >> >> >> >> > Martijn
> >> >> >> >> >
> >> >> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro>
> wrote:
> >> >> >> >> >>
> >> >> >> >> >> If the pages wouldn't be serializable, it wouldn't work in
> >> >> >> development
> >> >> >> >> >> mode.
> >> >> >> >> >> Is it right?
> >> >> >> >> >>
> >> >> >> >> >> I think that it is not necessarily about how large is
> >> >> application,
> >> >> >> in
> >> >> >> >> my
> >> >> >> >> >> case it is about how large is the model I'm working with
> for
> >> >> that
> >> >> >> >> >> specific
> >> >> >> >> >> request (ajax request).
> >> >> >> >> >>
> >> >> >> >> >> My action was: fetch a subview of a very large table
> 300x300,
> >> >> each
> >> >> >> >> cell
> >> >> >> >> >> has
> >> >> >> >> >> a heavy model object.
> >> >> >> >> >>
> >> >> >> >> >> Alex.
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >> Johan Compagner wrote:
> >> >> >> >> >> >
> >> >> >> >> >> > that looks very strange to me. We have also a very large
> >> app
> >> >> here
> >> >> >> >> and
> >> >> >> >> >> we
> >> >> >> >> >> > dont notice a difference
> >> >> >> >> >> > So i am very curious what is happening at your place
> then.
> >> Are
> >> >> >> you
> >> >> >> >> sure
> >> >> >> >> >> > for
> >> >> >> >> >> > example that the pages
> >> >> >> >> >> > are serializable ?  That we don't have constantly
> >> exceptions?
> >> >> >> >> >> >
> >> >> >> >> >> > johan
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro>
> >> wrote:
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >> Maybe the profiling was not a perfect one. But still, I
> >> have
> >> >> to
> >> >> >> >> give
> >> >> >> >> >> up
> >> >> >> >> >> >> using
> >> >> >> >> >> >> SecondSessionLevelStore just because the responsiveness
> of
> >> >> the
> >> >> >> >> >> >> application
> >> >> >> >> >> >> is very slow.
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >> Johan Compagner wrote:
> >> >> >> >> >> >> >
> >> >> >> >> >> >> > invocation count 1??
> >> >> >> >> >> >> >
> >> >> >> >> >> >> > So you only do 1 request and you profile that?
> >> >> >> >> >> >> > thats not a good test. You have to do plenty and
> >> multiply
> >> >> on
> >> >> >> the
> >> >> >> >> >> same
> >> >> >> >> >> >> > time
> >> >> >> >> >> >> > (10 for 100 request or something like that)
> >> >> >> >> >> >> > to really see the difference. (and have a warm up
> phase)
> >> >> >> >> >> >> >
> >> >> >> >> >> >> > johan
> >> >> >> >> >> >> >
> >> >> >> >> >> >> >
> >> >> >> >> >> >> >
> >> >> >> >> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro>
> >> >> wrote:
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> Matej, I must disagree with you regarding performance
> >> >> issues
> >> >> >> of
> >> >> >> >> the
> >> >> >> >> >> >> >> SecondLevelSessionStore. I've reverted the
> >> >> >> >> >> Application#newSessionStore
> >> >> >> >> >> >> to
> >> >> >> >> >> >> >> HttpSessionStore and this significantly improved the
> >> >> >> application
> >> >> >> >> >> >> overall
> >> >> >> >> >> >> >> performance. Maybe this is not so obvious for small
> >> >> >> >> applications,
> >> >> >> >> >> but
> >> >> >> >> >> >> >> when
> >> >> >> >> >> >> >> it is about a large one - things changes.
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> Below, you will find attached two images. The first
> one
> >> is
> >> >> a
> >> >> >> >> >> profiling
> >> >> >> >> >> >> of
> >> >> >> >> >> >> >> an
> >> >> >> >> >> >> >> action when working with HttpSessionStore, the second
> >> one
> >> >> is
> >> >> >> a
> >> >> >> >> >> >> profiling
> >> >> >> >> >> >> >> for
> >> >> >> >> >> >> >> the same action when using SecondSessionLevelStore.
> The
> >> >> >> >> difference
> >> >> >> >> >> is
> >> >> >> >> >> >> >> huge:
> >> >> >> >> >> >> >> 593ms vs 174420ms. I cannot explain what exactly is
> >> going
> >> >> on,
> >> >> >> >> but
> >> >> >> >> >> I've
> >> >> >> >> >> >> >> noticed that by switching from default
> >> >> >> SecondLevelSessionStore
> >> >> >> >> to
> >> >> >> >> >> the
> >> >> >> >> >> >> >> HttpSessionStore improved a lot the responsiveness of
> >> the
> >> >> >> >> >> application.
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> Alex.
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >>
> >> http://www.nabble.com/file/p12588790/HttpSessionStore.jpg
> >> >> >> >> >> >> >>
> >> >> >> http://www.nabble.com/file/p12588790/SecondSessionLevelStore.jpg
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> Matej Knopp-2 wrote:
> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> > You can revert to httpsessionstore by changing
> >> >> >> >> >> >> >> > Application.newSessionStore method. But that's not
> >> >> >> >> recommended.
> >> >> >> >> >> What
> >> >> >> >> >> >> >> > are your performance problems? I doubt it is caused
> >> by
> >> >> the
> >> >> >> >> >> session
> >> >> >> >> >> >> >> > store.
> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> > -Matej
> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> > On 9/7/07, jamieballing <ja...@hotmail.com>
> >> >> wrote:
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> We are trying to do some performance
> troubleshooting
> >> >> and
> >> >> >> want
> >> >> >> >> to
> >> >> >> >> >> >> >> disable
> >> >> >> >> >> >> >> >> the
> >> >> >> >> >> >> >> >> second level page cache.
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> Is there any way to do this?
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> Thanks,
> >> >> >> >> >> >> >> >> Jamie
> >> >> >> >> >> >> >> >> --
> >> >> >> >> >> >> >> >> View this message in context:
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >>
> >> >> >>
> >> >>
> >>
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12563895
> >> >> >> >> >> >> >> >> Sent from the Wicket - User mailing list archive
> at
> >> >> >> >> Nabble.com
> >> >> >> >> .
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> >> >> >> >> >> >> To unsubscribe, e-mail:
> >> >> >> users-unsubscribe@wicket.apache.org
> >> >> >> >> >> >> >> >> For additional commands, e-mail:
> >> >> >> users-help@wicket.apache.org
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> >
> >> >> >> >> >> >>
> >> >> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> >> >> >> >> >> > To unsubscribe, e-mail:
> >> >> users-unsubscribe@wicket.apache.org
> >> >> >> >> >> >> >> > For additional commands, e-mail:
> >> >> >> users-help@wicket.apache.org
> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> --
> >> >> >> >> >> >> >> View this message in context:
> >> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >>
> >> >> >>
> >> >>
> >>
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12588790
> >> >> >> >> >> >> >> Sent from the Wicket - User mailing list archive at
> >> >> >> Nabble.com.
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >> >> >> >> To unsubscribe, e-mail:
> >> >> users-unsubscribe@wicket.apache.org
> >> >> >> >> >> >> >> For additional commands, e-mail:
> >> >> users-help@wicket.apache.org
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >
> >> >> >> >> >> >> >
> >> >> >> >> >> >>
> >> >> >> >> >> >> --
> >> >> >> >> >> >> View this message in context:
> >> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >>
> >> >> >>
> >> >>
> >>
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589190
> >> >> >> >> >> >> Sent from the Wicket - User mailing list archive at
> >> >> Nabble.com
> >> >> .
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> >> >> >> >> To unsubscribe, e-mail:
> >> users-unsubscribe@wicket.apache.org
> >> >> >> >> >> >> For additional commands, e-mail:
> >> users-help@wicket.apache.org
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >> >>
> >> >> >> >> >> --
> >> >> >> >> >> View this message in context:
> >> >> >> >> >>
> >> >> >> >>
> >> >> >>
> >> >>
> >>
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589567
> >> >> >> >> >> Sent from the Wicket - User mailing list archive at
> >> Nabble.com.
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> >> >> For additional commands, e-mail:
> users-help@wicket.apache.org
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> > --
> >> >> >> >> > Buy Wicket in Action: http://manning.com/dashorst
> >> >> >> >> > Apache Wicket 1.3.0-beta3 is released
> >> >> >> >> > Get it now:
> >> >> http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
> >> >> >> >> >
> >> >> >> >> >
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> >> > For additional commands, e-mail:
> users-help@wicket.apache.org
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >> --
> >> >> >> >> View this message in context:
> >> >> >> >>
> >> >> >>
> >> >>
> >>
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12590414
> >> >> >> >> Sent from the Wicket - User mailing list archive at Nabble.com
> .
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >> --
> >> >> >> View this message in context:
> >> >> >>
> >> >>
> >>
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12590627
> >> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >> >> >>
> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> View this message in context:
> >> >>
> >>
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12591276
> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12592522
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
> > --
> > Buy Wicket in Action: http://manning.com/dashorst
> > Apache Wicket 1.3.0-beta3 is released
> > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12592818
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

Re: Disable the SecondLevelPageCache?

Posted by Alex Objelean <al...@isdc.ro>.

It is a intranet application, so the number of users for this application is
at most ~30-40 users/day. A back button support is not needed, because there
is a single page and also it doesn't make sense (since it is all ajax). 
I'm still wondering, what is best in this case: 
* Using HttpSessionStore
* Use 2nd level session store and make transient heavy object references.

Alex.



Martijn Dashorst wrote:
> 
> The only caveat you'll have is whether or not the backbutton is
> supported long enough, and how many copies of that page you want to
> have in memory.
> 
> If the non-2nd level cache way works for you, then there is absolutely
> nobody telling you to stop using it. The difference has mostly to do
> with providing backbutton support and optimizing memory usage. In your
> case it is probably best to limit the backbutton, as you claim to work
> a lot with ajax. So the back button functionality is probably already
> not working (users can press it, but they will leave your site, or go
> back to the login page).
> 
> Profile the memory usage, multiply with the number of users you expect
> and ask if it still fits on the machine available for your budget.
> 
> The second level cache will still keep the last rendered page in
> memory as I understand it, so that 32MB will still be claimed,
> whatever store you choose.
> 
> Martijn
> 
> On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>>
>> :) Unfortunately it's not a joke, but I'm glad you're having fun :D.
>> Actually, this is result of worst case scenario simulation (I told you
>> that
>> there are heavy objects in the model). After making transient some of the
>> fields, the size of the page dropped dramatically.
>>
>> Alex.
>>
>>
>> Johan Compagner wrote:
>> >
>> > you got to be kidding me...32MB????
>> > really? Or is this a nice joke so in the middle of the day :)
>> >
>> > johan
>> >
>> >
>> >
>> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>> >>
>> >>
>> >> It is about 32MB. Kind a big page :)
>> >>
>> >>
>> >> Matej Knopp-2 wrote:
>> >> >
>> >> > Turn on SecondLevelCacheSessionStore, and use FilePageStore as
>> >> > IPageStore (specified in session store constructor). Then go to your
>> >> > tmp dir and you should be able to find the serialized pages there.
>> >> >
>> >> > -Matej
>> >> >
>> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>> >> >>
>> >> >> How can I figure it out?
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> Johan Compagner wrote:
>> >> >> >
>> >> >> > if you save the page to disk how big is it?
>> >> >> >
>> >> >> > johan
>> >> >> >
>> >> >> >
>> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>> >> >> >>
>> >> >> >>
>> >> >> >> Indeed, it is a very big component hierarchy (It contains at
>> least
>> >> 3
>> >> >> >> levels
>> >> >> >> of nested AjaxTabbedPanel components).
>> >> >> >> The application is, in fact, a single page and it uses a lot of
>> >> ajax
>> >> >> to
>> >> >> >> perform the updates. The model reflect the component hierarchy
>> >> >> >> (Appliction
>> >> >> >> has a single modelObject which nests another objects
>> corresponding
>> >> to
>> >> >> >> each
>> >> >> >> component). I do not have a lot of detaching logic, because it
>> is
>> >> >> >> important
>> >> >> >> to have all the data in the model (caching), also because the
>> >> services
>> >> >> >> are
>> >> >> >> very costly operations.
>> >> >> >>
>> >> >> >> If this description is not enough for replication, I will be
>> glad
>> >> to
>> >> >> help
>> >> >> >> by
>> >> >> >> giving you another details.
>> >> >> >>
>> >> >> >> Alex.
>> >> >> >>
>> >> >> >>
>> >> >> >> Martijn Dashorst wrote:
>> >> >> >> >
>> >> >> >> > How big is the page? Sounds like a really, really big
>> component
>> >> >> >> > hierarchy. Then it sounds reasonable that the httpsession
>> store
>> >> is
>> >> >> >> > much faster: it keeps it in ram, and doesn't use serialization
>> >> until
>> >> >> >> > the session is serialized (server shutting down, deciding to
>> put
>> >> >> >> > session to disk or replication of session across cluster)
>> iirc.
>> >> >> >> >
>> >> >> >> > I think we would appreciate some way of replicating your
>> results.
>> >> I
>> >> >> >> > assume you can't share the actual code, but could you share a
>> >> >> spin-off
>> >> >> >> > of the page's component structure and a Model that replicates
>> the
>> >> >> data
>> >> >> >> > stuff's size (including the detach logic)?
>> >> >> >> >
>> >> >> >> > Martijn
>> >> >> >> >
>> >> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>> >> >> >> >>
>> >> >> >> >> If the pages wouldn't be serializable, it wouldn't work in
>> >> >> development
>> >> >> >> >> mode.
>> >> >> >> >> Is it right?
>> >> >> >> >>
>> >> >> >> >> I think that it is not necessarily about how large is
>> >> application,
>> >> >> in
>> >> >> >> my
>> >> >> >> >> case it is about how large is the model I'm working with for
>> >> that
>> >> >> >> >> specific
>> >> >> >> >> request (ajax request).
>> >> >> >> >>
>> >> >> >> >> My action was: fetch a subview of a very large table 300x300,
>> >> each
>> >> >> >> cell
>> >> >> >> >> has
>> >> >> >> >> a heavy model object.
>> >> >> >> >>
>> >> >> >> >> Alex.
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> Johan Compagner wrote:
>> >> >> >> >> >
>> >> >> >> >> > that looks very strange to me. We have also a very large
>> app
>> >> here
>> >> >> >> and
>> >> >> >> >> we
>> >> >> >> >> > dont notice a difference
>> >> >> >> >> > So i am very curious what is happening at your place then.
>> Are
>> >> >> you
>> >> >> >> sure
>> >> >> >> >> > for
>> >> >> >> >> > example that the pages
>> >> >> >> >> > are serializable ?  That we don't have constantly
>> exceptions?
>> >> >> >> >> >
>> >> >> >> >> > johan
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro>
>> wrote:
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >> Maybe the profiling was not a perfect one. But still, I
>> have
>> >> to
>> >> >> >> give
>> >> >> >> >> up
>> >> >> >> >> >> using
>> >> >> >> >> >> SecondSessionLevelStore just because the responsiveness of
>> >> the
>> >> >> >> >> >> application
>> >> >> >> >> >> is very slow.
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >> Johan Compagner wrote:
>> >> >> >> >> >> >
>> >> >> >> >> >> > invocation count 1??
>> >> >> >> >> >> >
>> >> >> >> >> >> > So you only do 1 request and you profile that?
>> >> >> >> >> >> > thats not a good test. You have to do plenty and
>> multiply
>> >> on
>> >> >> the
>> >> >> >> >> same
>> >> >> >> >> >> > time
>> >> >> >> >> >> > (10 for 100 request or something like that)
>> >> >> >> >> >> > to really see the difference. (and have a warm up phase)
>> >> >> >> >> >> >
>> >> >> >> >> >> > johan
>> >> >> >> >> >> >
>> >> >> >> >> >> >
>> >> >> >> >> >> >
>> >> >> >> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro>
>> >> wrote:
>> >> >> >> >> >> >>
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> Matej, I must disagree with you regarding performance
>> >> issues
>> >> >> of
>> >> >> >> the
>> >> >> >> >> >> >> SecondLevelSessionStore. I've reverted the
>> >> >> >> >> Application#newSessionStore
>> >> >> >> >> >> to
>> >> >> >> >> >> >> HttpSessionStore and this significantly improved the
>> >> >> application
>> >> >> >> >> >> overall
>> >> >> >> >> >> >> performance. Maybe this is not so obvious for small
>> >> >> >> applications,
>> >> >> >> >> but
>> >> >> >> >> >> >> when
>> >> >> >> >> >> >> it is about a large one - things changes.
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> Below, you will find attached two images. The first one
>> is
>> >> a
>> >> >> >> >> profiling
>> >> >> >> >> >> of
>> >> >> >> >> >> >> an
>> >> >> >> >> >> >> action when working with HttpSessionStore, the second
>> one
>> >> is
>> >> >> a
>> >> >> >> >> >> profiling
>> >> >> >> >> >> >> for
>> >> >> >> >> >> >> the same action when using SecondSessionLevelStore. The
>> >> >> >> difference
>> >> >> >> >> is
>> >> >> >> >> >> >> huge:
>> >> >> >> >> >> >> 593ms vs 174420ms. I cannot explain what exactly is
>> going
>> >> on,
>> >> >> >> but
>> >> >> >> >> I've
>> >> >> >> >> >> >> noticed that by switching from default
>> >> >> SecondLevelSessionStore
>> >> >> >> to
>> >> >> >> >> the
>> >> >> >> >> >> >> HttpSessionStore improved a lot the responsiveness of
>> the
>> >> >> >> >> application.
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> Alex.
>> >> >> >> >> >> >>
>> >> >> >> >> >> >>
>> http://www.nabble.com/file/p12588790/HttpSessionStore.jpg
>> >> >> >> >> >> >>
>> >> >> http://www.nabble.com/file/p12588790/SecondSessionLevelStore.jpg
>> >> >> >> >> >> >>
>> >> >> >> >> >> >>
>> >> >> >> >> >> >>
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> Matej Knopp-2 wrote:
>> >> >> >> >> >> >> >
>> >> >> >> >> >> >> > You can revert to httpsessionstore by changing
>> >> >> >> >> >> >> > Application.newSessionStore method. But that's not
>> >> >> >> recommended.
>> >> >> >> >> What
>> >> >> >> >> >> >> > are your performance problems? I doubt it is caused
>> by
>> >> the
>> >> >> >> >> session
>> >> >> >> >> >> >> > store.
>> >> >> >> >> >> >> >
>> >> >> >> >> >> >> > -Matej
>> >> >> >> >> >> >> >
>> >> >> >> >> >> >> > On 9/7/07, jamieballing <ja...@hotmail.com>
>> >> wrote:
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> We are trying to do some performance troubleshooting
>> >> and
>> >> >> want
>> >> >> >> to
>> >> >> >> >> >> >> disable
>> >> >> >> >> >> >> >> the
>> >> >> >> >> >> >> >> second level page cache.
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> Is there any way to do this?
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> Thanks,
>> >> >> >> >> >> >> >> Jamie
>> >> >> >> >> >> >> >> --
>> >> >> >> >> >> >> >> View this message in context:
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >>
>> >> >> >>
>> >> >>
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12563895
>> >> >> >> >> >> >> >> Sent from the Wicket - User mailing list archive at
>> >> >> >> Nabble.com
>> >> >> >> .
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> >> >> >> >> To unsubscribe, e-mail:
>> >> >> users-unsubscribe@wicket.apache.org
>> >> >> >> >> >> >> >> For additional commands, e-mail:
>> >> >> users-help@wicket.apache.org
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >
>> >> >> >> >> >>
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> >> >> >> > To unsubscribe, e-mail:
>> >> users-unsubscribe@wicket.apache.org
>> >> >> >> >> >> >> > For additional commands, e-mail:
>> >> >> users-help@wicket.apache.org
>> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >
>> >> >> >> >> >> >> >
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> --
>> >> >> >> >> >> >> View this message in context:
>> >> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >>
>> >> >> >>
>> >> >>
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12588790
>> >> >> >> >> >> >> Sent from the Wicket - User mailing list archive at
>> >> >> Nabble.com.
>> >> >> >> >> >> >>
>> >> >> >> >> >> >>
>> >> >> >> >> >> >>
>> >> >> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> >> >> >> To unsubscribe, e-mail:
>> >> users-unsubscribe@wicket.apache.org
>> >> >> >> >> >> >> For additional commands, e-mail:
>> >> users-help@wicket.apache.org
>> >> >> >> >> >> >>
>> >> >> >> >> >> >>
>> >> >> >> >> >> >
>> >> >> >> >> >> >
>> >> >> >> >> >>
>> >> >> >> >> >> --
>> >> >> >> >> >> View this message in context:
>> >> >> >> >> >>
>> >> >> >> >>
>> >> >> >>
>> >> >>
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589190
>> >> >> >> >> >> Sent from the Wicket - User mailing list archive at
>> >> Nabble.com
>> >> .
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> >> >> To unsubscribe, e-mail:
>> users-unsubscribe@wicket.apache.org
>> >> >> >> >> >> For additional commands, e-mail:
>> users-help@wicket.apache.org
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >>
>> >> >> >> >> --
>> >> >> >> >> View this message in context:
>> >> >> >> >>
>> >> >> >>
>> >> >>
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589567
>> >> >> >> >> Sent from the Wicket - User mailing list archive at
>> Nabble.com.
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > --
>> >> >> >> > Buy Wicket in Action: http://manning.com/dashorst
>> >> >> >> > Apache Wicket 1.3.0-beta3 is released
>> >> >> >> > Get it now:
>> >> http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
>> >> >> >> >
>> >> >> >> >
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >>
>> >> >> >> --
>> >> >> >> View this message in context:
>> >> >> >>
>> >> >>
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12590414
>> >> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> --
>> >> >> View this message in context:
>> >> >>
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12590627
>> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >> >>
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12591276
>> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12592522
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
> 
> 
> -- 
> Buy Wicket in Action: http://manning.com/dashorst
> Apache Wicket 1.3.0-beta3 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12592818
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Disable the SecondLevelPageCache?

Posted by Martijn Dashorst <ma...@gmail.com>.

The only caveat you'll have is whether or not the backbutton is
supported long enough, and how many copies of that page you want to
have in memory.

If the non-2nd level cache way works for you, then there is absolutely
nobody telling you to stop using it. The difference has mostly to do
with providing backbutton support and optimizing memory usage. In your
case it is probably best to limit the backbutton, as you claim to work
a lot with ajax. So the back button functionality is probably already
not working (users can press it, but they will leave your site, or go
back to the login page).

Profile the memory usage, multiply with the number of users you expect
and ask if it still fits on the machine available for your budget.

The second level cache will still keep the last rendered page in
memory as I understand it, so that 32MB will still be claimed,
whatever store you choose.

Martijn

On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>
> :) Unfortunately it's not a joke, but I'm glad you're having fun :D.
> Actually, this is result of worst case scenario simulation (I told you that
> there are heavy objects in the model). After making transient some of the
> fields, the size of the page dropped dramatically.
>
> Alex.
>
>
> Johan Compagner wrote:
> >
> > you got to be kidding me...32MB????
> > really? Or is this a nice joke so in the middle of the day :)
> >
> > johan
> >
> >
> >
> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
> >>
> >>
> >> It is about 32MB. Kind a big page :)
> >>
> >>
> >> Matej Knopp-2 wrote:
> >> >
> >> > Turn on SecondLevelCacheSessionStore, and use FilePageStore as
> >> > IPageStore (specified in session store constructor). Then go to your
> >> > tmp dir and you should be able to find the serialized pages there.
> >> >
> >> > -Matej
> >> >
> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
> >> >>
> >> >> How can I figure it out?
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> Johan Compagner wrote:
> >> >> >
> >> >> > if you save the page to disk how big is it?
> >> >> >
> >> >> > johan
> >> >> >
> >> >> >
> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
> >> >> >>
> >> >> >>
> >> >> >> Indeed, it is a very big component hierarchy (It contains at least
> >> 3
> >> >> >> levels
> >> >> >> of nested AjaxTabbedPanel components).
> >> >> >> The application is, in fact, a single page and it uses a lot of
> >> ajax
> >> >> to
> >> >> >> perform the updates. The model reflect the component hierarchy
> >> >> >> (Appliction
> >> >> >> has a single modelObject which nests another objects corresponding
> >> to
> >> >> >> each
> >> >> >> component). I do not have a lot of detaching logic, because it is
> >> >> >> important
> >> >> >> to have all the data in the model (caching), also because the
> >> services
> >> >> >> are
> >> >> >> very costly operations.
> >> >> >>
> >> >> >> If this description is not enough for replication, I will be glad
> >> to
> >> >> help
> >> >> >> by
> >> >> >> giving you another details.
> >> >> >>
> >> >> >> Alex.
> >> >> >>
> >> >> >>
> >> >> >> Martijn Dashorst wrote:
> >> >> >> >
> >> >> >> > How big is the page? Sounds like a really, really big component
> >> >> >> > hierarchy. Then it sounds reasonable that the httpsession store
> >> is
> >> >> >> > much faster: it keeps it in ram, and doesn't use serialization
> >> until
> >> >> >> > the session is serialized (server shutting down, deciding to put
> >> >> >> > session to disk or replication of session across cluster) iirc.
> >> >> >> >
> >> >> >> > I think we would appreciate some way of replicating your results.
> >> I
> >> >> >> > assume you can't share the actual code, but could you share a
> >> >> spin-off
> >> >> >> > of the page's component structure and a Model that replicates the
> >> >> data
> >> >> >> > stuff's size (including the detach logic)?
> >> >> >> >
> >> >> >> > Martijn
> >> >> >> >
> >> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
> >> >> >> >>
> >> >> >> >> If the pages wouldn't be serializable, it wouldn't work in
> >> >> development
> >> >> >> >> mode.
> >> >> >> >> Is it right?
> >> >> >> >>
> >> >> >> >> I think that it is not necessarily about how large is
> >> application,
> >> >> in
> >> >> >> my
> >> >> >> >> case it is about how large is the model I'm working with for
> >> that
> >> >> >> >> specific
> >> >> >> >> request (ajax request).
> >> >> >> >>
> >> >> >> >> My action was: fetch a subview of a very large table 300x300,
> >> each
> >> >> >> cell
> >> >> >> >> has
> >> >> >> >> a heavy model object.
> >> >> >> >>
> >> >> >> >> Alex.
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> Johan Compagner wrote:
> >> >> >> >> >
> >> >> >> >> > that looks very strange to me. We have also a very large app
> >> here
> >> >> >> and
> >> >> >> >> we
> >> >> >> >> > dont notice a difference
> >> >> >> >> > So i am very curious what is happening at your place then. Are
> >> >> you
> >> >> >> sure
> >> >> >> >> > for
> >> >> >> >> > example that the pages
> >> >> >> >> > are serializable ?  That we don't have constantly exceptions?
> >> >> >> >> >
> >> >> >> >> > johan
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >> Maybe the profiling was not a perfect one. But still, I have
> >> to
> >> >> >> give
> >> >> >> >> up
> >> >> >> >> >> using
> >> >> >> >> >> SecondSessionLevelStore just because the responsiveness of
> >> the
> >> >> >> >> >> application
> >> >> >> >> >> is very slow.
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >> Johan Compagner wrote:
> >> >> >> >> >> >
> >> >> >> >> >> > invocation count 1??
> >> >> >> >> >> >
> >> >> >> >> >> > So you only do 1 request and you profile that?
> >> >> >> >> >> > thats not a good test. You have to do plenty and multiply
> >> on
> >> >> the
> >> >> >> >> same
> >> >> >> >> >> > time
> >> >> >> >> >> > (10 for 100 request or something like that)
> >> >> >> >> >> > to really see the difference. (and have a warm up phase)
> >> >> >> >> >> >
> >> >> >> >> >> > johan
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro>
> >> wrote:
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >> Matej, I must disagree with you regarding performance
> >> issues
> >> >> of
> >> >> >> the
> >> >> >> >> >> >> SecondLevelSessionStore. I've reverted the
> >> >> >> >> Application#newSessionStore
> >> >> >> >> >> to
> >> >> >> >> >> >> HttpSessionStore and this significantly improved the
> >> >> application
> >> >> >> >> >> overall
> >> >> >> >> >> >> performance. Maybe this is not so obvious for small
> >> >> >> applications,
> >> >> >> >> but
> >> >> >> >> >> >> when
> >> >> >> >> >> >> it is about a large one - things changes.
> >> >> >> >> >> >>
> >> >> >> >> >> >> Below, you will find attached two images. The first one is
> >> a
> >> >> >> >> profiling
> >> >> >> >> >> of
> >> >> >> >> >> >> an
> >> >> >> >> >> >> action when working with HttpSessionStore, the second one
> >> is
> >> >> a
> >> >> >> >> >> profiling
> >> >> >> >> >> >> for
> >> >> >> >> >> >> the same action when using SecondSessionLevelStore. The
> >> >> >> difference
> >> >> >> >> is
> >> >> >> >> >> >> huge:
> >> >> >> >> >> >> 593ms vs 174420ms. I cannot explain what exactly is going
> >> on,
> >> >> >> but
> >> >> >> >> I've
> >> >> >> >> >> >> noticed that by switching from default
> >> >> SecondLevelSessionStore
> >> >> >> to
> >> >> >> >> the
> >> >> >> >> >> >> HttpSessionStore improved a lot the responsiveness of the
> >> >> >> >> application.
> >> >> >> >> >> >>
> >> >> >> >> >> >> Alex.
> >> >> >> >> >> >>
> >> >> >> >> >> >> http://www.nabble.com/file/p12588790/HttpSessionStore.jpg
> >> >> >> >> >> >>
> >> >> http://www.nabble.com/file/p12588790/SecondSessionLevelStore.jpg
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >> Matej Knopp-2 wrote:
> >> >> >> >> >> >> >
> >> >> >> >> >> >> > You can revert to httpsessionstore by changing
> >> >> >> >> >> >> > Application.newSessionStore method. But that's not
> >> >> >> recommended.
> >> >> >> >> What
> >> >> >> >> >> >> > are your performance problems? I doubt it is caused by
> >> the
> >> >> >> >> session
> >> >> >> >> >> >> > store.
> >> >> >> >> >> >> >
> >> >> >> >> >> >> > -Matej
> >> >> >> >> >> >> >
> >> >> >> >> >> >> > On 9/7/07, jamieballing <ja...@hotmail.com>
> >> wrote:
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> We are trying to do some performance troubleshooting
> >> and
> >> >> want
> >> >> >> to
> >> >> >> >> >> >> disable
> >> >> >> >> >> >> >> the
> >> >> >> >> >> >> >> second level page cache.
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> Is there any way to do this?
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> Thanks,
> >> >> >> >> >> >> >> Jamie
> >> >> >> >> >> >> >> --
> >> >> >> >> >> >> >> View this message in context:
> >> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >>
> >> >> >>
> >> >>
> >> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12563895
> >> >> >> >> >> >> >> Sent from the Wicket - User mailing list archive at
> >> >> >> Nabble.com
> >> >> >> .
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >> >> >> >> To unsubscribe, e-mail:
> >> >> users-unsubscribe@wicket.apache.org
> >> >> >> >> >> >> >> For additional commands, e-mail:
> >> >> users-help@wicket.apache.org
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >
> >> >> >> >> >> >> >
> >> >> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >> >> >> > To unsubscribe, e-mail:
> >> users-unsubscribe@wicket.apache.org
> >> >> >> >> >> >> > For additional commands, e-mail:
> >> >> users-help@wicket.apache.org
> >> >> >> >> >> >> >
> >> >> >> >> >> >> >
> >> >> >> >> >> >> >
> >> >> >> >> >> >>
> >> >> >> >> >> >> --
> >> >> >> >> >> >> View this message in context:
> >> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >>
> >> >> >>
> >> >>
> >> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12588790
> >> >> >> >> >> >> Sent from the Wicket - User mailing list archive at
> >> >> Nabble.com.
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> >> >> >> >> To unsubscribe, e-mail:
> >> users-unsubscribe@wicket.apache.org
> >> >> >> >> >> >> For additional commands, e-mail:
> >> users-help@wicket.apache.org
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >> >>
> >> >> >> >> >> --
> >> >> >> >> >> View this message in context:
> >> >> >> >> >>
> >> >> >> >>
> >> >> >>
> >> >>
> >> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589190
> >> >> >> >> >> Sent from the Wicket - User mailing list archive at
> >> Nabble.com
> >> .
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >> --
> >> >> >> >> View this message in context:
> >> >> >> >>
> >> >> >>
> >> >>
> >> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589567
> >> >> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >> > --
> >> >> >> > Buy Wicket in Action: http://manning.com/dashorst
> >> >> >> > Apache Wicket 1.3.0-beta3 is released
> >> >> >> > Get it now:
> >> http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
> >> >> >> >
> >> >> >> >
> >> >> ---------------------------------------------------------------------
> >> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >> --
> >> >> >> View this message in context:
> >> >> >>
> >> >>
> >> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12590414
> >> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >> >> >>
> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> View this message in context:
> >> >>
> >> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12590627
> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12591276
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12592522
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>


-- 
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0-beta3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Disable the SecondLevelPageCache?

Posted by Alex Objelean <al...@isdc.ro>.

:) Unfortunately it's not a joke, but I'm glad you're having fun :D.
Actually, this is result of worst case scenario simulation (I told you that
there are heavy objects in the model). After making transient some of the
fields, the size of the page dropped dramatically.

Alex.


Johan Compagner wrote:
> 
> you got to be kidding me...32MB????
> really? Or is this a nice joke so in the middle of the day :)
> 
> johan
> 
> 
> 
> On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>>
>>
>> It is about 32MB. Kind a big page :)
>>
>>
>> Matej Knopp-2 wrote:
>> >
>> > Turn on SecondLevelCacheSessionStore, and use FilePageStore as
>> > IPageStore (specified in session store constructor). Then go to your
>> > tmp dir and you should be able to find the serialized pages there.
>> >
>> > -Matej
>> >
>> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>> >>
>> >> How can I figure it out?
>> >>
>> >>
>> >>
>> >>
>> >> Johan Compagner wrote:
>> >> >
>> >> > if you save the page to disk how big is it?
>> >> >
>> >> > johan
>> >> >
>> >> >
>> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>> >> >>
>> >> >>
>> >> >> Indeed, it is a very big component hierarchy (It contains at least
>> 3
>> >> >> levels
>> >> >> of nested AjaxTabbedPanel components).
>> >> >> The application is, in fact, a single page and it uses a lot of
>> ajax
>> >> to
>> >> >> perform the updates. The model reflect the component hierarchy
>> >> >> (Appliction
>> >> >> has a single modelObject which nests another objects corresponding
>> to
>> >> >> each
>> >> >> component). I do not have a lot of detaching logic, because it is
>> >> >> important
>> >> >> to have all the data in the model (caching), also because the
>> services
>> >> >> are
>> >> >> very costly operations.
>> >> >>
>> >> >> If this description is not enough for replication, I will be glad
>> to
>> >> help
>> >> >> by
>> >> >> giving you another details.
>> >> >>
>> >> >> Alex.
>> >> >>
>> >> >>
>> >> >> Martijn Dashorst wrote:
>> >> >> >
>> >> >> > How big is the page? Sounds like a really, really big component
>> >> >> > hierarchy. Then it sounds reasonable that the httpsession store
>> is
>> >> >> > much faster: it keeps it in ram, and doesn't use serialization
>> until
>> >> >> > the session is serialized (server shutting down, deciding to put
>> >> >> > session to disk or replication of session across cluster) iirc.
>> >> >> >
>> >> >> > I think we would appreciate some way of replicating your results.
>> I
>> >> >> > assume you can't share the actual code, but could you share a
>> >> spin-off
>> >> >> > of the page's component structure and a Model that replicates the
>> >> data
>> >> >> > stuff's size (including the detach logic)?
>> >> >> >
>> >> >> > Martijn
>> >> >> >
>> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>> >> >> >>
>> >> >> >> If the pages wouldn't be serializable, it wouldn't work in
>> >> development
>> >> >> >> mode.
>> >> >> >> Is it right?
>> >> >> >>
>> >> >> >> I think that it is not necessarily about how large is
>> application,
>> >> in
>> >> >> my
>> >> >> >> case it is about how large is the model I'm working with for
>> that
>> >> >> >> specific
>> >> >> >> request (ajax request).
>> >> >> >>
>> >> >> >> My action was: fetch a subview of a very large table 300x300,
>> each
>> >> >> cell
>> >> >> >> has
>> >> >> >> a heavy model object.
>> >> >> >>
>> >> >> >> Alex.
>> >> >> >>
>> >> >> >>
>> >> >> >> Johan Compagner wrote:
>> >> >> >> >
>> >> >> >> > that looks very strange to me. We have also a very large app
>> here
>> >> >> and
>> >> >> >> we
>> >> >> >> > dont notice a difference
>> >> >> >> > So i am very curious what is happening at your place then. Are
>> >> you
>> >> >> sure
>> >> >> >> > for
>> >> >> >> > example that the pages
>> >> >> >> > are serializable ?  That we don't have constantly exceptions?
>> >> >> >> >
>> >> >> >> > johan
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> Maybe the profiling was not a perfect one. But still, I have
>> to
>> >> >> give
>> >> >> >> up
>> >> >> >> >> using
>> >> >> >> >> SecondSessionLevelStore just because the responsiveness of
>> the
>> >> >> >> >> application
>> >> >> >> >> is very slow.
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> Johan Compagner wrote:
>> >> >> >> >> >
>> >> >> >> >> > invocation count 1??
>> >> >> >> >> >
>> >> >> >> >> > So you only do 1 request and you profile that?
>> >> >> >> >> > thats not a good test. You have to do plenty and multiply
>> on
>> >> the
>> >> >> >> same
>> >> >> >> >> > time
>> >> >> >> >> > (10 for 100 request or something like that)
>> >> >> >> >> > to really see the difference. (and have a warm up phase)
>> >> >> >> >> >
>> >> >> >> >> > johan
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro>
>> wrote:
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >> Matej, I must disagree with you regarding performance
>> issues
>> >> of
>> >> >> the
>> >> >> >> >> >> SecondLevelSessionStore. I've reverted the
>> >> >> >> Application#newSessionStore
>> >> >> >> >> to
>> >> >> >> >> >> HttpSessionStore and this significantly improved the
>> >> application
>> >> >> >> >> overall
>> >> >> >> >> >> performance. Maybe this is not so obvious for small
>> >> >> applications,
>> >> >> >> but
>> >> >> >> >> >> when
>> >> >> >> >> >> it is about a large one - things changes.
>> >> >> >> >> >>
>> >> >> >> >> >> Below, you will find attached two images. The first one is
>> a
>> >> >> >> profiling
>> >> >> >> >> of
>> >> >> >> >> >> an
>> >> >> >> >> >> action when working with HttpSessionStore, the second one
>> is
>> >> a
>> >> >> >> >> profiling
>> >> >> >> >> >> for
>> >> >> >> >> >> the same action when using SecondSessionLevelStore. The
>> >> >> difference
>> >> >> >> is
>> >> >> >> >> >> huge:
>> >> >> >> >> >> 593ms vs 174420ms. I cannot explain what exactly is going
>> on,
>> >> >> but
>> >> >> >> I've
>> >> >> >> >> >> noticed that by switching from default
>> >> SecondLevelSessionStore
>> >> >> to
>> >> >> >> the
>> >> >> >> >> >> HttpSessionStore improved a lot the responsiveness of the
>> >> >> >> application.
>> >> >> >> >> >>
>> >> >> >> >> >> Alex.
>> >> >> >> >> >>
>> >> >> >> >> >> http://www.nabble.com/file/p12588790/HttpSessionStore.jpg
>> >> >> >> >> >>
>> >> http://www.nabble.com/file/p12588790/SecondSessionLevelStore.jpg
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >> Matej Knopp-2 wrote:
>> >> >> >> >> >> >
>> >> >> >> >> >> > You can revert to httpsessionstore by changing
>> >> >> >> >> >> > Application.newSessionStore method. But that's not
>> >> >> recommended.
>> >> >> >> What
>> >> >> >> >> >> > are your performance problems? I doubt it is caused by
>> the
>> >> >> >> session
>> >> >> >> >> >> > store.
>> >> >> >> >> >> >
>> >> >> >> >> >> > -Matej
>> >> >> >> >> >> >
>> >> >> >> >> >> > On 9/7/07, jamieballing <ja...@hotmail.com>
>> wrote:
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> We are trying to do some performance troubleshooting
>> and
>> >> want
>> >> >> to
>> >> >> >> >> >> disable
>> >> >> >> >> >> >> the
>> >> >> >> >> >> >> second level page cache.
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> Is there any way to do this?
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> Thanks,
>> >> >> >> >> >> >> Jamie
>> >> >> >> >> >> >> --
>> >> >> >> >> >> >> View this message in context:
>> >> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >>
>> >> >> >>
>> >> >>
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12563895
>> >> >> >> >> >> >> Sent from the Wicket - User mailing list archive at
>> >> >> Nabble.com
>> >> >> .
>> >> >> >> >> >> >>
>> >> >> >> >> >> >>
>> >> >> >> >> >> >>
>> >> >> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> >> >> >> To unsubscribe, e-mail:
>> >> users-unsubscribe@wicket.apache.org
>> >> >> >> >> >> >> For additional commands, e-mail:
>> >> users-help@wicket.apache.org
>> >> >> >> >> >> >>
>> >> >> >> >> >> >>
>> >> >> >> >> >> >
>> >> >> >> >> >> >
>> >> >> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> >> >> > To unsubscribe, e-mail:
>> users-unsubscribe@wicket.apache.org
>> >> >> >> >> >> > For additional commands, e-mail:
>> >> users-help@wicket.apache.org
>> >> >> >> >> >> >
>> >> >> >> >> >> >
>> >> >> >> >> >> >
>> >> >> >> >> >>
>> >> >> >> >> >> --
>> >> >> >> >> >> View this message in context:
>> >> >> >> >> >>
>> >> >> >> >>
>> >> >> >>
>> >> >>
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12588790
>> >> >> >> >> >> Sent from the Wicket - User mailing list archive at
>> >> Nabble.com.
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> >> >> To unsubscribe, e-mail:
>> users-unsubscribe@wicket.apache.org
>> >> >> >> >> >> For additional commands, e-mail:
>> users-help@wicket.apache.org
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >>
>> >> >> >> >> --
>> >> >> >> >> View this message in context:
>> >> >> >> >>
>> >> >> >>
>> >> >>
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589190
>> >> >> >> >> Sent from the Wicket - User mailing list archive at
>> Nabble.com
>> .
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >
>> >> >> >> >
>> >> >> >>
>> >> >> >> --
>> >> >> >> View this message in context:
>> >> >> >>
>> >> >>
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589567
>> >> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Buy Wicket in Action: http://manning.com/dashorst
>> >> >> > Apache Wicket 1.3.0-beta3 is released
>> >> >> > Get it now:
>> http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
>> >> >> >
>> >> >> >
>> >> ---------------------------------------------------------------------
>> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> --
>> >> >> View this message in context:
>> >> >>
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12590414
>> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >> >>
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12590627
>> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12591276
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
> 
> 

-- 
View this message in context: http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12592522
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Disable the SecondLevelPageCache?

Posted by Johan Compagner <jc...@gmail.com>.

you got to be kidding me...32MB????
really? Or is this a nice joke so in the middle of the day :)

johan



On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>
>
> It is about 32MB. Kind a big page :)
>
>
> Matej Knopp-2 wrote:
> >
> > Turn on SecondLevelCacheSessionStore, and use FilePageStore as
> > IPageStore (specified in session store constructor). Then go to your
> > tmp dir and you should be able to find the serialized pages there.
> >
> > -Matej
> >
> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
> >>
> >> How can I figure it out?
> >>
> >>
> >>
> >>
> >> Johan Compagner wrote:
> >> >
> >> > if you save the page to disk how big is it?
> >> >
> >> > johan
> >> >
> >> >
> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
> >> >>
> >> >>
> >> >> Indeed, it is a very big component hierarchy (It contains at least 3
> >> >> levels
> >> >> of nested AjaxTabbedPanel components).
> >> >> The application is, in fact, a single page and it uses a lot of ajax
> >> to
> >> >> perform the updates. The model reflect the component hierarchy
> >> >> (Appliction
> >> >> has a single modelObject which nests another objects corresponding
> to
> >> >> each
> >> >> component). I do not have a lot of detaching logic, because it is
> >> >> important
> >> >> to have all the data in the model (caching), also because the
> services
> >> >> are
> >> >> very costly operations.
> >> >>
> >> >> If this description is not enough for replication, I will be glad to
> >> help
> >> >> by
> >> >> giving you another details.
> >> >>
> >> >> Alex.
> >> >>
> >> >>
> >> >> Martijn Dashorst wrote:
> >> >> >
> >> >> > How big is the page? Sounds like a really, really big component
> >> >> > hierarchy. Then it sounds reasonable that the httpsession store is
> >> >> > much faster: it keeps it in ram, and doesn't use serialization
> until
> >> >> > the session is serialized (server shutting down, deciding to put
> >> >> > session to disk or replication of session across cluster) iirc.
> >> >> >
> >> >> > I think we would appreciate some way of replicating your results.
> I
> >> >> > assume you can't share the actual code, but could you share a
> >> spin-off
> >> >> > of the page's component structure and a Model that replicates the
> >> data
> >> >> > stuff's size (including the detach logic)?
> >> >> >
> >> >> > Martijn
> >> >> >
> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
> >> >> >>
> >> >> >> If the pages wouldn't be serializable, it wouldn't work in
> >> development
> >> >> >> mode.
> >> >> >> Is it right?
> >> >> >>
> >> >> >> I think that it is not necessarily about how large is
> application,
> >> in
> >> >> my
> >> >> >> case it is about how large is the model I'm working with for that
> >> >> >> specific
> >> >> >> request (ajax request).
> >> >> >>
> >> >> >> My action was: fetch a subview of a very large table 300x300,
> each
> >> >> cell
> >> >> >> has
> >> >> >> a heavy model object.
> >> >> >>
> >> >> >> Alex.
> >> >> >>
> >> >> >>
> >> >> >> Johan Compagner wrote:
> >> >> >> >
> >> >> >> > that looks very strange to me. We have also a very large app
> here
> >> >> and
> >> >> >> we
> >> >> >> > dont notice a difference
> >> >> >> > So i am very curious what is happening at your place then. Are
> >> you
> >> >> sure
> >> >> >> > for
> >> >> >> > example that the pages
> >> >> >> > are serializable ?  That we don't have constantly exceptions?
> >> >> >> >
> >> >> >> > johan
> >> >> >> >
> >> >> >> >
> >> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> Maybe the profiling was not a perfect one. But still, I have
> to
> >> >> give
> >> >> >> up
> >> >> >> >> using
> >> >> >> >> SecondSessionLevelStore just because the responsiveness of the
> >> >> >> >> application
> >> >> >> >> is very slow.
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> Johan Compagner wrote:
> >> >> >> >> >
> >> >> >> >> > invocation count 1??
> >> >> >> >> >
> >> >> >> >> > So you only do 1 request and you profile that?
> >> >> >> >> > thats not a good test. You have to do plenty and multiply on
> >> the
> >> >> >> same
> >> >> >> >> > time
> >> >> >> >> > (10 for 100 request or something like that)
> >> >> >> >> > to really see the difference. (and have a warm up phase)
> >> >> >> >> >
> >> >> >> >> > johan
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro>
> wrote:
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >> Matej, I must disagree with you regarding performance
> issues
> >> of
> >> >> the
> >> >> >> >> >> SecondLevelSessionStore. I've reverted the
> >> >> >> Application#newSessionStore
> >> >> >> >> to
> >> >> >> >> >> HttpSessionStore and this significantly improved the
> >> application
> >> >> >> >> overall
> >> >> >> >> >> performance. Maybe this is not so obvious for small
> >> >> applications,
> >> >> >> but
> >> >> >> >> >> when
> >> >> >> >> >> it is about a large one - things changes.
> >> >> >> >> >>
> >> >> >> >> >> Below, you will find attached two images. The first one is
> a
> >> >> >> profiling
> >> >> >> >> of
> >> >> >> >> >> an
> >> >> >> >> >> action when working with HttpSessionStore, the second one
> is
> >> a
> >> >> >> >> profiling
> >> >> >> >> >> for
> >> >> >> >> >> the same action when using SecondSessionLevelStore. The
> >> >> difference
> >> >> >> is
> >> >> >> >> >> huge:
> >> >> >> >> >> 593ms vs 174420ms. I cannot explain what exactly is going
> on,
> >> >> but
> >> >> >> I've
> >> >> >> >> >> noticed that by switching from default
> >> SecondLevelSessionStore
> >> >> to
> >> >> >> the
> >> >> >> >> >> HttpSessionStore improved a lot the responsiveness of the
> >> >> >> application.
> >> >> >> >> >>
> >> >> >> >> >> Alex.
> >> >> >> >> >>
> >> >> >> >> >> http://www.nabble.com/file/p12588790/HttpSessionStore.jpg
> >> >> >> >> >>
> >> http://www.nabble.com/file/p12588790/SecondSessionLevelStore.jpg
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >> Matej Knopp-2 wrote:
> >> >> >> >> >> >
> >> >> >> >> >> > You can revert to httpsessionstore by changing
> >> >> >> >> >> > Application.newSessionStore method. But that's not
> >> >> recommended.
> >> >> >> What
> >> >> >> >> >> > are your performance problems? I doubt it is caused by
> the
> >> >> >> session
> >> >> >> >> >> > store.
> >> >> >> >> >> >
> >> >> >> >> >> > -Matej
> >> >> >> >> >> >
> >> >> >> >> >> > On 9/7/07, jamieballing <ja...@hotmail.com> wrote:
> >> >> >> >> >> >>
> >> >> >> >> >> >> We are trying to do some performance troubleshooting and
> >> want
> >> >> to
> >> >> >> >> >> disable
> >> >> >> >> >> >> the
> >> >> >> >> >> >> second level page cache.
> >> >> >> >> >> >>
> >> >> >> >> >> >> Is there any way to do this?
> >> >> >> >> >> >>
> >> >> >> >> >> >> Thanks,
> >> >> >> >> >> >> Jamie
> >> >> >> >> >> >> --
> >> >> >> >> >> >> View this message in context:
> >> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >>
> >> >> >>
> >> >>
> >>
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12563895
> >> >> >> >> >> >> Sent from the Wicket - User mailing list archive at
> >> >> Nabble.com
> >> >> .
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> >> >> >> >> To unsubscribe, e-mail:
> >> users-unsubscribe@wicket.apache.org
> >> >> >> >> >> >> For additional commands, e-mail:
> >> users-help@wicket.apache.org
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> >> >> >> > To unsubscribe, e-mail:
> users-unsubscribe@wicket.apache.org
> >> >> >> >> >> > For additional commands, e-mail:
> >> users-help@wicket.apache.org
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >> >>
> >> >> >> >> >> --
> >> >> >> >> >> View this message in context:
> >> >> >> >> >>
> >> >> >> >>
> >> >> >>
> >> >>
> >>
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12588790
> >> >> >> >> >> Sent from the Wicket - User mailing list archive at
> >> Nabble.com.
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> >> >> For additional commands, e-mail:
> users-help@wicket.apache.org
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >> --
> >> >> >> >> View this message in context:
> >> >> >> >>
> >> >> >>
> >> >>
> >>
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589190
> >> >> >> >> Sent from the Wicket - User mailing list archive at Nabble.com
> .
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >> --
> >> >> >> View this message in context:
> >> >> >>
> >> >>
> >>
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589567
> >> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >> >> >>
> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Buy Wicket in Action: http://manning.com/dashorst
> >> >> > Apache Wicket 1.3.0-beta3 is released
> >> >> > Get it now:
> http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
> >> >> >
> >> >> >
> >> ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> View this message in context:
> >> >>
> >>
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12590414
> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12590627
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12591276
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

Re: Disable the SecondLevelPageCache?

Posted by Alex Objelean <al...@isdc.ro>.

It is about 32MB. Kind a big page :) 


Matej Knopp-2 wrote:
> 
> Turn on SecondLevelCacheSessionStore, and use FilePageStore as
> IPageStore (specified in session store constructor). Then go to your
> tmp dir and you should be able to find the serialized pages there.
> 
> -Matej
> 
> On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>>
>> How can I figure it out?
>>
>>
>>
>>
>> Johan Compagner wrote:
>> >
>> > if you save the page to disk how big is it?
>> >
>> > johan
>> >
>> >
>> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>> >>
>> >>
>> >> Indeed, it is a very big component hierarchy (It contains at least 3
>> >> levels
>> >> of nested AjaxTabbedPanel components).
>> >> The application is, in fact, a single page and it uses a lot of ajax
>> to
>> >> perform the updates. The model reflect the component hierarchy
>> >> (Appliction
>> >> has a single modelObject which nests another objects corresponding to
>> >> each
>> >> component). I do not have a lot of detaching logic, because it is
>> >> important
>> >> to have all the data in the model (caching), also because the services
>> >> are
>> >> very costly operations.
>> >>
>> >> If this description is not enough for replication, I will be glad to
>> help
>> >> by
>> >> giving you another details.
>> >>
>> >> Alex.
>> >>
>> >>
>> >> Martijn Dashorst wrote:
>> >> >
>> >> > How big is the page? Sounds like a really, really big component
>> >> > hierarchy. Then it sounds reasonable that the httpsession store is
>> >> > much faster: it keeps it in ram, and doesn't use serialization until
>> >> > the session is serialized (server shutting down, deciding to put
>> >> > session to disk or replication of session across cluster) iirc.
>> >> >
>> >> > I think we would appreciate some way of replicating your results. I
>> >> > assume you can't share the actual code, but could you share a
>> spin-off
>> >> > of the page's component structure and a Model that replicates the
>> data
>> >> > stuff's size (including the detach logic)?
>> >> >
>> >> > Martijn
>> >> >
>> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>> >> >>
>> >> >> If the pages wouldn't be serializable, it wouldn't work in
>> development
>> >> >> mode.
>> >> >> Is it right?
>> >> >>
>> >> >> I think that it is not necessarily about how large is application,
>> in
>> >> my
>> >> >> case it is about how large is the model I'm working with for that
>> >> >> specific
>> >> >> request (ajax request).
>> >> >>
>> >> >> My action was: fetch a subview of a very large table 300x300, each
>> >> cell
>> >> >> has
>> >> >> a heavy model object.
>> >> >>
>> >> >> Alex.
>> >> >>
>> >> >>
>> >> >> Johan Compagner wrote:
>> >> >> >
>> >> >> > that looks very strange to me. We have also a very large app here
>> >> and
>> >> >> we
>> >> >> > dont notice a difference
>> >> >> > So i am very curious what is happening at your place then. Are
>> you
>> >> sure
>> >> >> > for
>> >> >> > example that the pages
>> >> >> > are serializable ?  That we don't have constantly exceptions?
>> >> >> >
>> >> >> > johan
>> >> >> >
>> >> >> >
>> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>> >> >> >>
>> >> >> >>
>> >> >> >> Maybe the profiling was not a perfect one. But still, I have to
>> >> give
>> >> >> up
>> >> >> >> using
>> >> >> >> SecondSessionLevelStore just because the responsiveness of the
>> >> >> >> application
>> >> >> >> is very slow.
>> >> >> >>
>> >> >> >>
>> >> >> >> Johan Compagner wrote:
>> >> >> >> >
>> >> >> >> > invocation count 1??
>> >> >> >> >
>> >> >> >> > So you only do 1 request and you profile that?
>> >> >> >> > thats not a good test. You have to do plenty and multiply on 
>> the
>> >> >> same
>> >> >> >> > time
>> >> >> >> > (10 for 100 request or something like that)
>> >> >> >> > to really see the difference. (and have a warm up phase)
>> >> >> >> >
>> >> >> >> > johan
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> Matej, I must disagree with you regarding performance issues
>> of
>> >> the
>> >> >> >> >> SecondLevelSessionStore. I've reverted the
>> >> >> Application#newSessionStore
>> >> >> >> to
>> >> >> >> >> HttpSessionStore and this significantly improved the
>> application
>> >> >> >> overall
>> >> >> >> >> performance. Maybe this is not so obvious for small
>> >> applications,
>> >> >> but
>> >> >> >> >> when
>> >> >> >> >> it is about a large one - things changes.
>> >> >> >> >>
>> >> >> >> >> Below, you will find attached two images. The first one is a
>> >> >> profiling
>> >> >> >> of
>> >> >> >> >> an
>> >> >> >> >> action when working with HttpSessionStore, the second one is
>> a
>> >> >> >> profiling
>> >> >> >> >> for
>> >> >> >> >> the same action when using SecondSessionLevelStore. The
>> >> difference
>> >> >> is
>> >> >> >> >> huge:
>> >> >> >> >> 593ms vs 174420ms. I cannot explain what exactly is going on,
>> >> but
>> >> >> I've
>> >> >> >> >> noticed that by switching from default
>> SecondLevelSessionStore
>> >> to
>> >> >> the
>> >> >> >> >> HttpSessionStore improved a lot the responsiveness of the
>> >> >> application.
>> >> >> >> >>
>> >> >> >> >> Alex.
>> >> >> >> >>
>> >> >> >> >> http://www.nabble.com/file/p12588790/HttpSessionStore.jpg
>> >> >> >> >>
>> http://www.nabble.com/file/p12588790/SecondSessionLevelStore.jpg
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> Matej Knopp-2 wrote:
>> >> >> >> >> >
>> >> >> >> >> > You can revert to httpsessionstore by changing
>> >> >> >> >> > Application.newSessionStore method. But that's not
>> >> recommended.
>> >> >> What
>> >> >> >> >> > are your performance problems? I doubt it is caused by the
>> >> >> session
>> >> >> >> >> > store.
>> >> >> >> >> >
>> >> >> >> >> > -Matej
>> >> >> >> >> >
>> >> >> >> >> > On 9/7/07, jamieballing <ja...@hotmail.com> wrote:
>> >> >> >> >> >>
>> >> >> >> >> >> We are trying to do some performance troubleshooting and
>> want
>> >> to
>> >> >> >> >> disable
>> >> >> >> >> >> the
>> >> >> >> >> >> second level page cache.
>> >> >> >> >> >>
>> >> >> >> >> >> Is there any way to do this?
>> >> >> >> >> >>
>> >> >> >> >> >> Thanks,
>> >> >> >> >> >> Jamie
>> >> >> >> >> >> --
>> >> >> >> >> >> View this message in context:
>> >> >> >> >> >>
>> >> >> >> >>
>> >> >> >>
>> >> >>
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12563895
>> >> >> >> >> >> Sent from the Wicket - User mailing list archive at
>> >> Nabble.com
>> >> .
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> >> >> To unsubscribe, e-mail:
>> users-unsubscribe@wicket.apache.org
>> >> >> >> >> >> For additional commands, e-mail:
>> users-help@wicket.apache.org
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >> >> > For additional commands, e-mail:
>> users-help@wicket.apache.org
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >>
>> >> >> >> >> --
>> >> >> >> >> View this message in context:
>> >> >> >> >>
>> >> >> >>
>> >> >>
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12588790
>> >> >> >> >> Sent from the Wicket - User mailing list archive at
>> Nabble.com.
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >
>> >> >> >> >
>> >> >> >>
>> >> >> >> --
>> >> >> >> View this message in context:
>> >> >> >>
>> >> >>
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589190
>> >> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> --
>> >> >> View this message in context:
>> >> >>
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589567
>> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >> >>
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > Buy Wicket in Action: http://manning.com/dashorst
>> >> > Apache Wicket 1.3.0-beta3 is released
>> >> > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
>> >> >
>> >> >
>> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12590414
>> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12590627
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12591276
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Disable the SecondLevelPageCache?

Posted by Matej Knopp <ma...@gmail.com>.

Turn on SecondLevelCacheSessionStore, and use FilePageStore as
IPageStore (specified in session store constructor). Then go to your
tmp dir and you should be able to find the serialized pages there.

-Matej

On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>
> How can I figure it out?
>
>
>
>
> Johan Compagner wrote:
> >
> > if you save the page to disk how big is it?
> >
> > johan
> >
> >
> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
> >>
> >>
> >> Indeed, it is a very big component hierarchy (It contains at least 3
> >> levels
> >> of nested AjaxTabbedPanel components).
> >> The application is, in fact, a single page and it uses a lot of ajax to
> >> perform the updates. The model reflect the component hierarchy
> >> (Appliction
> >> has a single modelObject which nests another objects corresponding to
> >> each
> >> component). I do not have a lot of detaching logic, because it is
> >> important
> >> to have all the data in the model (caching), also because the services
> >> are
> >> very costly operations.
> >>
> >> If this description is not enough for replication, I will be glad to help
> >> by
> >> giving you another details.
> >>
> >> Alex.
> >>
> >>
> >> Martijn Dashorst wrote:
> >> >
> >> > How big is the page? Sounds like a really, really big component
> >> > hierarchy. Then it sounds reasonable that the httpsession store is
> >> > much faster: it keeps it in ram, and doesn't use serialization until
> >> > the session is serialized (server shutting down, deciding to put
> >> > session to disk or replication of session across cluster) iirc.
> >> >
> >> > I think we would appreciate some way of replicating your results. I
> >> > assume you can't share the actual code, but could you share a spin-off
> >> > of the page's component structure and a Model that replicates the data
> >> > stuff's size (including the detach logic)?
> >> >
> >> > Martijn
> >> >
> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
> >> >>
> >> >> If the pages wouldn't be serializable, it wouldn't work in development
> >> >> mode.
> >> >> Is it right?
> >> >>
> >> >> I think that it is not necessarily about how large is application, in
> >> my
> >> >> case it is about how large is the model I'm working with for that
> >> >> specific
> >> >> request (ajax request).
> >> >>
> >> >> My action was: fetch a subview of a very large table 300x300, each
> >> cell
> >> >> has
> >> >> a heavy model object.
> >> >>
> >> >> Alex.
> >> >>
> >> >>
> >> >> Johan Compagner wrote:
> >> >> >
> >> >> > that looks very strange to me. We have also a very large app here
> >> and
> >> >> we
> >> >> > dont notice a difference
> >> >> > So i am very curious what is happening at your place then. Are you
> >> sure
> >> >> > for
> >> >> > example that the pages
> >> >> > are serializable ?  That we don't have constantly exceptions?
> >> >> >
> >> >> > johan
> >> >> >
> >> >> >
> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
> >> >> >>
> >> >> >>
> >> >> >> Maybe the profiling was not a perfect one. But still, I have to
> >> give
> >> >> up
> >> >> >> using
> >> >> >> SecondSessionLevelStore just because the responsiveness of the
> >> >> >> application
> >> >> >> is very slow.
> >> >> >>
> >> >> >>
> >> >> >> Johan Compagner wrote:
> >> >> >> >
> >> >> >> > invocation count 1??
> >> >> >> >
> >> >> >> > So you only do 1 request and you profile that?
> >> >> >> > thats not a good test. You have to do plenty and multiply on  the
> >> >> same
> >> >> >> > time
> >> >> >> > (10 for 100 request or something like that)
> >> >> >> > to really see the difference. (and have a warm up phase)
> >> >> >> >
> >> >> >> > johan
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> Matej, I must disagree with you regarding performance issues of
> >> the
> >> >> >> >> SecondLevelSessionStore. I've reverted the
> >> >> Application#newSessionStore
> >> >> >> to
> >> >> >> >> HttpSessionStore and this significantly improved the application
> >> >> >> overall
> >> >> >> >> performance. Maybe this is not so obvious for small
> >> applications,
> >> >> but
> >> >> >> >> when
> >> >> >> >> it is about a large one - things changes.
> >> >> >> >>
> >> >> >> >> Below, you will find attached two images. The first one is a
> >> >> profiling
> >> >> >> of
> >> >> >> >> an
> >> >> >> >> action when working with HttpSessionStore, the second one is a
> >> >> >> profiling
> >> >> >> >> for
> >> >> >> >> the same action when using SecondSessionLevelStore. The
> >> difference
> >> >> is
> >> >> >> >> huge:
> >> >> >> >> 593ms vs 174420ms. I cannot explain what exactly is going on,
> >> but
> >> >> I've
> >> >> >> >> noticed that by switching from default SecondLevelSessionStore
> >> to
> >> >> the
> >> >> >> >> HttpSessionStore improved a lot the responsiveness of the
> >> >> application.
> >> >> >> >>
> >> >> >> >> Alex.
> >> >> >> >>
> >> >> >> >> http://www.nabble.com/file/p12588790/HttpSessionStore.jpg
> >> >> >> >> http://www.nabble.com/file/p12588790/SecondSessionLevelStore.jpg
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> Matej Knopp-2 wrote:
> >> >> >> >> >
> >> >> >> >> > You can revert to httpsessionstore by changing
> >> >> >> >> > Application.newSessionStore method. But that's not
> >> recommended.
> >> >> What
> >> >> >> >> > are your performance problems? I doubt it is caused by the
> >> >> session
> >> >> >> >> > store.
> >> >> >> >> >
> >> >> >> >> > -Matej
> >> >> >> >> >
> >> >> >> >> > On 9/7/07, jamieballing <ja...@hotmail.com> wrote:
> >> >> >> >> >>
> >> >> >> >> >> We are trying to do some performance troubleshooting and want
> >> to
> >> >> >> >> disable
> >> >> >> >> >> the
> >> >> >> >> >> second level page cache.
> >> >> >> >> >>
> >> >> >> >> >> Is there any way to do this?
> >> >> >> >> >>
> >> >> >> >> >> Thanks,
> >> >> >> >> >> Jamie
> >> >> >> >> >> --
> >> >> >> >> >> View this message in context:
> >> >> >> >> >>
> >> >> >> >>
> >> >> >>
> >> >>
> >> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12563895
> >> >> >> >> >> Sent from the Wicket - User mailing list archive at
> >> Nabble.com
> >> .
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >
> >> >> >> >> >
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >> --
> >> >> >> >> View this message in context:
> >> >> >> >>
> >> >> >>
> >> >>
> >> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12588790
> >> >> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >> --
> >> >> >> View this message in context:
> >> >> >>
> >> >>
> >> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589190
> >> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >> >> >>
> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> View this message in context:
> >> >>
> >> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589567
> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > Buy Wicket in Action: http://manning.com/dashorst
> >> > Apache Wicket 1.3.0-beta3 is released
> >> > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12590414
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12590627
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Disable the SecondLevelPageCache?

Posted by Alex Objelean <al...@isdc.ro>.

How can I figure it out?




Johan Compagner wrote:
> 
> if you save the page to disk how big is it?
> 
> johan
> 
> 
> On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>>
>>
>> Indeed, it is a very big component hierarchy (It contains at least 3
>> levels
>> of nested AjaxTabbedPanel components).
>> The application is, in fact, a single page and it uses a lot of ajax to
>> perform the updates. The model reflect the component hierarchy
>> (Appliction
>> has a single modelObject which nests another objects corresponding to
>> each
>> component). I do not have a lot of detaching logic, because it is
>> important
>> to have all the data in the model (caching), also because the services
>> are
>> very costly operations.
>>
>> If this description is not enough for replication, I will be glad to help
>> by
>> giving you another details.
>>
>> Alex.
>>
>>
>> Martijn Dashorst wrote:
>> >
>> > How big is the page? Sounds like a really, really big component
>> > hierarchy. Then it sounds reasonable that the httpsession store is
>> > much faster: it keeps it in ram, and doesn't use serialization until
>> > the session is serialized (server shutting down, deciding to put
>> > session to disk or replication of session across cluster) iirc.
>> >
>> > I think we would appreciate some way of replicating your results. I
>> > assume you can't share the actual code, but could you share a spin-off
>> > of the page's component structure and a Model that replicates the data
>> > stuff's size (including the detach logic)?
>> >
>> > Martijn
>> >
>> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>> >>
>> >> If the pages wouldn't be serializable, it wouldn't work in development
>> >> mode.
>> >> Is it right?
>> >>
>> >> I think that it is not necessarily about how large is application, in
>> my
>> >> case it is about how large is the model I'm working with for that
>> >> specific
>> >> request (ajax request).
>> >>
>> >> My action was: fetch a subview of a very large table 300x300, each
>> cell
>> >> has
>> >> a heavy model object.
>> >>
>> >> Alex.
>> >>
>> >>
>> >> Johan Compagner wrote:
>> >> >
>> >> > that looks very strange to me. We have also a very large app here
>> and
>> >> we
>> >> > dont notice a difference
>> >> > So i am very curious what is happening at your place then. Are you
>> sure
>> >> > for
>> >> > example that the pages
>> >> > are serializable ?  That we don't have constantly exceptions?
>> >> >
>> >> > johan
>> >> >
>> >> >
>> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>> >> >>
>> >> >>
>> >> >> Maybe the profiling was not a perfect one. But still, I have to
>> give
>> >> up
>> >> >> using
>> >> >> SecondSessionLevelStore just because the responsiveness of the
>> >> >> application
>> >> >> is very slow.
>> >> >>
>> >> >>
>> >> >> Johan Compagner wrote:
>> >> >> >
>> >> >> > invocation count 1??
>> >> >> >
>> >> >> > So you only do 1 request and you profile that?
>> >> >> > thats not a good test. You have to do plenty and multiply on  the
>> >> same
>> >> >> > time
>> >> >> > (10 for 100 request or something like that)
>> >> >> > to really see the difference. (and have a warm up phase)
>> >> >> >
>> >> >> > johan
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>> >> >> >>
>> >> >> >>
>> >> >> >> Matej, I must disagree with you regarding performance issues of
>> the
>> >> >> >> SecondLevelSessionStore. I've reverted the
>> >> Application#newSessionStore
>> >> >> to
>> >> >> >> HttpSessionStore and this significantly improved the application
>> >> >> overall
>> >> >> >> performance. Maybe this is not so obvious for small
>> applications,
>> >> but
>> >> >> >> when
>> >> >> >> it is about a large one - things changes.
>> >> >> >>
>> >> >> >> Below, you will find attached two images. The first one is a
>> >> profiling
>> >> >> of
>> >> >> >> an
>> >> >> >> action when working with HttpSessionStore, the second one is a
>> >> >> profiling
>> >> >> >> for
>> >> >> >> the same action when using SecondSessionLevelStore. The
>> difference
>> >> is
>> >> >> >> huge:
>> >> >> >> 593ms vs 174420ms. I cannot explain what exactly is going on,
>> but
>> >> I've
>> >> >> >> noticed that by switching from default SecondLevelSessionStore
>> to
>> >> the
>> >> >> >> HttpSessionStore improved a lot the responsiveness of the
>> >> application.
>> >> >> >>
>> >> >> >> Alex.
>> >> >> >>
>> >> >> >> http://www.nabble.com/file/p12588790/HttpSessionStore.jpg
>> >> >> >> http://www.nabble.com/file/p12588790/SecondSessionLevelStore.jpg
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> Matej Knopp-2 wrote:
>> >> >> >> >
>> >> >> >> > You can revert to httpsessionstore by changing
>> >> >> >> > Application.newSessionStore method. But that's not
>> recommended.
>> >> What
>> >> >> >> > are your performance problems? I doubt it is caused by the
>> >> session
>> >> >> >> > store.
>> >> >> >> >
>> >> >> >> > -Matej
>> >> >> >> >
>> >> >> >> > On 9/7/07, jamieballing <ja...@hotmail.com> wrote:
>> >> >> >> >>
>> >> >> >> >> We are trying to do some performance troubleshooting and want
>> to
>> >> >> >> disable
>> >> >> >> >> the
>> >> >> >> >> second level page cache.
>> >> >> >> >>
>> >> >> >> >> Is there any way to do this?
>> >> >> >> >>
>> >> >> >> >> Thanks,
>> >> >> >> >> Jamie
>> >> >> >> >> --
>> >> >> >> >> View this message in context:
>> >> >> >> >>
>> >> >> >>
>> >> >>
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12563895
>> >> >> >> >> Sent from the Wicket - User mailing list archive at
>> Nabble.com
>> .
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >
>> >> >> >> >
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >>
>> >> >> >> --
>> >> >> >> View this message in context:
>> >> >> >>
>> >> >>
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12588790
>> >> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> --
>> >> >> View this message in context:
>> >> >>
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589190
>> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >> >>
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589567
>> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > Buy Wicket in Action: http://manning.com/dashorst
>> > Apache Wicket 1.3.0-beta3 is released
>> > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12590414
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
> 
> 

-- 
View this message in context: http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12590627
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Disable the SecondLevelPageCache?

Posted by Johan Compagner <jc...@gmail.com>.

if you save the page to disk how big is it?

johan


On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>
>
> Indeed, it is a very big component hierarchy (It contains at least 3
> levels
> of nested AjaxTabbedPanel components).
> The application is, in fact, a single page and it uses a lot of ajax to
> perform the updates. The model reflect the component hierarchy (Appliction
> has a single modelObject which nests another objects corresponding to each
> component). I do not have a lot of detaching logic, because it is
> important
> to have all the data in the model (caching), also because the services are
> very costly operations.
>
> If this description is not enough for replication, I will be glad to help
> by
> giving you another details.
>
> Alex.
>
>
> Martijn Dashorst wrote:
> >
> > How big is the page? Sounds like a really, really big component
> > hierarchy. Then it sounds reasonable that the httpsession store is
> > much faster: it keeps it in ram, and doesn't use serialization until
> > the session is serialized (server shutting down, deciding to put
> > session to disk or replication of session across cluster) iirc.
> >
> > I think we would appreciate some way of replicating your results. I
> > assume you can't share the actual code, but could you share a spin-off
> > of the page's component structure and a Model that replicates the data
> > stuff's size (including the detach logic)?
> >
> > Martijn
> >
> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
> >>
> >> If the pages wouldn't be serializable, it wouldn't work in development
> >> mode.
> >> Is it right?
> >>
> >> I think that it is not necessarily about how large is application, in
> my
> >> case it is about how large is the model I'm working with for that
> >> specific
> >> request (ajax request).
> >>
> >> My action was: fetch a subview of a very large table 300x300, each cell
> >> has
> >> a heavy model object.
> >>
> >> Alex.
> >>
> >>
> >> Johan Compagner wrote:
> >> >
> >> > that looks very strange to me. We have also a very large app here and
> >> we
> >> > dont notice a difference
> >> > So i am very curious what is happening at your place then. Are you
> sure
> >> > for
> >> > example that the pages
> >> > are serializable ?  That we don't have constantly exceptions?
> >> >
> >> > johan
> >> >
> >> >
> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
> >> >>
> >> >>
> >> >> Maybe the profiling was not a perfect one. But still, I have to give
> >> up
> >> >> using
> >> >> SecondSessionLevelStore just because the responsiveness of the
> >> >> application
> >> >> is very slow.
> >> >>
> >> >>
> >> >> Johan Compagner wrote:
> >> >> >
> >> >> > invocation count 1??
> >> >> >
> >> >> > So you only do 1 request and you profile that?
> >> >> > thats not a good test. You have to do plenty and multiply on  the
> >> same
> >> >> > time
> >> >> > (10 for 100 request or something like that)
> >> >> > to really see the difference. (and have a warm up phase)
> >> >> >
> >> >> > johan
> >> >> >
> >> >> >
> >> >> >
> >> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
> >> >> >>
> >> >> >>
> >> >> >> Matej, I must disagree with you regarding performance issues of
> the
> >> >> >> SecondLevelSessionStore. I've reverted the
> >> Application#newSessionStore
> >> >> to
> >> >> >> HttpSessionStore and this significantly improved the application
> >> >> overall
> >> >> >> performance. Maybe this is not so obvious for small applications,
> >> but
> >> >> >> when
> >> >> >> it is about a large one - things changes.
> >> >> >>
> >> >> >> Below, you will find attached two images. The first one is a
> >> profiling
> >> >> of
> >> >> >> an
> >> >> >> action when working with HttpSessionStore, the second one is a
> >> >> profiling
> >> >> >> for
> >> >> >> the same action when using SecondSessionLevelStore. The
> difference
> >> is
> >> >> >> huge:
> >> >> >> 593ms vs 174420ms. I cannot explain what exactly is going on, but
> >> I've
> >> >> >> noticed that by switching from default SecondLevelSessionStore to
> >> the
> >> >> >> HttpSessionStore improved a lot the responsiveness of the
> >> application.
> >> >> >>
> >> >> >> Alex.
> >> >> >>
> >> >> >> http://www.nabble.com/file/p12588790/HttpSessionStore.jpg
> >> >> >> http://www.nabble.com/file/p12588790/SecondSessionLevelStore.jpg
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> Matej Knopp-2 wrote:
> >> >> >> >
> >> >> >> > You can revert to httpsessionstore by changing
> >> >> >> > Application.newSessionStore method. But that's not recommended.
> >> What
> >> >> >> > are your performance problems? I doubt it is caused by the
> >> session
> >> >> >> > store.
> >> >> >> >
> >> >> >> > -Matej
> >> >> >> >
> >> >> >> > On 9/7/07, jamieballing <ja...@hotmail.com> wrote:
> >> >> >> >>
> >> >> >> >> We are trying to do some performance troubleshooting and want
> to
> >> >> >> disable
> >> >> >> >> the
> >> >> >> >> second level page cache.
> >> >> >> >>
> >> >> >> >> Is there any way to do this?
> >> >> >> >>
> >> >> >> >> Thanks,
> >> >> >> >> Jamie
> >> >> >> >> --
> >> >> >> >> View this message in context:
> >> >> >> >>
> >> >> >>
> >> >>
> >>
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12563895
> >> >> >> >> Sent from the Wicket - User mailing list archive at Nabble.com
> .
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >>
> ---------------------------------------------------------------------
> >> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >> --
> >> >> >> View this message in context:
> >> >> >>
> >> >>
> >>
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12588790
> >> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >> >> >>
> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> View this message in context:
> >> >>
> >>
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589190
> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589567
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
> > --
> > Buy Wicket in Action: http://manning.com/dashorst
> > Apache Wicket 1.3.0-beta3 is released
> > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12590414
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

Re: Disable the SecondLevelPageCache?

Posted by Alex Objelean <al...@isdc.ro>.

Indeed, it is a very big component hierarchy (It contains at least 3 levels
of nested AjaxTabbedPanel components).
 The application is, in fact, a single page and it uses a lot of ajax to
perform the updates. The model reflect the component hierarchy (Appliction
has a single modelObject which nests another objects corresponding to each
component). I do not have a lot of detaching logic, because it is important
to have all the data in the model (caching), also because the services are
very costly operations. 

If this description is not enough for replication, I will be glad to help by
giving you another details.

Alex.


Martijn Dashorst wrote:
> 
> How big is the page? Sounds like a really, really big component
> hierarchy. Then it sounds reasonable that the httpsession store is
> much faster: it keeps it in ram, and doesn't use serialization until
> the session is serialized (server shutting down, deciding to put
> session to disk or replication of session across cluster) iirc.
> 
> I think we would appreciate some way of replicating your results. I
> assume you can't share the actual code, but could you share a spin-off
> of the page's component structure and a Model that replicates the data
> stuff's size (including the detach logic)?
> 
> Martijn
> 
> On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>>
>> If the pages wouldn't be serializable, it wouldn't work in development
>> mode.
>> Is it right?
>>
>> I think that it is not necessarily about how large is application, in my
>> case it is about how large is the model I'm working with for that
>> specific
>> request (ajax request).
>>
>> My action was: fetch a subview of a very large table 300x300, each cell
>> has
>> a heavy model object.
>>
>> Alex.
>>
>>
>> Johan Compagner wrote:
>> >
>> > that looks very strange to me. We have also a very large app here and
>> we
>> > dont notice a difference
>> > So i am very curious what is happening at your place then. Are you sure
>> > for
>> > example that the pages
>> > are serializable ?  That we don't have constantly exceptions?
>> >
>> > johan
>> >
>> >
>> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>> >>
>> >>
>> >> Maybe the profiling was not a perfect one. But still, I have to give
>> up
>> >> using
>> >> SecondSessionLevelStore just because the responsiveness of the
>> >> application
>> >> is very slow.
>> >>
>> >>
>> >> Johan Compagner wrote:
>> >> >
>> >> > invocation count 1??
>> >> >
>> >> > So you only do 1 request and you profile that?
>> >> > thats not a good test. You have to do plenty and multiply on  the
>> same
>> >> > time
>> >> > (10 for 100 request or something like that)
>> >> > to really see the difference. (and have a warm up phase)
>> >> >
>> >> > johan
>> >> >
>> >> >
>> >> >
>> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>> >> >>
>> >> >>
>> >> >> Matej, I must disagree with you regarding performance issues of the
>> >> >> SecondLevelSessionStore. I've reverted the
>> Application#newSessionStore
>> >> to
>> >> >> HttpSessionStore and this significantly improved the application
>> >> overall
>> >> >> performance. Maybe this is not so obvious for small applications,
>> but
>> >> >> when
>> >> >> it is about a large one - things changes.
>> >> >>
>> >> >> Below, you will find attached two images. The first one is a
>> profiling
>> >> of
>> >> >> an
>> >> >> action when working with HttpSessionStore, the second one is a
>> >> profiling
>> >> >> for
>> >> >> the same action when using SecondSessionLevelStore. The difference
>> is
>> >> >> huge:
>> >> >> 593ms vs 174420ms. I cannot explain what exactly is going on, but
>> I've
>> >> >> noticed that by switching from default SecondLevelSessionStore to
>> the
>> >> >> HttpSessionStore improved a lot the responsiveness of the
>> application.
>> >> >>
>> >> >> Alex.
>> >> >>
>> >> >> http://www.nabble.com/file/p12588790/HttpSessionStore.jpg
>> >> >> http://www.nabble.com/file/p12588790/SecondSessionLevelStore.jpg
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> Matej Knopp-2 wrote:
>> >> >> >
>> >> >> > You can revert to httpsessionstore by changing
>> >> >> > Application.newSessionStore method. But that's not recommended.
>> What
>> >> >> > are your performance problems? I doubt it is caused by the
>> session
>> >> >> > store.
>> >> >> >
>> >> >> > -Matej
>> >> >> >
>> >> >> > On 9/7/07, jamieballing <ja...@hotmail.com> wrote:
>> >> >> >>
>> >> >> >> We are trying to do some performance troubleshooting and want to
>> >> >> disable
>> >> >> >> the
>> >> >> >> second level page cache.
>> >> >> >>
>> >> >> >> Is there any way to do this?
>> >> >> >>
>> >> >> >> Thanks,
>> >> >> >> Jamie
>> >> >> >> --
>> >> >> >> View this message in context:
>> >> >> >>
>> >> >>
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12563895
>> >> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> ---------------------------------------------------------------------
>> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> --
>> >> >> View this message in context:
>> >> >>
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12588790
>> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >> >>
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589190
>> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589567
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
> 
> 
> -- 
> Buy Wicket in Action: http://manning.com/dashorst
> Apache Wicket 1.3.0-beta3 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12590414
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Disable the SecondLevelPageCache?

Posted by Martijn Dashorst <ma...@gmail.com>.

How big is the page? Sounds like a really, really big component
hierarchy. Then it sounds reasonable that the httpsession store is
much faster: it keeps it in ram, and doesn't use serialization until
the session is serialized (server shutting down, deciding to put
session to disk or replication of session across cluster) iirc.

I think we would appreciate some way of replicating your results. I
assume you can't share the actual code, but could you share a spin-off
of the page's component structure and a Model that replicates the data
stuff's size (including the detach logic)?

Martijn

On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>
> If the pages wouldn't be serializable, it wouldn't work in development mode.
> Is it right?
>
> I think that it is not necessarily about how large is application, in my
> case it is about how large is the model I'm working with for that specific
> request (ajax request).
>
> My action was: fetch a subview of a very large table 300x300, each cell has
> a heavy model object.
>
> Alex.
>
>
> Johan Compagner wrote:
> >
> > that looks very strange to me. We have also a very large app here and we
> > dont notice a difference
> > So i am very curious what is happening at your place then. Are you sure
> > for
> > example that the pages
> > are serializable ?  That we don't have constantly exceptions?
> >
> > johan
> >
> >
> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
> >>
> >>
> >> Maybe the profiling was not a perfect one. But still, I have to give up
> >> using
> >> SecondSessionLevelStore just because the responsiveness of the
> >> application
> >> is very slow.
> >>
> >>
> >> Johan Compagner wrote:
> >> >
> >> > invocation count 1??
> >> >
> >> > So you only do 1 request and you profile that?
> >> > thats not a good test. You have to do plenty and multiply on  the same
> >> > time
> >> > (10 for 100 request or something like that)
> >> > to really see the difference. (and have a warm up phase)
> >> >
> >> > johan
> >> >
> >> >
> >> >
> >> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
> >> >>
> >> >>
> >> >> Matej, I must disagree with you regarding performance issues of the
> >> >> SecondLevelSessionStore. I've reverted the Application#newSessionStore
> >> to
> >> >> HttpSessionStore and this significantly improved the application
> >> overall
> >> >> performance. Maybe this is not so obvious for small applications, but
> >> >> when
> >> >> it is about a large one - things changes.
> >> >>
> >> >> Below, you will find attached two images. The first one is a profiling
> >> of
> >> >> an
> >> >> action when working with HttpSessionStore, the second one is a
> >> profiling
> >> >> for
> >> >> the same action when using SecondSessionLevelStore. The difference is
> >> >> huge:
> >> >> 593ms vs 174420ms. I cannot explain what exactly is going on, but I've
> >> >> noticed that by switching from default SecondLevelSessionStore to the
> >> >> HttpSessionStore improved a lot the responsiveness of the application.
> >> >>
> >> >> Alex.
> >> >>
> >> >> http://www.nabble.com/file/p12588790/HttpSessionStore.jpg
> >> >> http://www.nabble.com/file/p12588790/SecondSessionLevelStore.jpg
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> Matej Knopp-2 wrote:
> >> >> >
> >> >> > You can revert to httpsessionstore by changing
> >> >> > Application.newSessionStore method. But that's not recommended. What
> >> >> > are your performance problems? I doubt it is caused by the session
> >> >> > store.
> >> >> >
> >> >> > -Matej
> >> >> >
> >> >> > On 9/7/07, jamieballing <ja...@hotmail.com> wrote:
> >> >> >>
> >> >> >> We are trying to do some performance troubleshooting and want to
> >> >> disable
> >> >> >> the
> >> >> >> second level page cache.
> >> >> >>
> >> >> >> Is there any way to do this?
> >> >> >>
> >> >> >> Thanks,
> >> >> >> Jamie
> >> >> >> --
> >> >> >> View this message in context:
> >> >> >>
> >> >>
> >> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12563895
> >> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >> >> >>
> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> View this message in context:
> >> >>
> >> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12588790
> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589190
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589567
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>


-- 
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0-beta3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Disable the SecondLevelPageCache?

Posted by Alex Objelean <al...@isdc.ro>.

If the pages wouldn't be serializable, it wouldn't work in development mode.
Is it right?

I think that it is not necessarily about how large is application, in my
case it is about how large is the model I'm working with for that specific
request (ajax request). 

My action was: fetch a subview of a very large table 300x300, each cell has
a heavy model object.

Alex. 


Johan Compagner wrote:
> 
> that looks very strange to me. We have also a very large app here and we
> dont notice a difference
> So i am very curious what is happening at your place then. Are you sure
> for
> example that the pages
> are serializable ?  That we don't have constantly exceptions?
> 
> johan
> 
> 
> On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>>
>>
>> Maybe the profiling was not a perfect one. But still, I have to give up
>> using
>> SecondSessionLevelStore just because the responsiveness of the
>> application
>> is very slow.
>>
>>
>> Johan Compagner wrote:
>> >
>> > invocation count 1??
>> >
>> > So you only do 1 request and you profile that?
>> > thats not a good test. You have to do plenty and multiply on  the same
>> > time
>> > (10 for 100 request or something like that)
>> > to really see the difference. (and have a warm up phase)
>> >
>> > johan
>> >
>> >
>> >
>> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>> >>
>> >>
>> >> Matej, I must disagree with you regarding performance issues of the
>> >> SecondLevelSessionStore. I've reverted the Application#newSessionStore
>> to
>> >> HttpSessionStore and this significantly improved the application
>> overall
>> >> performance. Maybe this is not so obvious for small applications, but
>> >> when
>> >> it is about a large one - things changes.
>> >>
>> >> Below, you will find attached two images. The first one is a profiling
>> of
>> >> an
>> >> action when working with HttpSessionStore, the second one is a
>> profiling
>> >> for
>> >> the same action when using SecondSessionLevelStore. The difference is
>> >> huge:
>> >> 593ms vs 174420ms. I cannot explain what exactly is going on, but I've
>> >> noticed that by switching from default SecondLevelSessionStore to the
>> >> HttpSessionStore improved a lot the responsiveness of the application.
>> >>
>> >> Alex.
>> >>
>> >> http://www.nabble.com/file/p12588790/HttpSessionStore.jpg
>> >> http://www.nabble.com/file/p12588790/SecondSessionLevelStore.jpg
>> >>
>> >>
>> >>
>> >>
>> >> Matej Knopp-2 wrote:
>> >> >
>> >> > You can revert to httpsessionstore by changing
>> >> > Application.newSessionStore method. But that's not recommended. What
>> >> > are your performance problems? I doubt it is caused by the session
>> >> > store.
>> >> >
>> >> > -Matej
>> >> >
>> >> > On 9/7/07, jamieballing <ja...@hotmail.com> wrote:
>> >> >>
>> >> >> We are trying to do some performance troubleshooting and want to
>> >> disable
>> >> >> the
>> >> >> second level page cache.
>> >> >>
>> >> >> Is there any way to do this?
>> >> >>
>> >> >> Thanks,
>> >> >> Jamie
>> >> >> --
>> >> >> View this message in context:
>> >> >>
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12563895
>> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >> >>
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12588790
>> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589190
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
> 
> 

-- 
View this message in context: http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589567
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Disable the SecondLevelPageCache?

Posted by Johan Compagner <jc...@gmail.com>.

that looks very strange to me. We have also a very large app here and we
dont notice a difference
So i am very curious what is happening at your place then. Are you sure for
example that the pages
are serializable ?  That we don't have constantly exceptions?

johan


On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>
>
> Maybe the profiling was not a perfect one. But still, I have to give up
> using
> SecondSessionLevelStore just because the responsiveness of the application
> is very slow.
>
>
> Johan Compagner wrote:
> >
> > invocation count 1??
> >
> > So you only do 1 request and you profile that?
> > thats not a good test. You have to do plenty and multiply on  the same
> > time
> > (10 for 100 request or something like that)
> > to really see the difference. (and have a warm up phase)
> >
> > johan
> >
> >
> >
> > On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
> >>
> >>
> >> Matej, I must disagree with you regarding performance issues of the
> >> SecondLevelSessionStore. I've reverted the Application#newSessionStore
> to
> >> HttpSessionStore and this significantly improved the application
> overall
> >> performance. Maybe this is not so obvious for small applications, but
> >> when
> >> it is about a large one - things changes.
> >>
> >> Below, you will find attached two images. The first one is a profiling
> of
> >> an
> >> action when working with HttpSessionStore, the second one is a
> profiling
> >> for
> >> the same action when using SecondSessionLevelStore. The difference is
> >> huge:
> >> 593ms vs 174420ms. I cannot explain what exactly is going on, but I've
> >> noticed that by switching from default SecondLevelSessionStore to the
> >> HttpSessionStore improved a lot the responsiveness of the application.
> >>
> >> Alex.
> >>
> >> http://www.nabble.com/file/p12588790/HttpSessionStore.jpg
> >> http://www.nabble.com/file/p12588790/SecondSessionLevelStore.jpg
> >>
> >>
> >>
> >>
> >> Matej Knopp-2 wrote:
> >> >
> >> > You can revert to httpsessionstore by changing
> >> > Application.newSessionStore method. But that's not recommended. What
> >> > are your performance problems? I doubt it is caused by the session
> >> > store.
> >> >
> >> > -Matej
> >> >
> >> > On 9/7/07, jamieballing <ja...@hotmail.com> wrote:
> >> >>
> >> >> We are trying to do some performance troubleshooting and want to
> >> disable
> >> >> the
> >> >> second level page cache.
> >> >>
> >> >> Is there any way to do this?
> >> >>
> >> >> Thanks,
> >> >> Jamie
> >> >> --
> >> >> View this message in context:
> >> >>
> >>
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12563895
> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12588790
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589190
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

Re: Disable the SecondLevelPageCache?

Posted by Alex Objelean <al...@isdc.ro>.

Maybe the profiling was not a perfect one. But still, I have to give up using
SecondSessionLevelStore just because the responsiveness of the application
is very slow. 


Johan Compagner wrote:
> 
> invocation count 1??
> 
> So you only do 1 request and you profile that?
> thats not a good test. You have to do plenty and multiply on  the same
> time
> (10 for 100 request or something like that)
> to really see the difference. (and have a warm up phase)
> 
> johan
> 
> 
> 
> On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>>
>>
>> Matej, I must disagree with you regarding performance issues of the
>> SecondLevelSessionStore. I've reverted the Application#newSessionStore to
>> HttpSessionStore and this significantly improved the application overall
>> performance. Maybe this is not so obvious for small applications, but
>> when
>> it is about a large one - things changes.
>>
>> Below, you will find attached two images. The first one is a profiling of
>> an
>> action when working with HttpSessionStore, the second one is a profiling
>> for
>> the same action when using SecondSessionLevelStore. The difference is
>> huge:
>> 593ms vs 174420ms. I cannot explain what exactly is going on, but I've
>> noticed that by switching from default SecondLevelSessionStore to the
>> HttpSessionStore improved a lot the responsiveness of the application.
>>
>> Alex.
>>
>> http://www.nabble.com/file/p12588790/HttpSessionStore.jpg
>> http://www.nabble.com/file/p12588790/SecondSessionLevelStore.jpg
>>
>>
>>
>>
>> Matej Knopp-2 wrote:
>> >
>> > You can revert to httpsessionstore by changing
>> > Application.newSessionStore method. But that's not recommended. What
>> > are your performance problems? I doubt it is caused by the session
>> > store.
>> >
>> > -Matej
>> >
>> > On 9/7/07, jamieballing <ja...@hotmail.com> wrote:
>> >>
>> >> We are trying to do some performance troubleshooting and want to
>> disable
>> >> the
>> >> second level page cache.
>> >>
>> >> Is there any way to do this?
>> >>
>> >> Thanks,
>> >> Jamie
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12563895
>> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12588790
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
> 
> 

-- 
View this message in context: http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589190
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Disable the SecondLevelPageCache?

Posted by Johan Compagner <jc...@gmail.com>.

invocation count 1??

So you only do 1 request and you profile that?
thats not a good test. You have to do plenty and multiply on  the same time
(10 for 100 request or something like that)
to really see the difference. (and have a warm up phase)

johan



On 9/10/07, Alex Objelean <al...@isdc.ro> wrote:
>
>
> Matej, I must disagree with you regarding performance issues of the
> SecondLevelSessionStore. I've reverted the Application#newSessionStore to
> HttpSessionStore and this significantly improved the application overall
> performance. Maybe this is not so obvious for small applications, but when
> it is about a large one - things changes.
>
> Below, you will find attached two images. The first one is a profiling of
> an
> action when working with HttpSessionStore, the second one is a profiling
> for
> the same action when using SecondSessionLevelStore. The difference is
> huge:
> 593ms vs 174420ms. I cannot explain what exactly is going on, but I've
> noticed that by switching from default SecondLevelSessionStore to the
> HttpSessionStore improved a lot the responsiveness of the application.
>
> Alex.
>
> http://www.nabble.com/file/p12588790/HttpSessionStore.jpg
> http://www.nabble.com/file/p12588790/SecondSessionLevelStore.jpg
>
>
>
>
> Matej Knopp-2 wrote:
> >
> > You can revert to httpsessionstore by changing
> > Application.newSessionStore method. But that's not recommended. What
> > are your performance problems? I doubt it is caused by the session
> > store.
> >
> > -Matej
> >
> > On 9/7/07, jamieballing <ja...@hotmail.com> wrote:
> >>
> >> We are trying to do some performance troubleshooting and want to
> disable
> >> the
> >> second level page cache.
> >>
> >> Is there any way to do this?
> >>
> >> Thanks,
> >> Jamie
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12563895
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12588790
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

Re: Disable the SecondLevelPageCache?

Posted by Alex Objelean <al...@isdc.ro>.

Matej, I must disagree with you regarding performance issues of the
SecondLevelSessionStore. I've reverted the Application#newSessionStore to
HttpSessionStore and this significantly improved the application overall
performance. Maybe this is not so obvious for small applications, but when
it is about a large one - things changes. 

Below, you will find attached two images. The first one is a profiling of an
action when working with HttpSessionStore, the second one is a profiling for
the same action when using SecondSessionLevelStore. The difference is huge:
593ms vs 174420ms. I cannot explain what exactly is going on, but I've
noticed that by switching from default SecondLevelSessionStore to the
HttpSessionStore improved a lot the responsiveness of the application.

Alex.

http://www.nabble.com/file/p12588790/HttpSessionStore.jpg 
http://www.nabble.com/file/p12588790/SecondSessionLevelStore.jpg 

Matej Knopp-2 wrote:
> 
> You can revert to httpsessionstore by changing
> Application.newSessionStore method. But that's not recommended. What
> are your performance problems? I doubt it is caused by the session
> store.
> 
> -Matej
> 
> On 9/7/07, jamieballing <ja...@hotmail.com> wrote:
>>
>> We are trying to do some performance troubleshooting and want to disable
>> the
>> second level page cache.
>>
>> Is there any way to do this?
>>
>> Thanks,
>> Jamie
>> --
>> View this message in context:
>> http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12563895
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12588790
Sent from the Wicket - User mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Disable the SecondLevelPageCache?

Posted by Eelco Hillenius <ee...@gmail.com>.

On 9/7/07, Matej Knopp <ma...@gmail.com> wrote:
> You can revert to httpsessionstore by changing
> Application.newSessionStore method. But that's not recommended. What
> are your performance problems? I doubt it is caused by the session
> store.

And if you are interested in just profiling etc, you could just use
SLCSS and a dummy file page store. You're back button won't work in
that case, but for profiling that's probably not relevant.

But I agree with Matej, it is unlikely that SLCSS is a bottleneck,
even though intuition might point to that.

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Disable the SecondLevelPageCache?

Posted by Matej Knopp <ma...@gmail.com>.

You can revert to httpsessionstore by changing
Application.newSessionStore method. But that's not recommended. What
are your performance problems? I doubt it is caused by the session
store.

-Matej

On 9/7/07, jamieballing <ja...@hotmail.com> wrote:
>
> We are trying to do some performance troubleshooting and want to disable the
> second level page cache.
>
> Is there any way to do this?
>
> Thanks,
> Jamie
> --
> View this message in context: http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12563895
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org