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

Tue Jul 5 21:08:47 UTC 2011

---------- Forwarded message ----------
From: Mariano Martinez Peck <marianopeck at gmail.com>
Date: Wed, Jun 1, 2011 at 8:54 PM
Subject: Re: Increasing the performances of a Seaside application
To: Henrik Sperre Johansen <henrik.s.johansen at veloxit.no>,
proyecto_relacional at googlegroups.com

On Tue, May 31, 2011 at 11:30 PM, Henrik Sperre Johansen <
henrik.s.johansen at veloxit.no> wrote:

>   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 :(
>
> Not really :)
>

Thanks Henrik.

Before analyzing your suggestions, let me tell you something stupid we did
in DBX that I have just realized.  There are TWO different timeouts.

1) OpenDBX timeout: the one send by parameter to OpenDBX function:
http://www.linuxnetworks.de/doc/index.php/OpenDBX/C_API/odbx_result
that determinates the time the C function of OpenDBX waits for the result.

nextResultSet: aConnection querySettings: aQuerySettings onReturn: aBlock
    "Returns the next resultSet from the last resultSet. When there is no
more resultSets,
    the block is evaluated."
    | handle err handleArray |
    handleArray := WordArray with: 0.

    err := OpenDBX current
                apiQueryResult: aConnection handle
                handle: handleArray
                timeout: aQuerySettings timeoutAsDBXTimeSpec
                chunk: aQuerySettings pageSize.
......

2) SqueakDBX timeout: the time we wait in the IMAGE side once we got a
timeout from OpenDBX.
this is what I showed you:

    (code = OpenDBX resultTimeout) ifTrue: [ (Delay forMilliseconds:
(aQuerySettings timeout asMiliseconds)) wait  ].

So....as you can see we are using both values for both things. This is not
necessary and maybe stupid.

The default timeout now is 10 miliseconds

>> defaultTimeout
    "10 miliseconds"
    ^DBXQueryTimeout seconds: 0 microseconds: 10.

So...if I follow your a)  you smartly recommend to use 100ms. And in this
case you are talking about the OpenDBX timeout and only for the first time.
This way most queries will be cought in the first try and even if they do
not, we return fast. And then, for future calls of the same query (only if
there is a timeout) we use a really short timeout. For example 1ms. The idea
is to wait as much as possible in image side (Delay) rather than C.

At the same time, with b) you recommend you use an incremental SqueakDBX
timeout (the Delay). So we can start with 1 ms and then grow 2 4 8 16 32 64
128 256 512 up to 1024. And if we get until 1024 we continue using that
value?   but isn't 1ms too small? because this value will be used if a
timeout happened (the result took more than 100ms). So it is quite weird
that it will be ready just 1ms after. No?

so...did I understand correctly ?

>
> You could
> a) Use a default timeout for the first call which means it actually
> completes more queries on the first try yet still returns fast, say 100ms
> rather than 1ms.
> (For later calls just to check if it is possibly finished, you probably
> want to block for as short a time as possible though)
> b) Use an exponentially growing value for the Delay rather than a constant
> one, starting at 1ms and max some other value
> 1 2 4 8 16 32 64 128 256 512 1024 for instance, polling once per second
> shouldn't hurt other processes at all, yet give ok responsiveness for
> queries > 1 seconds.
>
> This way, you (in the cases where potential is 9k queries /sec) will have a
> hard cap at 10k queries (due to the 100ms block time), and hurt those above
> that as little as possible using Delays. What you don't have though, is a
> cap of around 1k, due to calls never completing in 1ms, and having to wait
> (at least, I don't know the default value of aQuerySettings timeout) 1ms for
> each due to minimum delay wait time resolution.
>
>
>
>
 Btw, unless the microseconds and seconds are switched, this could be
> simpler (as well as misspelled :) ):
> DBXQueryTimeout >> asMiliseconds
>     ^ (self seconds * 1000) + (((self microseconds / 1000) asFloat)
> integerPart asInteger )
>     ^ (self seconds * 1000) + (self microseconds // 1000)
>
>
Thanks :)

> DBXTimeSpec also has an field called nseconds which contains microseconds,
> rather confusing :)
>

yes, I know. The problem was the OpenDBX/C uses that structure but from
image side it was nicer to use microseconds hehehehe

>
> Cheers,
> Henry
>

-- 
Mariano
http://marianopeck.wordpress.com

-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeakdbx/attachments/20110705/cbdf4219/attachment.htm