Hi Markus

The mail was not directed to me but anyhow I take the abillity to responce
directly

Markus Kemper wrote:

> From: "Markus Kemper" <mkemper@...>
>
> Hi Phil,
>
> I'll take a whack at this one. We've been discussing this
> issue internally quite a bit. Classic does have some nice
> benefits over SuperServer at this stage in the game. I
> think that most if not all of those benefits could be
> implemented into the SuperServer engine.
>
> > I like the ability to be able to kill a client in Linux
>
> May I ask when and why you find this a benefit. Ann asked
> me to come up with a pros of Classic list a while back and
> this was one of them but, I see this more as a dev-time
> feature vs. a run-time feature. I see a run-time environment
> as one where queries executing against the database are
> tested and known to execute well. In a dev environment
> a bad query may be executed thus killing it is handy.
> Either way 'async-query-cancel' could likely be implemented
> in SuperServer.
>

It is a benefit especially if you are using NT. I agree about the dev-time
testing of the queries but is strongly
data depented. I have an installed IDB with 24 users on an 256MB 2x10GB HD
on a Proliant 3000 PIII -333
and in the begining everything was just fine, Now after 8 months, the main
printouts of the wearhouse system take
about 20-25 minutes to execute and all this period the NT stays at 100% load
and the other users most of the time look
on an SQL cursor waiting. The printout could be given by mistake and,
believe me, I put serial effords to optimize it.
With the clasic architecture on Linux 1) The Proccessor time distribution is
better (I hope this will continue and with the
superserver) and 2) I can kill the Printout proccess (even better I would
prefer to kill a specified user and all the queries he ganerated) and not
have to informe everybody to disconect and the force shutdown the server
(shutding down the database first: does not work always and 2nd caused me
problems whith the SQL rights / the are "lost" and I had to backup / restore
the database in order to get recognized again)

An other case is that there is some kind of database administrator who is
trying to generate some report with a report builder and produces "bad"
queries. The problem is that its very easy to produce such a query. In some
cases it's enough
to join three tables with left joins (a situation tha I can't say tha IB
manages gracefully) I had to put another (Linux) sever with IB 5.6 in
parallel with the NT to manage such situations.

I like very mach the ability to change the metadata run-time the superserver
has. I also hope that its the NT thread management the reason of the
problems and by the way (concerning the Postgress vs IB test) I have run 10
separate executions of the same VERY heavy query both on NT 5.6 (ss) and on
Linux 5.6 (cl) against an 10000x4096 page DB
with 15000 page buffers and the performance on the Linux machine was much
better (same memory, same disk space Compaq server vs Normal PC, 333
Pentium III, 45 Pentium III) The execution time on Linux was about 10%
better and most inportand other users could also work. With the NT - IBss
just impossible and I the memory Load on the Linux machine was about the
same as the NT.

I've also noticed that (I dont know why) most of the times after a period of
inactivity Linux (RedHad 2.2.12 Kernel)
througs the proccss (I mean that the gds_inet... does not apoears active if
use "top")


Best Regards
John Pasvantis