Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!dev!dgis!jkrueger From: jkrueger@dgis.dtic.dla.mil (Jon) Newsgroups: comp.databases Subject: Re: Performance Data (was Re: Client/Server processes and implementations) Message-ID: <679@dgis.dtic.dla.mil> Date: 29 Nov 89 22:12:06 GMT References: <7169@sybase.sybase.com> <13520004@hpisod2.HP.COM> Organization: Defense Technical Information Center (DTIC), Alexandria VA Lines: 31 dhepner@hpisod2.HP.COM (Dan Hepner) writes: >1. Is it your experience that more than 10% of the work is done by > the clients? Sometimes. If it's only 10%, we may then assign 10 clients per server, thus balancing the load. Yes, the server load increases too, but not proportionately; balance might be 12 or 15 clients per server. >2. Is it your experience that remote communication costs don't end > up chewing into the savings attained by moving the clients > somewhere else? No, the lower bandwidth is more than offset by multiprocessing. When this isn't true, you probably have a poorly partitioned problem, not insufficient communiciations hardware. The same profiling that tells you who's shouldering more of the processing burden will also reveal if both sides are waiting for communications. >>(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 isn't the extreme case. Multiple processors can divide work with better granularity than client and server processes. -- Jon -- Jonathan Krueger jkrueger@dtic.dla.mil uunet!dgis!jkrueger Isn't it interesting that the first thing you do with your color bitmapped window system on a network is emulate an ASR33? Brought to you by Super Global Mega Corp .com