Re: EOF related objects present a lot in the heap
Re: EOF related objects present a lot in the heap
- Subject: Re: EOF related objects present a lot in the heap
- From: Ramsey Gurley <email@hidden>
- Date: Fri, 26 Apr 2013 12:12:45 -0700
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@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden