Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!think!ames!sgi!shinobu!odin!hargrove From: hargrove@harlie.sgi.com (Mark Hargrove) Newsgroups: comp.databases Subject: Re: Performance Data (was Re: Client/Server processes and implementations) Message-ID: Date: 30 Nov 89 00:09:43 GMT References: <7169@sybase.sybase.com> <13520004@hpisod2.HP.COM> Sender: news@odin.SGI.COM Organization: Silicon Graphics Inc, Mountain View, CA Lines: 65 In-reply-to: dhepner@hpisod2.HP.COM's message of 28 Nov 89 20:40:10 GMT In article <13520004@hpisod2.HP.COM> dhepner@hpisod2.HP.COM (Dan Hepner) writes: From: hargrove@harlie.sgi.com (Mark Hargrove) > >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. How much this will buy you is directly dependent upon the distribution of CPU cycle requirements between the clients and the server(s), and the relative cost of remote vs local communication between the clients and the server. Huh? I'm afraid I don't understand what you're getting at wrt "distribution of CPU cycle requirements". Naturally, you are correct in assuming that you do have to ponder communication costs when building client-server models. 1. Is it your experience that more than 10% of the work is done by the clients? 10% of *what* work? It's my experience that a client does 100% of the work that's appropriate for the client to perform. The content of this work is highly variable -- it depends upon your application. Clients make requests to servers, and then do something with the results. A "typical" client-server application might have the client application handling presentation, user interface, and flow of control, while making requests of database servers (and perhaps of directory servers to locate the DB servers, and perhaps of Kerberos-type servers to handle authentication, etc.) 2. Is it your experience that remote communication costs don't end up chewing into the savings attained by moving the clients somewhere else? What do you mean by "remote"? What do you mean by "cost"? If my client and server live on the same ethernet (or FDDI ring, or UltraNet backbone) then no, I don't see a problem. On the other hand, if I'm communicating over a 300 baud dial-up network, then I'd better be pretty sure my clients aren't impatient for responses from the servers. Nevertheless, there are clear cases where even this slow link is perfectly OK. Try rephrasing your question :-). >(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. This would require basically a 50-50 split of the workload between the client and server. A practical assumption? No! Not at all. I'm not sure you really understand the notion of client-server. Have you read Mike Harris' recent postings? He gives good examples of what client-server is all about. I think *you're* drifting in the direction of distributed processing, where a single problem is broken up and shared by several machines. This is NOT what we're talking about here. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Mark Hargrove Silicon Graphics, Inc. email: hargrove@harlie.corp.sgi.com 2011 N.Shoreline Drive voice: 415-962-3642 Mt.View, CA 94039 Brought to you by Super Global Mega Corp .com