Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!asuvax!anasaz!john From: john@anasaz.UUCP (John Moore) Newsgroups: comp.databases Subject: Re: Client/Server processes and implementations Keywords: Client Server Processes Message-ID: <936@anasaz.UUCP> Date: 22 Nov 89 14:48:15 GMT References: <7114@sybase.sybase.com> <6895@sybase.sybase.com> <2184@kodak.UUCP> <375@xyzzy.UUCP> <510@xyzzy.UUCP> Reply-To: john@anasaz.UUCP (John Moore) Organization: Anasazi Inc, Phoenix AZ Lines: 45 In article <510@xyzzy.UUCP> harrism@aquila.DG.COM (Mike Harris) writes: ]An example: If there are M processes on the system, including the Sybase server, ]successfully competing equally for cpu resources, the distribution of cpu ]will be 1/M *100 percent per process. If the Sybase server could run N ]servers, the distribution would be 1/(M+N) *100 percent per process. Since ]there were N servers working for the same application (Sybase), the ]distribution to Sybase would be N/(M+N) *100. ] ]Grant me that M=5 and that there was enough Sybase work to allow N=2. With ]a single server architecture, the distribution to Sybase would be 1/5 *100, or, ]20% of the CPU. Given the multi server architecture, the distribution would ]change to 2/(5+2) *100, or 28.5%. A significant change indeed! What all of this points out is not so much the problem with a single server as with the normal Unix operating system. I grant that a single server won't take full advantage of multi-cpu systems. However, if Unix is to be used seriously as a database server, the scheduler should get smarter - you need to be able to tune the cpu usage by process class. Likewise, you need better I/O system, which has: asynchronous I/O, ordered I/O (FIFO disk I/O on request), and disk mirroring. Sybase has dealt with this by writing their own device driver. Unfortunately, this has limited their portability. The lack of portability, and the lack of ability to effectively utilize more than one CPU are two of the reasons that we reluctantly disqualified Sybase from our recent high performance RDBMS selection process. By the way, the Pyramid OS has all the features I described above, and we are using it. I wish it was standard in the industry! Anyhow,... the fact is that with proper cooperation from the OS scheduler and I/O system, architectures that allow requests from many processes to be served by one server can do a better job than process per server. We just benchmarked a realistic application mix where the Informix back-end memory usage alone exceed 350MBytes! The advantage of one process per multiple users is that the "threads" can be cheap - low memory usage, low CPU usage because of precisely targetted scheduling algorithms. In addition, it is cheaper for them to cooperate for optimized scheduling. Finally, we have found that lock contention consumes lots of CPU when you have a large number of very active processes. The single server (or few servers) is a good way to reduce the lock overhead. -- John Moore (NJ7E) mcdphx!anasaz!john asuvax!anasaz!john (602) 861-7607 (day or eve) long palladium, short petroleum 7525 Clearwater Pkwy, Scottsdale, AZ 85253 The 2nd amendment is about military weapons, NOT JUST hunting weapons!