Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!mtxinu!sybase!phobos!forrest From: forrest@phobos.sybase.com (Jon Forrest) Newsgroups: comp.databases Subject: Re: Client/Server processes and implementations Keywords: Client Server Processes Message-ID: <7237@sybase.sybase.com> Date: 28 Nov 89 17:18:16 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> <684@xyzzy.UUCP> Sender: news@sybase.sybase.com Reply-To: forrest@sybase.com Organization: Sybase, Inc. Lines: 76 In article <684@xyzzy.UUCP> harrism@aquila.DG.COM (Mike Harris) writes: >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. > Although you are welcome to talk theoretically, until you can buy our (or anyone else's) MP product it isn't fair to talk about what such a product can or can't do. I have been careful to avoid discussing our MP product partially because it isn't right to talk about unreleased products on comp.databases. [a bunch of good stuff edited out] >Your non MP versions lacks the tunability & scalability aspects to a >significant degree. > Please elaborate. How does our current (Release 4.0) product lack tunability and scalability? >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. > Since a database management system is intimately tied to many capabilities provided by an operating system, it is difficult for database developers to ignore operating systems. There is also the matter of being able to provide replicable performance on a number of different platforms. By using a portable kernel we can better understand how our database system will perform. Some companies (not just DBMS companies) that sell a product that runs on a number of different platforms are selling essentially a different product for each platform because the implementation on each platform is based on platform specific code. Sybase has made the effort to make most of our code portable. > >I also argue that the process creation time shouldn't be a primary >consideration. I agree. I only mentioned this in response to a previous posting. > >As a case study, I'll discuss a DG platform. > [a good description of a very interesting DG DBMS] > > >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. > Again, having multiple servers accessing the same database requires all sorts of additional concurrency control using O.S. services. I don't argue that in theory being able to do this is a bad idea. However, I believe that in practice, especially when a product has to run on many platforms and under many O.S.'s, the penalty in doing this can eat up much of the gain. When you combine this with all the platform specific code you'd have to have I'm not convinced that the net result is a win. To me, given where things are going, I'm much more interested in seeing a "server" run on a 6 CPU MP machine than on 6 separate machines. ---- Anything you read here is my opinion and in no way represents Sybase, Inc. Jon Forrest WB6EDM forrest@sybase.com {pacbell,sun,{uunet,ucbvax}!mtxinu}!sybase!forrest 415-596-3422 Brought to you by Super Global Mega Corp .com