[Seaside] Increasing the performances of a Seaside application

[Levente Uzonyi]

On Sun, 29 May 2011, Mariano Martinez Peck wrote:

> On Sun, May 29, 2011 at 2:19 PM, Levente Uzonyi <leves at elte.hu> wrote:
>
>> On Sun, 29 May 2011, Mariano Martinez Peck wrote:
>>
>>  On Sun, May 29, 2011 at 4:06 AM, Levente Uzonyi <leves at elte.hu> wrote:
>>>
>>>  On Sat, 28 May 2011, Mariano Martinez Peck wrote:
>>>>
>>>>
>>>>   What are the errors that I must avoid making ?
>>>>>>
>>>>>>>
>>>>>>>
>>>>>> AFAIK SqueakDBX uses FFI which to my understanding means that it calls
>>>>>> block the entire VM. That reduces the amount of concurrency a single
>>>>>> image can handle. It also makes a connection pool more important.
>>>>>>
>>>>>>
>>>>>>  Yes, FFI blocks the whole VM while a functions is being called.
>>>>>> However,
>>>>>>
>>>>> if
>>>>> and only if the database client library supports asynchronous queries,
>>>>> SqueakDBX will work asynchronously. Basically, we do a loop where we ask
>>>>> the
>>>>> backend if the query was ready. If it was not, we do a yield (we let
>>>>> other
>>>>> process of the image to run) and then continue the loop.
>>>>>
>>>>>
>>>> FYI: The expression "Processor yield" doesn't let all processes run, just
>>>> those which have the same priority. So using it in a loop starves all
>>>> lower
>>>> priority processes and results in busy waiting.
>>>>
>>>>
>>>>  Thanks.  I was not clear. What we actually do is:
>>>
>>>   (code = OpenDBX resultTimeout) ifTrue: [ (Delay forMilliseconds:
>>> (aQuerySettings timeout asMiliseconds)) wait  ].
>>>
>>> Is that better?  Even if it lets just run processes of the same priority,
>>> this is good anyway because what we want is at least be able to process
>>> other queries. Probably, those other processes are being done from other
>>> Process.
>>>
>>
>> It's a bit better. There's no starvation if the timeout is greater than
>> zero, but it's still a form of busy waiting, and it limits the number of
>> queries per second per connection to at most 1000 (actually 1000 / timeout).
>> To compare this with our native implementation - PostgresV3 - I measured 6k+
>> queries per second per connection and it's still not optimized for Cog
>> (#perform: is slow on Cog).
>>
>>
> Thanks Levente. Unfortunatly I guess that's all we can do with a blocking
> FFI :(

That's right. You can write a custom plugin to avoid blocking if you 
really want to, but I guess the FFI version's performance is enough for 
most applications.


Levente

>
>
>
>>
>> Levente
>>
>>
>>
>>> Thanks
>>>
>>> Mariano
>>>
>>>
>>>
>>>
>>>> Levente
>>>>
>>>>
>>>>
>>>>  http://www.squeakdbx.org/documentation/Asynchronous%20queries
>>>>>
>>>>> Eliot implemented a multi-threaded FFI for Cog but so far I am not sure
>>>>> if
>>>>> it is already working.
>>>>>
>>>>> Cheers
>>>>>
>>>>> --
>>>>> Mariano
>>>>> http://marianopeck.wordpress.com
>>>>>
>>>>>  _______________________________________________
>>>>>
>>>> seaside mailing list
>>>> seaside at lists.squeakfoundation.org
>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>>
>>>>
>>>
>>>
>>> --
>>> Mariano
>>> http://marianopeck.wordpress.com
>>>
>>>  _______________________________________________
>> seaside mailing list
>> seaside at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>
>
>
> -- 
> Mariano
> http://marianopeck.wordpress.com
>