|Re: [IB-Architect] Re : License Question
> > The reason is that each time you have a connection to portWhile cheap, its still slow compared to threading the process and using
> > 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.
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 doesApache is apache. At the end of the day mutilthreading one server will beat
> 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.
it hands down.
> Doing it individual processes offers nice reliability advantages.Is this already covered in "Superserver"?
> 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.