[Seaside] WeakArray (again)

[David Shaffer]

William Harford wrote:

> Just a note: Restarting the image a clearing the caches solves the 
> problem for a few hours so It could turn out the slow downs I am 
> experiencing are not totally related to WeakArray.
>
> From the beginning I have experienced slow down issues on Squeak/
> Seaside images running on Linux and while I have done a lot to reduce 
> the problem it has not gone away. I am almost ready to give up and 
> write some sort of load balancing script that expires/kills images 
> after a few hours and after they are done handling active session.
>
> It would be a terrible hack but I am getting far to many complaints 
> about seaside applications slowing down and me having to save and 
> restart the image.
>
> Has anyone else experienced these issues and discovered a solution/
> work around.
>
> Thanks
> Will


I wish there was a simple answer (well, there is a simple answer "fix
weak array finalization", but it doesn't seem likely to happen soon). 
Here are some things I've done to avoid slowdown nightmares...they are
not all appropriate for all scenarios:

1) as you mentioned, remove the use of WeakIdentityKeyDictionary in
WAStateRegistry...this will mean you're sessions grow continually but is
OK for relatively short-lived sessions.
2) force session reclaimation on a periodic basis rather than checking
every ~10 requests (set up a service to call
WARegistry>>unregisterExpiredHandlers periodically and perform a
fullGC).  Unregistering sessions can be expensive and it happens on
average every time 10 new sessions are created.  This means that expired
sessions will hang around during periods of inactivity which are usually
the best times to reclaim them and GC.  I've found that simply checking
every few minutes improves the first page responsiveness of my largest
app.  I use a "Service" to do this (attached).
3) "register" a minimal amount of state...still each component uses a
"state holder" for each decoration (including the component itself).

Anyway...no rocket science here but I have a collection of applications
which sustain a fairly reasonable hit rate and I have not heard of (or
experienced myself) the "weak reclaimation freeze" since I took these
measures.  My users' sessions are relatively short so 1 and 2 have a big
impact.

David



-------------- next part --------------
'From Squeak3.7 of ''4 September 2004'' [latest update: #5989] on 9 April 2005 at 4:04:12 pm'!
ApplicationService subclass: #SessionExpirationService
	instanceVariableNames: ''
	classVariableNames: ''
	poolDictionaries: ''
	category: 'SC-SeasideHacks'!

!SessionExpirationService methodsFor: 'private' stamp: 'cds 4/9/2005 16:04'!
informApplications
	WADispatcher default entryPoints do: [:app |
		app unregisterExpiredHandlers]! !


!SessionExpirationService methodsFor: 'running' stamp: 'cds 3/13/2005 19:04'!
runWhile: aBlock
	[aBlock value] 
		whileTrue: [self informApplications.
			    Smalltalk garbageCollect.
			    self sleepFor: 30000]
! !