Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!xanth!mcnc!rti!xyzzy!aquila.DG.COM!harrism
From: harrism@aquila.DG.COM (Mike Harris)
Newsgroups: comp.databases
Subject: Re: Client/Server processes and implementations
Keywords: Client Server Processes
Message-ID: <684@xyzzy.UUCP>
Date: 27 Nov 89 20:42:45 GMT
References: <7139@sybase.sybase.com> <2184@kodak.UUCP> <6895@sybase.sybase.com> <122@tacitus.tfic.bc.ca> <7037@sybase.sybase.com> <125@tacitus.tfic.bc.ca>
Sender: usenet@xyzzy.UUCP
Lines: 68

In article <7139@sybase.sybase.com>, forrest@phobos.sybase.com (Jon Forrest) writes:
> 
> I don't know what you are expecting to see in a multi-threaded
> environment but I think that you would find that a process in our
> kernel is much simplier than you might think. In fact, it's my
> personal belief (that I have no facts to backup) that process
> creation time in our kernel is negligable. It's certainlly less
> than on BSD Unix. But again I don't hold this against BSD Unix.
> Our kernel is a special purpose kernel that can leave a lot of
> the hard stuff to the operating system kernel.
> 
> ----

I'm sure that it is much quicker now. And simpler. And it has it's limitations.
Your company is working on the MP version now. I doubt that it will be
as quick. Or as simple. Or have all of it's previous limitations.
It can't be (as quick, simple). It has processes & threads to coordinate; data
structures to protect, etc.  To some extent your scheduler is converging 
towards the same stuff that the OS kernel is doing. 

Don't get me wrong. The scheduler your people wrote is pretty slick,  and 
it was written to fulfill an unmet need & allowed your product to run 
effectively on PCs. And it does. And it fulfills the needs of a very nice
slice of the marketplace. The other slices, however, are also very nice.
And their requirements are much more stringent in terms of performance,
versatility, tunability, and most importantly, scalability of performance.
Your non MP versions lacks the tunability & scalability aspects to a 
significant degree.

I'm getting off the point some. The primary point is that a database 
developers resources are most effectively utilized when directed against
developing database managers - NOT developing operating systems.

I will also agree that VMS (& yes, even DG's AOS/VS) have significant 
overheads WRT  process creation and context switching. I will also state
that DG's DG/UX implementation can context switch in 100 instructions
(not lines of C). I can't compete with that.

I also argue that the process creation time shouldn't be a primary
consideration. That is, unless, the servers didn't stay up, or were created
on the fly for clients. I'm not arguing for server per client either.

As a case study, I'll discuss a DG platform.

We have a product, TPMS, which runs on AOS/VS. It is a "Transaction Processing
Management System". It supports multiple copies of servers to support load
balancing. It supports multiple server types. It load balances servers against
the load by bringing up & destroying servers. Servers aren't bound to clients.
It event goes as far as having a server "exec" another process type to avoid
the process creation overhead. It knows how to work with DG/SQL SQL servers,
with INFOS servers (another data manager), with DG/DBMS (codasyl), and also
with your code. It's largest customer has an installation with a machine hosting
TPMS along with our data managers & their servers (for their application, 
running under the control of TPMS) with 750 concurrent users.

I could go an and talk about the SPERRY/UNISYS 1100 and the TIP subsystem also.
Perhaps later.

The point  is that while there is some penalty for OS context  switching 
overhead, the gains that can be acheived by taking advantage of an os's
prime resource, processes, more than outweighs the costs of it's use. This
holds for any MP directly, and indirectly for non MPs - mostly as a result
of the tuning that becomes available.

regards,

Mike Harris - KM4UL                      harrism@dg-rtp.dg.com
Data General Corporation                 {world}!mcnc!rti!dg-rtp!harrism
Research Triangle Park, NC


Brought to you by Super Global Mega Corp .com