At 11:50 PM 10/15/02 +0400, Nickolay Samofatov wrote:

>
>We spawn one listener process per each interface/port/protocol we listen to.
>It submits jobs to a pool of worker threads/processes and returns
>results to a client when they are ready.
>

How does the listener process communicate with the worker processes?
Do you use any of the existing plumbing or did you roll your own?
Do you support the full API?

Does this mean that every client request requires a listener process
wake up, a context switch to the worker thread, and a context switch
back to listener process?

This is rather ironic because the fundamental idea behind classic
is that a call instruction to a process based database is so much
faster than a pair of context switches to and back from a server
process. Now you're paying the overhead of the server architecture
without the benefits.

I'm perfectly willing to believe that this archicture works well
for a massive number of predominately read requests, but I continue
to question whether this system performs under load. Just about
every performance study I'm aware of has shown that classic becomes
IPC bound under a heavy, contentious update load.

>
>My general idea is that server should be modular and flexible to allow
>to work in different environments w/o recompilation or modification.
>

Certainly a noble goal. But it can be achieved only by a substantial
cost in complexity, as any code change checked in would have to
tested against all configurations, and any major configuration-
specific overhaul would face major resistance.

Jim Starkey