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
Sent from the Users forum mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to