On Wed, Mar 22, 2000 at 08:05:07AM -0500, Emil Briggs wrote:

> From: Emil Briggs <emil@...>
>
> Markus Kemper wrote:
> >
> > From: "Markus Kemper" <mkemper@...>
> >
> > Not sure what this question has to do with
> > licensing but, here goes.
> >
> > a) For over 15 years InterBase used /etc/services
> > to listen on port 3050 which then has 'inetd'
> > spawn a gds_inet_server (a connection/engine)
> > to perform database work. Perhaps I do not
> > understand everything involved but, I do not
> > believe that inetd is pooling anything. Once
> > the gds_inet_server is spawned 'inetd' is no
> > longer involved and tcp sockets managed the
> > traffic between client and server. Is my
> > understanding correct? And also, why is this
> > deemed unacceptable in an 'enterprise' environment?
> >
>
> 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.

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.

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.


-Andi