Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!asuvax!anasaz!john
From: john@anasaz.UUCP (John Moore)
Newsgroups: comp.databases
Subject: Re: Client/Server processes and implementations
Keywords: Client Server Processes
Message-ID: <947@anasaz.UUCP>
Date: 30 Nov 89 14:47:29 GMT
References: <936@anasaz.UUCP> <7114@sybase.sybase.com> <6895@sybase.sybase.com> <2184@kodak.UUCP> <375@xyzzy.UUCP> <510@xyzzy.UUCP> <718@xyzzy.UUCP>
Reply-To: john@anasaz.UUCP (John Moore)
Organization: Anasazi Inc, Phoenix AZ
Lines: 47

In article <718@xyzzy.UUCP> harrism@aquila.DG.COM (Mike Harris) writes:
]In article <936@anasaz.UUCP>, john@anasaz.UUCP (John Moore) writes:
]> In article <510@xyzzy.UUCP> harrism@aquila.DG.COM (Mike Harris) writes:
]    [stuff about cpu allocation]
]> 
]> [much good stuff about Unix needing to grow up & provide a configurable
]>  scheduler, better I/O facilities, etc]
]
]I fully agree. However, many business, which are run by people that aren't
]as technical as your group, Spec UNIX for "portability" and "open systems". 
]It is pure Specmanship.  Our AOS/VS operating system has all of the OS process 
]scheduling and I/O support you mentioned, including mirroring. We even have 

After having been stung by having our software run on a proprietary platform
(IBM S/1 EDX - yeach!), our company is very serious about portability. This
is why I would like to see the configurable scheduler, better I/O, etc
in UNIX (as a standard), and have difficulty taking advantage of it when
it is a one-off customization in one manufacturer's kernel. Of course, if
the RDBMS manufacturer does it, I don't have to worry about it as much, but
I still contend that life would be better for OLTP customers if Unix
were to develop better OLTP performance related features.
]
]> we have found that lock contention consumes lots of CPU when
]> you have a large number of very active processes. The single
]> server (or few servers) is a good way to reduce the lock overhead.
]
]Your threads will have to cooperate also. If they can be scheduled, 
]concurrently, against multiple CPUs then that is the way to go.
]
Yes, that's true. However, if you use a few multi-threaded processes,
and can make the locking routines non-pre-emptable, the contention is
minimized.
]Overhead is inescapable when processes or threads must cooperate. Typically
]the price is worth the gain.
Not in our benchmarks (which were, I admit, rather extreme!).

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



-- 
John Moore (NJ7E)           mcdphx!anasaz!john asuvax!anasaz!john
(602) 861-7607 (day or eve) long palladium, short petroleum
7525 Clearwater Pkwy, Scottsdale, AZ 85253
The 2nd amendment is about military weapons, NOT JUST hunting weapons!


Brought to you by Super Global Mega Corp .com