At 04:26 AM 25/04/2007, you wrote:

>hello one and all,
>
>i just got a new server with 2 processors on it and installed firebird
>1.5.4.4910 superserver on it. a particularly intensive sql statement
>initiated through a tcp/ip connection with a delphi program causes
>fbserver to go to 50% CPU usage. even if CPUAffinity is set to 3.
>that would be ok, however, other sql statements grind to a complete
>halt until the former statement is done processing.

Not OK. For superserver, you must keep the CpuAffinity set to one processor.

>i once setup an old server of mine with classic because of the same
>problem. however, i installed super because i thought it might work
>ok with the particular motherboard construction and that super has
>been updated so much.

When Superserver supports SMP you will hear the bells ringing all
over the world.

>is there a way to optimize super 1.5 to use both processors with
>multiple and nearly simultaneous sql statements without the bog down i
>seem to be experiencing?

No. Actually, setting SS to multiple cpus on Windows is worse than
you seem to think. SS is a single process with multiple
threads. When the cpu resource usage heads towards 100%, Windows
swings the ENTIRE process over to the other cpu. Then, it swings it
back to the first cpu again. Then.... well, this is referred to as
"the see-saw effect". As load increases, your Firebird server just
comes to a standstill.

>or, will have have to go to classic?

Yes

>i would consider the latter a step backwards. no?

Not at all. It's a step sideways and solves some environmental
problems, particularly those that arise because of limits on 32-bit
processes. However, all things being equal, if your server has
limited resources to cope with multiple concurrent connections, SS is
capable of making better use of the resources across up to about 150
concurrent users, as long as you are strict about setting cpu
affinity to a single processor.

>does fbserver v2 fix the above or not.

No. Major architectural change is coming in v.3, which fully
addresses threading issues at multiple levels.

>i have been a bit reluctant to goto to 2 because of my limited time
>towards migration and testing.

Sounds wise. In V.2 the language engine is a lot stricter about
syntax, so thorough testing of legacy application code is
necessary. If you already addressed the "sloppy syntax" issues in
1.5, the transition is relatively simple.

./heLen