> > The reason is that each time you have a connection to port
> > 3050 inetd will spawn another copy of gds_inet_server. Their
> > is extra overhead associated with starting a new process for
> > each connection. If you were in an environment where you were
> > getting lots of separate connections at the same time this
> > would cause a performance problem.
>
> On a modern Unix fork()/exec() has been heavily optimized. The "fork
> is insanely slow" rule of thumb dating from Unix prehistory is often not
> true anymore. On Linux a fork() is really cheap, and the exec can be tuned
> with minor tricks like statically linking the application.

While cheap, its still slow compared to threading the process and using
mutexes to access shared memory. Look at MySQL and how quick it runs along
using threading. The issue isn't so much if a fork() is really cheap or
not, its more so the memory constructions each time you create an instance.

> Preforking and reusing existing processes like Apache does
> offers some speed up, but probably not as much as you may imagine. I
> guess it will be only really beneficial if Interbase has a lot of
> startup overhead per process (I'm not sure if it does, but please
> profile before design). On NT threads are needed, because process creation
> is insanely slow there.

Apache is apache. At the end of the day mutilthreading one server will beat
it hands down.

> Doing it individual processes offers nice reliability advantages.
> The main disadvantage seems to be the lack of shared cache, although
> that could be handled by a shared memory segment. I'm not sure how
> hard it would be to implement that in Classic.

Is this already covered in "Superserver"?

RM