Subject | Re: [IB-Architect] Classic vs. superserver (long, very very long) |
---|---|
Author | Jim Starkey |
Post date | 2002-10-13T20:44:42Z |
Due to a misunderstanding between Eudora and the universe, my
copy of Mark O'Donohue's recent post has been turned into
bitburger, so I can't reply point by point.
Mark expressed a preference for a multi-threaded/multi-process
architecture. I've deleted my first four responses. This
time I'll just ask a few questions.
Mark, how does a client make connection with the server? Only
one process can bind to 3050 (why did I pick that number?). In
classic, inetd or xinetd waits on 3050 then forks off a single
client server. In classic and other multi-client servers the
server itself binds and waits on 3050. Neither of these would
work with the hybrid system. Do you have a design for a
server manager to redirect clients to a designated process?
How much extention to the remote protocol will you have do?
How do you make a close-connection-and-retry-another schema
backwards compatible? What is the additional overhead of another
complete round trip on short transactions?
The engine currently uses the page locks issued by the cache
manager to synchronize access to pages within a process knowing
that a thread switch can't happen while a page is in use. When
you relax this to permit parallel thread execution, you're going
to need a different type of synchronization for threads within
the process. Turning classic's external page locks into
internal buffer locks works just fine in a multi-threaded single
process server. But how do you handle both types of locks with
rewrite vast quantities of extremely tricky code, introducing
deadlocks between the two locking systems, and making the
conditionalization much, much worse?
Doesn't a hybrid multi-threaded/multi-process architecture
combine the worst characteristics of class and superserver
while simultaneous losing the best? Superserver is (in theory)
more efficient because it can use cheaper, in-process, non-AST
generating locks and move pages between database attachments
without a page write, context switch, page read cycle. This
all gets lost in the multi-process case.
Mark, what is the difference between multi-threaded classic
and superserver?
Jim Starkey
copy of Mark O'Donohue's recent post has been turned into
bitburger, so I can't reply point by point.
Mark expressed a preference for a multi-threaded/multi-process
architecture. I've deleted my first four responses. This
time I'll just ask a few questions.
Mark, how does a client make connection with the server? Only
one process can bind to 3050 (why did I pick that number?). In
classic, inetd or xinetd waits on 3050 then forks off a single
client server. In classic and other multi-client servers the
server itself binds and waits on 3050. Neither of these would
work with the hybrid system. Do you have a design for a
server manager to redirect clients to a designated process?
How much extention to the remote protocol will you have do?
How do you make a close-connection-and-retry-another schema
backwards compatible? What is the additional overhead of another
complete round trip on short transactions?
The engine currently uses the page locks issued by the cache
manager to synchronize access to pages within a process knowing
that a thread switch can't happen while a page is in use. When
you relax this to permit parallel thread execution, you're going
to need a different type of synchronization for threads within
the process. Turning classic's external page locks into
internal buffer locks works just fine in a multi-threaded single
process server. But how do you handle both types of locks with
rewrite vast quantities of extremely tricky code, introducing
deadlocks between the two locking systems, and making the
conditionalization much, much worse?
Doesn't a hybrid multi-threaded/multi-process architecture
combine the worst characteristics of class and superserver
while simultaneous losing the best? Superserver is (in theory)
more efficient because it can use cheaper, in-process, non-AST
generating locks and move pages between database attachments
without a page write, context switch, page read cycle. This
all gets lost in the multi-process case.
Mark, what is the difference between multi-threaded classic
and superserver?
Jim Starkey