hargrove@harlie.sgi.com (Mark Hargrove) (11/23/89)
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
harrism@aquila.DG.COM (Mike Harris) (11/28/89)
In article <HARGROVE.89Nov22184755@harlie.sgi.com>, hargrove@harlie.sgi.com (Mark Hargrove) writes: > 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: [edited.... ] > > Accounting, payroll, order entry, etc. aren't servers, they're *clients* of > a database server! > > > [harris's stuff about Airline reservation systems, Bank Tellers, etc] > > [Stuff about these being both servers [to users] [& clients of dbs ] > >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. > Open your eyes and look at the marketplace! My point is EXACTLY what I said and I will quote again: "I believe that people, all too often, think of a database server as the only type of server." Coonsider how the Airlines reservation system operates. (a CLASSIC high volume TP application). Bank Card & Credit Card validations systems are other similar examples. There are about 50,000 terminals out there. They are connected via complex com networks into the computing complex. The terminals are CLIENTS of [a heterogenous mix of] forms handling SERVERS. These packetize the requests and forward them to the reservations SERVERS suite of processes. These are managed by a TP manager. These in turn, are CLIENTS of the database, and also CLIENTS of the TICKET printers, etc. Theses systems provide not only database integrity,but that of ticket printing, screen recovery, etc. The database is but ONE of MANY parties to the commit. They are but ONE of MANY resources managed & corrdinated. Consider teller applications. The banks are VERY serious about being sure that you don't get $ from the machine unless they debit your account. The primary parties here are 1) the database, and 2) a process or service which guarantees delivery of the cash dispensing. Theses two participate in a JOINT commit protocal. Yes, often a database is ONE of the SERVERS consulted. Ever consider a nested heirarchy? We have a client server manager which doesn't force pure clients and pure servers. The applications which run under it can act as both clients and servers as required to get the job done. A database server is typically just one of many other servers participating in a unit of work. The servers (before the data managers) run very well, but they take advantage of our automatic load balancing. The application often needs more front end servers running than database servers. > > > > [Harris's comments about heterogenous server process mix] > > 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. I agree that real OSs allow an administrator to do this. I have worked on several "real" OSs, & now, unfortunately, I am being paid to make some of the same stuff run on UNIX. I also heartily support threads (os especially). Unfortunately, we have applications that we want to sell on the UNIX platform. There is a considerable amount of $$ there & people want to spend it. If you want to sell into a marketplace you must meet it's immediate, or at worst, it's needs in the immediate future. The market isn't waiting for threads or powerful schedulers in UNIX. IT WANTS UNIX. This pains me also! So, for my target environment, I must do Multi servers, etc. A second point is that even if you have a powerful scheduler, It MIGHT be able to help on an MP HDW IFF the application mix is sufficiently balanced that the scheduler could be told to run servers on different CPUs, etc. Otherwise it commonly happens that a processor is idle (often >10% of the time even on a busy system) because there wasn't a second server to schedule against that cpu. You can't play the game if you don't have the equipment. [edited....; stuff from everybody about "This is one of the rudements of a client/server architecture."] & [a comment about my vision relative to the future, etc] Touchy, Touchy, Touchy! I heartily agree with distributed processing, threads, RPCS, multi's, pcs, heterogenous environments. I am not a stodgy old fart who wants to buy a bigg'n from IBM! I just take issue with people who aren't open enough or don't (but claim to) know enough about the marketplace to consider applications other then their own! Learn something about the common High Volume TP applications. Learn something about other peoples applications. Think about multi level CLIENT/SERVER applications. Imagine a world where everything was a PC. Somebody would say "You know, there are situations where a bigger machine which could hold more of (or all of) my application would be faster & more cost effective" And he would buy it from the people who could supply them. The proper machine environment depends upon the specific APPLICATION, not some general theories! "Money talks & bullshit walks." > hargrove regards, Mike Harris - KM4UL harrism@dg-rtp.dg.com Data General Corporation {world}!mcnc!rti!dg-rtp!harrism Research Triangle Park, NC
hargrove@harlie.sgi.com (Mark Hargrove) (11/30/89)
In article <724@xyzzy.UUCP> harrism@aquila.DG.COM (Mike Harris) writes:
Open your eyes and look at the marketplace! My point is EXACTLY what I said
and I will quote again: "I believe that people, all too often, think of a
database server as the only type of server."
[comments about nested, multi-level client-server architectures deleted]
Whoops, I find that we're in violent agreement on this issue, I just didn't
follow your point the first time.
[re: my complaints about Mike's lack of vision]
Touchy, Touchy, Touchy! I heartily agree with distributed processing,
threads, RPCS, multi's, pcs, heterogenous environments. I am not a stodgy
old fart who wants to buy a bigg'n from IBM! I just take issue with people
who aren't open enough or don't (but claim to) know enough about the
marketplace to consider applications other then their own! Learn something
about the common High Volume TP applications. Learn something about other
peoples applications. Think about multi level CLIENT/SERVER applications.
Imagine a world where everything was a PC. Somebody would say "You know,
there are situations where a bigger machine which could hold more of
(or all of) my application would be faster & more cost effective" And he
would buy it from the people who could supply them. The proper machine
environment depends upon the specific APPLICATION, not some general
theories! "Money talks & bullshit walks."
Again, we're in violent agreement. In fact, I do know quite a bit about
reasonably high volume TP applications, and what kind of iron it takes
to support them. I certainly didn't mean to imply that you can (or even
want to) do everything with PC's. From a user's perspective, a PC will
frequently host client applications, but you are CLEARLY correct about
two things: all sorts of iron will be involved, and many participating
computers will act as servers for some functions and will be clients to
other servers as well.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Mark Hargrove Silicon Graphics, Inc.
email: hargrove@harlie.corp.sgi.com 2011 N.Shoreline Drive
voice: 415-962-3642 Mt.View, CA 94039