---------- Forwarded message ---------- From: Mariano Martinez Peck marianopeck@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@veloxit.no, proyecto_relacional@googlegroups.com
On Tue, May 31, 2011 at 11:30 PM, Henrik Sperre Johansen < henrik.s.johansen@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
squeakdbx@lists.squeakfoundation.org