[Seaside] Confused about WASession cleanup

[Julian Fitzell]

Try using a number higher than 11. I'm pretty sure our default reaping
behaviour doesn't actually count 10 requests, but rather uses a random
probability of 1 in 10. You should find that under regular (i.e.
non-spikey) load your sessions should not hang around significantly
beyond their expiry.

Alternatively, try creating a new session every 10 seconds. Once you
hit your timeout (600 seconds) you should find the total (average)
session count stops growing at the same rate flattens out pretty
quickly from then on.

Julian

On Wed, Jun 9, 2010 at 10:33 PM, Sven Van Caekenberghe <sven at beta9.be> wrote:
> Lukas,
>
> I am sure there is some explanation here, but really, the following fails in my image, while from my understanding of what you said, it should work, no ? Tomorrow, I will test this on a virgin Seaside one-click image (the test takes 11 minutes ;-)
>
> 'From Pharo-1.0 of 19 October 2009 [Latest update: #10517] on 9 June 2010 at 11:28:15 pm'!
> TestCase subclass: #SessionCleanupTest
>        instanceVariableNames: ''
>        classVariableNames: ''
>        poolDictionaries: ''
>        category: 'ADayAtTheBeach'!
>
> !SessionCleanupTest methodsFor: 'testing' stamp: 'svc 6/9/2010 23:05'!
> testSessionCleanup
>        | startCount highCount |
>        startCount := self numberOfSessions.
>        100 timesRepeat: [ self hitCounterWebApp ].
>        self assert: (self numberOfSessions > startCount).
>        highCount := self numberOfSessions.
>        (Delay forDuration: 11 minutes) wait.
>        11 timesRepeat: [ self hitCounterWebApp ].
>        3 timesRepeat: [ Smalltalk garbageCollect ].
>        self assert: (self numberOfSessions < highCount)! !
>
>
> !SessionCleanupTest methodsFor: 'private' stamp: 'svc 6/9/2010 22:52'!
> hitCounterWebApp
>        ^ HTTPClient httpGet: 'http://127.0.0.1:8080/examples/counter'
>        ! !
>
> !SessionCleanupTest methodsFor: 'private' stamp: 'svc 6/9/2010 22:52'!
> numberOfSessions
>        | count |
>        count := 0.
>        WASession allSubInstancesDo: [ :each |
>                count := count + 1 ].
>        ^ count! !
>
> Sven
>
> On 09 Jun 2010, at 19:49, Lukas Renggli wrote:
>
>> Waiting for objects to disappear is tricky.
>>
>> Maybe they are referenced elsewhere?
>>
>> Also the garbage collector might not remove them immediately.
>>
>> Lukas
>>
>> On 9 June 2010 19:46, Sven Van Caekenberghe <sven at beta9.be> wrote:
>>> I thought I saw that somewhere in the code,
>>> but it still does not happen for me...
>>>
>>> On 09 Jun 2010, at 19:17, Lukas Renggli wrote:
>>>
>>>> Seaside by default reaps expired sessions only every 10th newly created session.
>>>>
>>>> Lukas
>>>>
>>>> On 9 June 2010 19:10, Sven Van Caekenberghe <sven at beta9.be> wrote:
>>>>> Hi,
>>>>>
>>>>> I am confused about how WASession instances get cleaned up. This class's documentation says: If the session has not been used for #defaultTimeoutSeconds, it is garbage collected by the system. Which defaults to 600 seconds or 10 minutes if I am correct.
>>>>>
>>>>> No matter what I do, the number of cached sessions doesn't seem to come down. Not after days, never. I see this in all my images on different platforms/vms.
>>>>>
>>>>> To make this repeatable, I tried the following:
>>>>>
>>>>> Take the Seaside One-Click Experience 3.0a5, load ADayAtTheBeach-svc.2.mcz from http://www.squeaksource.com/ADayAtTheBeach. This will install a couple of small demos, including a Seaside implementation of my DW-Bench benchmark.
>>>>>
>>>>> Next, hit it using the Apache benchmark tool, like ab -n 64 -c 4 -d http://127.0.0.1:8080/DW-Bench
>>>>>
>>>>> Have a look at Status/Image and note the number of sessions.
>>>>>
>>>>> Hit it again and note how the number of sessions increases.
>>>>>
>>>>> Wait 10 minutes, force a garbage collect using Status/GC.
>>>>>
>>>>> The number of sessions does not come down.
>>>>>
>>>>> Maybe I am looking at this the wrong way ?
>>>>>
>>>>> Thx,
>>>>>
>>>>> Sven
>>>>>
>>>>> PS: My final goal is to pose some questions about load, performance and tuning, but I want to start by understanding this aspect first.
>>>>>
>>>>> _______________________________________________
>>>>> seaside mailing list
>>>>> seaside at lists.squeakfoundation.org
>>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Lukas Renggli
>>>> www.lukas-renggli.ch
>>>> _______________________________________________
>>>> seaside mailing list
>>>> seaside at lists.squeakfoundation.org
>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>
>>> _______________________________________________
>>> seaside mailing list
>>> seaside at lists.squeakfoundation.org
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>
>>
>>
>>
>> --
>> Lukas Renggli
>> www.lukas-renggli.ch
>> _______________________________________________
>> seaside mailing list
>> seaside at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>