At 01:51 AM 28/05/2005 +0200, you wrote:

> >CpuAffinityMask.
>You can use it only on Windows...

That could be so.

> >
> >Stay with the default settings for this server, which allocate 75 Kb pages
> >(static DbCache) per connection. With a 4Kb page size, this allocates
> >about 300 Kb database page cache to each connection. 512MB of RAM isn\'t
> >much to offer to 20 concurrent users and two CPUs if you set the cache too
> >high. 20 users will eat ~6 Mb of RAM with a 4 KB page

>Exactly! So the server will use only 6MB for cache for all 20 users. Don't
>you think it's too small?

I don't have an opinion, since I don't know your data or your users'
requirements. However, with your small RAM, you need to be conservative
about allocating static cache memory that won't be needed. Cache usage on
Classic isn't dynamic like it is on SS. Assume 75 Kb is enough unless your
testing indicates otherwise.

> >
> >>Server is running on 2.4 SMP kernel - i\'ve heard that 2.6 kernel is
> better
> >>for Firebird CS running on 2CPU (or 2Intel HT CPUs which in fact gives
> >>4CPUs). Is that true ?
>I remember reading kernel 2.6.x release notes in which it was stated that
>SMP support was improved for speed.

That's neither here nor there for Firebird, since it doesn't know how to
behave with multiple processors. The OS will use its rules to decide
whether to send a process to one CPU or another, which may provide some
benefit for load-sharing. The Firebird server doesn't have any "say" in
this; and Firebird itself cannot split a process across multiple
CPUs. But, again, any supposed advantage from upgrading the kernel
wouldn't be expected to show on a server with only 512 Mb of RAM.

> >Test stuff! Compare stuff! You have no startpoint for anything if you
> >don\'t do that. Study the notes in the firebird.conf file to get an
> idea of
> >what the various parameters can achieve.

>
>Yeah, I know, I was wondering if somone had done it already;)

Well, people certainly do "tune" (read "reconfigure") things sometimes to
help improve throughput for this operation or that..but what they do (and
what works) is determined by test results and priorities in the actual,
live environment, not by guesswork. By and large, "tuning" is not a thing
you have to do with Firebird. The crucial "tuning parameters" for Firebird
exist in the ways you structure your data, design your queries and take
care of garbage.

./hb