[SqueakDBX] Re: [Seaside] Increasing the performances of a Seaside application

Mariano Martinez Peck marianopeck at gmail.com
Sun May 29 12:49:08 UTC 2011


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 :(



>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeakdbx/attachments/20110529/0f9cab05/attachment.htm


More information about the SqueakDBX mailing list