Has this anything to do with transactions? What if you commit (hard
commit, not commitretaining) after 20 responses, does the degradation
still occur? Check your OAT (oldest active transaction) and next
transaction.

Have you tested other operating systems, i.e. is the problem specific
to SS under Mandrake 10, or is it just that Mandrake 10 and
SuperServer is the only thing you have tested?

Set

--- In firebird-support@yahoogroups.com, Jacqui Caren wrote:
> Hi,
> I am still investigating this problem and wonder if anyone
> else has any suggestions (other than "don't do that").
>
> I have two sprocs that present the headers and contents of
> an email message - part of an intranet email app.
> They use a number of execute statement calls
> and ~20 UDF's to generate a clob values (sub_type 1's).
>
> The problem is that performance starts at ~20 responses
> per second and degrades to 3 per sec after 200 sequential
> attempts. By reconnecting every 20 attempts I can
> keep performance close to 18 reqs/sec but that can
> only be a temporary workaround.
>
> My first guess was a client side problem so I eliminated
> any (complex) client side code that could be responsible.
> I ended up with a for loop and two selects and still had
> the degradation.
>
> I have eliminated memory leaks and memory or processor
> limitations. The next obvious problem is threading.
>
> A recent NTPL thread discussed problems with Mandrake
> so I am planning on ugrading firebird to 1.5.1 and
> installing the MDK10 patches.
>
> If this does not solve the problem, any suggestions as
> how to investigate the problem server side (above the level
> of process traces) would be appreciated.
>
> Jacqui