Apple

@Chuck Hill

> The snapshots are referenced counted.

> (...) There is no way to accelerate this and I doubt it would be overall beneficial to do so. That would just increase the database traffic to re-generate the snapshot.

The points which I see which could make it interesting for us are:

- for some entities, we create a new record at change. Each record has all the data. As such, if 10 changes happen, only the latest record is actually used. The others snapshots there consume heap space for nothing and for quite some time,

- we currently use a "one editing context per session strategy". Our users potentially remain connected and active for hours. Whereas the data they deal with can have a short lifespan (1 hour or so). So some of the data may remain in the editing context while not being used anymore

But it looks like we have others ways to look for right now. As far as I get it right now our best options to reduce RAM consumption looks like:

- reducing the editing context scope (so they retain less),

- switching to persistent sessions

Any other hint/option welcomed :)

@Musall Maik

> What would be the point of freeing some memory in WO only to allocate the same memory in another process?

you're right in case of memcached. For our current issue putting it to the file system or db would be better.

@Musall Maik

> 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?

Well, from my wicket experience and what was said here earlier, the cost of serialization is dramatically low. So adding 100 ms on each request and be sure to spare RAM would be ok for me.

Anyway, once the mechanism is up and running, it's a matter of optimization.

@Ramsey Gurley

Do you have some estimate of the average size of serialized down sessions ? Approximations are fine: do we speak of Kb, Mb, Gb ? I guess a few Mb but then..

BTW, how does it play ball with the editing context snapshot ? Every time no RR is running all snapshots are cleared, is it right ?

2013/4/30 Chuck Hill <email@hidden>

On 2013-04-29, at 2:11 AM, Musall Maik wrote:

>
> Am 26.04.2013 um 21:21 schrieb Chuck Hill <email@hidden>:
>
>>
>> On 2013-04-26, at 12:12 PM, Ramsey Gurley wrote:
>>> 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.
>>
>> memcached, or something like that, might be an interesting alternative.
>
> What would be the point of freeing some memory in WO only to allocate the same memory in another process?

I was considering how to make persistent sessions faster, not save memory.

--
Chuck Hill
Executive Managing Partner, VP Development and Technical Services

Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.
http://www.global-village.net/gvc/practical_webobjects

Global Village Consulting ranks 13th in 2012 in BIV's Top 100 Fastest Growing Companies in B.C!
Global Village Consulting ranks 76th in 24th annual PROFIT 200 ranking of Canada’s Fastest-Growing Companies by PROFIT Magazine!

_______________________________________________
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