Xref: utzoo comp.databases:4229 comp.infosystems:25 Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!ames!sgi!shinobu!odin!hargrove From: hargrove@harlie.sgi.com (Mark Hargrove) Newsgroups: comp.databases,comp.infosystems Subject: Re: Client/Server processes and implementations Message-ID: Date: 22 Nov 89 18:47:55 GMT References: <7114@sybase.sybase.com> <6895@sybase.sybase.com> <2184@kodak.UUCP> <375@xyzzy.UUCP> <510@xyzzy.UUCP> Sender: news@odin.SGI.COM Distribution: comp Organization: Silicon Graphics Inc, Mountain View, CA Lines: 100 In-reply-to: harrism@aquila.DG.COM's message of 20 Nov 89 18:36:07 GMT In article <510@xyzzy.UUCP> harrism@aquila.DG.COM (Mike Harris) writes: >In article <7114@sybase.sybase.com>, forrest@phobos.sybase.com (Jon Forrest) writes: >Second: >> [edited.... ] but a server of any kind, single process >> or multi process, that runs in a cpu bound environment is not >> running in an environment in which a server should be run. >> Servers are meant to be run on machines with as little else >> going on as possible. [edited.....] > >Perhaps for a simple PC or workstation server. Consider, also, the small >[medium?} size business that has a mix of order entry, order processing, >payroll, accounting, etc, applications. They are very likely to purchase >a medium size "server", probably unix, for their business. This "server" >will be handling ALL of their applications. I would say that the "accounting" >servers have as much right to CPU as the "payroll", or (classic) "order >entry" servers. Accounting, payroll, order entry, etc. aren't servers, they're *clients* of a database server! > >I believe that people, all too often, think of a database server as the only >type of server. Airline reservation systems, and Bank Teller applications are >other examples of services that can (and do) benefit from the client-server >architecture. They (not seen to you at the terminal) also will act as clients >to a database server. What are you trying to get across here? Your first sentence puts forth a proposition which is completely unconnected to the following sentences. > >Even forgetting, for now, about the mixed use departmental server, consider >our server machine hosting a heterogenous mix of server applications. They >are all server processes. Hosted on my "server" machine. How do I tune them >now? The only way the Sybase (or single process server) will get more cpu is >when the other processes wait on it (demand scheduling comes into play). If >some of the other services aren't using Sybase, they wont be forced to >give up cpu to Sybase. > Huh? A server is just a process. Don't make the problem more difficult than it is. There are facilities in all real OS's to allow an administrator to schedule/prioritize a process. >Thirdly: >> [edited....]This is one of the rudements of a >> client/server architecture. > >This has nothing to do with the client/server architecture. It may happen >to be and ideal environment to run it in, but that is beside the point. It has *everything* to do with client/server architecture in the context that concerns this newsgroup, and I think *you* miss the point. The future is here, yet ye refuse to see it. The day of the fully general purpose commercial processor is fading rapidly. Mike Harris's concerns over "mixed application loads" is a symptom of living in this fading day, and entirely misses the vision embodied in the notion of client-server architectures. Here's the idea Mike, since you seem to have missed it: The client and server don't have to run on the same machine. In fact, as Jon Forrest (correctly) points out, in the general case, you don't *want* them to run on the same machine. When CPU demand is low relative to capacity, you can run both clients and servers on the same box. As demand grows, you balance things for a while using whatever scheduling/prioritization facilities the OS has available. As demand continues to grow, you *distribute* the processing load across multiple machines. The *first* action to take is to separate clients from servers! If demand still continues to grow, you separate the servers onto their own machines (and in the extreme (and not at all impractical) case, you run each client and each server on its own machine). This model is simple, elegant, and fundamentally right. The client-server model is what *enables* this controlled evolution of a commercial application environment. Silicon Graphics has VAXen, 500+ Macs, 100+ PC's and over 1000 workstations sitting on our network. I would have to be severely retarded not to *want* to take advantage of all that processing power; the client-server model gives me a practical way to *plan* to take advantage of it. Folks have talked about "coopertive computing" and "distributed processing" for a long time, while still worrying about whether they can fit in just one more report into their nightly batch. The client-server model, as embodied in the actual *products* available from Sybase, Ingres, et.al., make it possible to *do* something today! *Some restrictions may apply. Severe penalties for early withdrawal. :-) -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Mark Hargrove Silicon Graphics, Inc. email: hargrove@harlie.corp.sgi.com 2011 N.Shoreline Drive voice: 415-962-3642 Mt.View, CA 94039