Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!uakari.primate.wisc.edu!xanth!mcnc!rti!xyzzy!aquila.DG.COM!harrism From: harrism@aquila.DG.COM (Mike Harris) Newsgroups: comp.databases Subject: Re: MP servers Message-ID: <689@xyzzy.UUCP> Date: 27 Nov 89 21:17:13 GMT References: <7141@sybase.sybase.com> <13520003@hpisod2.HP.COM> Sender: usenet@xyzzy.UUCP Lines: 49 In article <7141@sybase.sybase.com>, forrest@phobos.sybase.com (Jon Forrest) writes: > > In article <13520003@hpisod2.HP.COM> dhepner@hpisod2.HP.COM (Dan Hepner) writes: > > > >Maybe you could discuss the abstract question, without offering > >any claims about any Sybase product. > > > First, my input to your MP question: First, It is VERY advantageous to have a server per processor. That way time can be allocated against your workload, concurrently, by both processors. The overhead involved (not insignificant) is more than made up by the extra cycles that your workload receives. And also by the scalability the product (to >2 MPs, tuning, etc). Also, it is advantageous to have multiple servers even on a singe processor for another reason: That being I/O. Unless a server is very smart (Sybase does have os hooks to take advantage of this in some circumstances where available in the os platform) it will be hung when it performs I/O, or verrrrry long queries. Even with disk caching and async I/O, pended writes are still required during the commit phase. > The other reason why I can't comment on matters relating to the > MP server is because I don't know anything about it, or at least > not enought to present even the relevant abstract questions > intelligently. Unhappily, you'll have to wait for someone else > from Sybase to respond or you'll have to wait for more general information > to appear from Sybase. Sorry. I now understand the reasoning, or lack thereof, in Jons previous discussions. I'm sorry, but I don't see how one can reasonably discuss the merits of even a single server architecture without understanding the basics of multiple server architectures. Especially considering the fact that their product has a notion of "threads". The problems & challenges are very similar in nature. I do respect him for finally admitting it. This is a forum for discussion. Let's ask questions & learn answers - not act like experts where we aren't. > > ---- > Anything you read here is my opinion and in no way represents Sybase, Inc. > Unfortunately, most people forget about this line - esp when the person is arguing the merits of their companies product on a forum such as comp.databases. regards, Mike Harris - KM4UL harrism@dg-rtp.dg.com Data General Corporation {world}!mcnc!rti!dg-rtp!harrism Research Triangle Park, NC Brought to you by Super Global Mega Corp .com