hi
@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..