Date: Sun, 13 Apr 1997 18:28:23 +0900 (KST) From: grog@lemis.de To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: chat@FreeBSD.ORG (FreeBSD Chat) Subject: Re: Informix efficiency--any ideas? Message-ID: <199704130928.SAA01139@papillon.lemis.de> In-Reply-To: <199704110211.LAA08433@genesis.atrad.adelaide.edu.au> from Michael Smith at "Apr 11, 97 11:41:45 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Michael Smith writes: > grog@lemis.de stands accused of saying: >> >>> TBH, I don't know how the various SMP implementations would come into >>> play here; specifically on the send/recv model I would expect >>> (assuming an idle system) that one half would be running on each CPU, >>> ie. the long-term throughput would be that of the slowest component >>> rather than of the system as a whole. In contrast, the lock-step >>> model using semaphores basically ensures that a single client/server >>> pair runs as a single logical thread. >> >> Now that's an interesting thought. Basically, the socket >> implementation doesn't even need to be as fast as the semaphore >> implementation (*if* you're restricting your semaphore counter to 1. >> IIRC, you can have more than one on System V), since it can queue. >> That might explain why we were getting up to 30% idle on System A. > > I would expect that the server would only use multiple semaphores if > it could guarantee the order in which it woke on them, as otherwise > there could be problems with transaction ordering. My understanding is that the semaphores are required to ensure that the requestor and the server don't tread all over each other in shared memory. >> In the meantime, we have found some more documentation. It seems that >> there are "protocols" for talking to the server. One is called >> tlitcp, and the other is called ipcshm. System A was using ipcshm, >> and system B was using tlitcp, so now we're repeting a (longer, more >> accurate) benchmark the other way round. > > I would expect that the TLI/TCP interface will be much more efficient > in the SMP context than the IPC/SHM interface, simply because by nature > it will offer better decoupling between the client and server. > Could be wrong, of course 8) Looks like you are. Sure, if you want to run up a queue, TLI or sockets (on machine B) sound better than a lock-step semaphore business. But in this case, it's just the primitive of letting the server or the requestor know when the data is available. On the down side, going through the TCP and IP stack just to pass a local message is relatively inefficient. > It would be _very_ informative to be able to run this benchmark on a > well-configured SMP FreeBSD system, as I understand that Informix runs > well under the SCO emulation. I would imagine that the SMP Mips > systems you are looking at would be a lot more expensive 8) Indeed it would. I have an Oracle CD-ROM which has been floating around for a while waiting for me to take a look. Want to borrow it? > (ps. what do you think of Viewsonic's 21" monitors? They're reasonably > available around here...) Well, I've heard the name... what are the specs like, and what do they cost? Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704130928.SAA01139>