How are you storing/retrieving your photos? I recently did some session size testing and I found the sessions were surprisingly small. Once I removed the detachable model wrapped around an object holding a photo (byte array) retrieved from the database my session size shot up considerably.
From: Per <[email protected]> To: [email protected] Date: 02/16/2011 06:41 AM Subject: Re: Just 100K per session? That would be my dream come true! (Anyone here who has tuned session size before?) Hi Johan and Igor, well, on one hand I am using App Engine, and puts are limited to 1MB. Even with pagination and limitation of each page to 50 users (totalling 200Kb in memory for the whole page), I had to limit the pagemap size severely to ensure I am always below 1M. In Wicket 1.5 it's a lot easier to write an adaptive EvictionStrategy to control memory usage, so I can be more flexible and evict large pages more aggressively than smaller ones. Still, displaying say 500 users at once will still not be possible if each user-row can take as much as 5K. But I am not complaining. I knew that App Engine has this limitation, and I make my own product specifications, so I can live with it. On the plus side, App Engine (due to its restrictions) scales really well, and I am not worried if some day thousands of users will use my app concurrently. But although a typical server may have many Gigs these days, you'd still be in trouble if thousands of users came slurping 40M each, that's why I do think that session size remains an important consideration. I would strongly recommend anyone not to leave optimisation till the very last, but plan ahead and spike some of the most complex screens first, since Wicket *is* different in that respect. Sorry to hear I can't optimise easily, but thanks for the quick responses Johan and Igor! Your support on this forum is truly legendary! Will try to figure out the autoAdd() soon :-) Per > but if you have it down to 200K then 50 users it is nothing... thats > 10MB on memory.... > If if both where 2X so 400K and 100 users thats still only 40MB in > memory.... Thats for a server nothing.. > > > > On Wed, Feb 16, 2011 at 02:10, Per <[hidden email] > </user/SendEmail.jtp?type=node&node=3308586&i=0>> wrote: > > > > > > > So I still haven't solved my memory issues, despite weeks of > research and > > profiling. Reading in the other thread that a session size of 100K > or less > > is achievable, I'll admit defeat now: I have not been able to shrink > some of > > my pages(!) to less than 200K, not to mention the sessions. Despite > LDMs, > > CompoundPropertyModels, and no, there are no domain objects in > there, and no > > finals. > > > > What on earth am I doing wrong? > > > > My goal is to display a long list of, say, users. Each users should > list a > > few labels (name, position, location, etc) and images to show who's an > > admin/poweruser. Each user has a profile picture. Each user who is > also a > > manager should have image icons of their subordinates' profile pictures > > (e.g. a nested ListView) And I want 5 or 6 AJAX labels so I can quickly > > lock/unlock users, delete them, give and revoke certain rights. > > > > Despite lots of profiling each row is still 4K to 6K. This adds up > for even > > just 50 users. Can this be reduced, at all? I mean, it seems that 56 > Bytes > > is the minimum for a Label, 32 for a PropertyModel, 80 for a > ListItem, and > > some 200 for an AjaxLink. 400 for an Image (or alternatively 272 for > a label > > with 2 AttributeAppenders to also render an image), and unless the > whole > > list disappears from the page's object graph, all those small > numbers DO add > > up. > > > > My final hope was the RefreshingList, but no, it also keeps the list > items > > stored in the page. What I really would like is a list that does not > > maintain all its items, but throws them away, just like a LDM throws > away > > the domain object, and just reloads when needed. Okay, that would > not work > > because I want some state in there, but you get my point. > > > > I really hope it's something totally obvious I missed. > > > > Cheers, > > Per > > -- > > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3308014.html > < http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3308014.html?by-user=t > > > Sent from the Users forum mailing list archive at Nabble.com. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [hidden email] > </user/SendEmail.jtp?type=node&node=3308586&i=1> > > For additional commands, e-mail: [hidden email] > </user/SendEmail.jtp?type=node&node=3308586&i=2> > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > </user/SendEmail.jtp?type=node&node=3308586&i=3> > For additional commands, e-mail: [hidden email] > </user/SendEmail.jtp?type=node&node=3308586&i=4> > > > > ------------------------------------------------------------------------ > If you reply to this email, your message will be added to the > discussion below: > http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3308586.html > > To unsubscribe from Just 100K per session? That would be my dream come > true! (Anyone here who has tuned session size before?), click here > < http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=3308014&code=cGVyQGhhbWJ1cmcuZGV8MzMwODAxNHwtMjI2MTAwMzE0 >. > -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Just-100K-per-session-That-would-be-my-dream-come-true-Anyone-here-who-has-tuned-session-size-before-tp3308014p3308621.html Sent from the Users forum mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] Notice: This communication, including any attachments, is intended solely for the use of the individual or entity to which it is addressed. This communication may contain information that is protected from disclosure under State and/or Federal law. Please notify the sender immediately if you have received this communication in error and delete this email from your system. If you are not the intended recipient, you are requested not to disclose, copy, distribute or take any action in reliance on the contents of this information.
