[Seaside] Increasing the performances of a Seaside application

[Philippe Marschall]

2011/5/29 Mariano Martinez Peck <marianopeck at gmail.com>:
>
>
> On Sun, May 29, 2011 at 4:18 PM, stephane ducasse <stephane.ducasse at free.fr>
> wrote:
>>
>> >
>> >
>> > 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 :(
>>
>> Just that I understand why you do not have the same constraints that
>> levente?
>> What are they? because he does not have either a threaded ffi.
>
> Because he uses a native client for PostgreSQL, that is, a driver
> implemented directly in Smalltalk: you open a socket and you implement the
> protocol the database specify. Easy. They use a Socket, and do not need FFI
> because the do not delegate to an external library. They implement the same
> as the external library but in Smalltalk.
> Why we don't do that?
> Because that ONLY and ONLY works for open-sources databases where they can
> make available the protocol specification so that you can build as many
> drivers as you want. However, non open-source databases (Oracle, SQLServer,
> Sybase, etc) DO NOT make the protocol available so you cannot just create
> your own driver.

At least for SQLServer/Sybase it seems to be available [1]. You can
get it for Oracle, just not for free and not in an OSS compatible way.

 [1] http://en.wikipedia.org/wiki/Tabular_Data_Stream

Cheers
Philippe