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: Mon, 29 Apr 2013 08:49:23 -0700
On Apr 29, 2013, at 2:13 AM, Musall Maik wrote:
> re-post as I forgot to post to the list
>
> Am 26.04.2013 um 21:12 schrieb Ramsey Gurley <email@hidden>:
>
>> 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.
>
> Do you think it would be possible to not serialize out the session on each RR loop, but instead having a short timeout delay (like 10 or 30 seconds), make the session persistent once the timeout is reached, and keeping the actively used sessions in memory?
>
> Could that be "best of both worlds"? :-) Of course you wouldn't spare the serialization debugging.
>
> Maik
If you retain sessions in memory, even for a little while, you lose the second advantage: session distribution. That is just as important to me as the memory savings because it allows for horizontal scaling across commodity machines. Applications under heavy load? Just add more instances.
You'll never hit the wall on the apps. Only on the database. Even with the database, I doubt it would be much of an issue for sessions. Just put the persistent session storage model into its own database all by itself. Before you ever hit the wall, you'll probably need to partition the table to make selects and updates faster. Once you do hit the wall, you just need to find a way to get each partition into its own 'master' database, giving you ~14K writes per partition. At that point, you could scale it horizontally just like the apps. I only pretend to be a DBA, so I'm a little fuzzy on how to accomplish this last bit, but it doesn't sound unreasonable.
I would think you would have a far greater challenge scaling the rest of your database this way. Sessions are easy, because there is a single table with no relationships to anything. Partition based on session id and you should get a fairly even distribution. I would imagine the real problem for "Large" apps is going to be the rest of that RDBMS. If your app is write heavy and your data structure is spread out in lots of little tables, then partitioning everything correctly sounds much more challenging.
Ramsey
_______________________________________________
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