Date: Thu, 10 Apr 1997 17:17:34 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: chat@freebsd.org, grog@lemis.de Cc: hackers@freebsd.org, chat@freebsd.org Subject: Re: Informix efficiency--any ideas? Message-ID: <199704100747.RAA01734@genesis.atrad.adelaide.edu.au> In-Reply-To: <199704100623.PAA01255@papillon.lemis.de> from "grog@lemis.de" at "Apr 10, 97 03:23:05 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
grog@lemis.de stands accused of saying: > > We did some examination and found that the port of Informix on A > performs 21729 system calls to insert 5000 records into a table. Of > these, 21403 calls are to semsys. B performs approximately half this > number of calls, equally split (what a surprise) between send() and > recv(): although it's System V.4, it has a native sockets > implementation. > > I'm obviously following this up with Informix and vendor A, but I'd be > interested if anybody here had a view with a different bias. Do > semaphores have to be so much less efficient, or could this just be a > poor semxxx() implementation on A? I don't think it's that the semaphores are less efficient, but that there is more semaphore activity required to transfer the given data. At a guess, a record transaction with semaphores goes something like : writer puts data in shared memory area, raises 'data is there' semaphore. reader wakes on semaphore, raises 'I am busy with your data' semaphore reader finishes with data, lowers 'I am busy with your data' semaphore writer wakes on semaphore, repeat. That's 4 system calls for a single transaction. With sockets, I would expect : writer calls send() with data, repeat reader returns from recv() with data, repeat ie. two calls, and if socket buffering works the two will be decoupled as well, reducing the impact of the (potentially) less efficient send/recv by eliminating the context switches between transaction cycles. 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. > Greg -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704100747.RAA01734>