I think you are simply finding that in memory sessions use up memory. Consider using persistent sessions. That moves them out of memory and into the datastore.
Advantages of memory sessions: * Easier * Faster Disadvantages of memory sessions: * Doesn't scale well. Sessions eat up all available memory. * Must have short session timeouts. * Sessions are tied to a specific instance Advantages of persistent sessions: * Frees memory at the end of the RR loop * Easier to manage deployments. Sessions are distributed across instances. * Sessions can last as long as you want. Disadvantages of persistent sessions: * Hard. Everything must be serializable on your session. Your EOs, your WOComponents, everything. Fixing serialization errors is no walk in the park. * Serialization adds a few milliseconds wait to the RR loop. * Database load. Every RR loop is two selects and an update on a session row. Even if you isolate the session in their own database, there's a wall there. Get large enough and you'll hit it. Postgres 9.2 can handle about 14,000 writes per second according to what I've read. And for the stateless RESTful crowd, Advantages of no session: * Saves memory * Easier to manage deployments * Fast Disadvantages of no session: * You lose component actions and D2W, which IMO, is one of the strongest reason to choose WO. * WO fights you. It's easy to accidentally create a session in WO. If you want to go session free, go ahead and throw a runtime exception in your session constructor. * You can only pass so much state through a URL. This leaves you to implement state on the client side. If you're in a browser, that means JavaScript :-P If you're planning a native app, then this is probably the route you want to go anyway. In terms of hard limits on user base, I see these options as Small, Medium, and Large in that order. Ramsey On Apr 26, 2013, at 4:55 AM, Joseph Pachod wrote: > Hi > > When looking at some memory dumps, I see huge numbers of EOF related > instances, such as, by decreasing order and with % of instance nb and % of > heap size : > - _EOHandlerWeakRef 5,8% - 5,1%, > - EOAccessArrayFaultHandler 5,7% - 6,6% > - _EOCheapCopyMutableArray 2,9% - 1% > - _EOMutableKnownKeyDictionnary 2,1% - 3;3% > - _EOWeakReference 1,2% - 1% > > The overall JVM is about 360Mo. Each session of the application looks like > holding quite some of them (they're nicely garbage collected on session > termination). So they look like editing context related. > > I was wondering it there were some tricks to clean up these objects. > > For example can the WeakReference be clean up somehow ? Can the editing > context cache be cleaned up to retain only the dirty objects ? Or maybe to > remove some of the least used entities (or not used for quite some time) ? > > Any hint welcomed :) > > Thanks in advance > best > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/rgurley%40smarthealth.com > > This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
