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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: >> [EMAIL PROTECTED] >> >> >> >> >> >> For additional commands, e-mail: >> [EMAIL PROTECTED] >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> >> --------------------------------------------------------------------- >> >> >> >> >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> >> >> >> > For additional commands, e-mail: >> [EMAIL PROTECTED] >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> >> 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: [EMAIL PROTECTED] >> >> >> >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> > >> >> >> >> >> >> >> >> -- >> >> >> >> 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: [EMAIL PROTECTED] >> >> >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> >> >> >> >> >> >> > >> >> >> > >> >> >> >> >> >> -- >> >> >> 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: [EMAIL PROTECTED] >> >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> >> >> >> > >> >> > >> >> > -- >> >> > 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: [EMAIL PROTECTED] >> >> > For additional commands, e-mail: [EMAIL PROTECTED] >> >> > >> >> > >> >> > >> >> >> >> -- >> >> 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: [EMAIL PROTECTED] >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> > >> >> -- >> 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: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
