On Thu, 2004-03-11 at 16:48, Chris Ess wrote:
> On Thu, 11 Mar 2004, Ken Jones wrote:
> > On Thursday 11 March 2004 4:22 pm, Tom Collins wrote:
> [snip]
> > > I'm not sure that there's a need to disable the shared library option
> > > -- I'd like to always build it.
> >
> > I'd like to be able to disable shared libraries.
> > I like not having run time linking each time vchkpw and vdelivermail
> > are run. I'd rather link once at compile time. Makes it just-a-bit-more
> > efficent. The only thing it would save me is recompiling vpopmail dependent
> > libraries on an update, and that's not a big deal for me.
> I see where Mr. Jones is coming from and I agree.  However, I also see
> where having a shared library could be better.  (See, for instance, the
> recurring theme on this list of "I just recompiled vpopmail and now
> qmail doesn't work/users can't authenticate through courier-imap/other
> stuff is broken now.")
Disabling should definitely remain an option since I've both done all
the work, and the bulk of the work was done by autoconf by automagically
supporting --disable-foo for every --enable-foo with a case statement
and some ifs.

The next issue is the bugaboo of performance. Rather than shooting from
the hip, I decided to do some minimal benchmarking. This is all on a
pentiumIII 750Mhz with 128M of physical memory and an IDE hard disk
(7200 rpm). That all said, zero swapping was done during any of the
testing as this is an idle test server. I was trying to do what I could
to eliminate outside influences. The vpopmail binary tested was
vdelivermail, as everyone I think would agree its the most frequently
executed binary on a busy system.
The test run was a loop of 10K vdelivermails to the same account by
export EXT=nick
export HOME=qa.webley
time for((i=0;i<10000;i++)); do echo test | \
/var/vpopmail/bin/vdelivermail '' bounce-no-mailbox; done
I tested four different binaries:
Everything static (including libc)
[EMAIL PROTECTED] root]# ldd /var/vpopmail/bin/vdelivermail
        not a dynamic executable
real    4m59.377s
user    0m47.580s
sys     1m13.210s

Everything dynamic (using the exact patch on sf.net)

real    4m5.353s
user    1m12.150s
sys     1m18.490s

Out of the box vpopmail 5.4.2 (what I run in production) with dynamic
[EMAIL PROTECTED] root]# ldd /var/vpopmail/bin/vdelivermail
        libmysqlclient.so.10 => /usr/lib/mysql/libmysqlclient.so.10 
        libz.so.1 => /usr/lib/libz.so.1 
        libcrypt.so.1 => /lib/libcrypt.so.1 
        libc.so.6 => /lib/libc.so.6
        libnsl.so.1 => /lib/libnsl.so.1 
        libm.so.6 => /lib/libm.so.6 
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 
real    5m27.626s
user    1m6.210s
sys     1m17.560s

Out of the box vpopmail 5.4.2 with static libmysqlclient (done by moving
the .so files out of /usr/lib/mysql so ld couldn't find them)
[EMAIL PROTECTED] vpopmail-5.4.2]# ldd /var/vpopmail/bin/vdelivermail
        libz.so.1 => /usr/lib/libz.so.1 
        libcrypt.so.1 => /lib/libcrypt.so.1 
        libc.so.6 => /lib/libc.so.6
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2
real    4m59.499s
user    0m55.380s
sys     1m15.480s

Now the relocation is going to hit against user space time, rather than
system. The real time is obviously limited by IO, which is something to
bear in mind later.
Obviously the fastest was with everything static, however it only beat
out a "normal" installation by 8 seconds over 10K iterations. Close
behind is a dynamic libmysqlclient 11 seconds back, and then 1 more
second is lost to dynamic libvpopmail.
I'm planning on doing more runs, and seeing if I can introduce some
factors that'd more closely simulate a "production" environment, but
obviously the cost of runtime linking is pretty small percentage wise,
and the bulk of it is in libc (unsurprisingly). 
Another possible place to pickup performance but retain dynamic benefits
is with glibc3.2 and prelinking, though the jury appears to be out in a
big way based on benchmarks all over the web.
Ultimately though, looking at these results (which i consider fairly
average, since the contents of the message was a mere four characters),
75% of time is spent doing IO of one sort or another. We're worrying
about optimizing the remaining 25% by a margin of what, 30 seconds over
10K iterations, or 0.003 seconds. My entire production cluster does
roughly 500K deliveries, so I'd save 1500 seconds of cpu time. On boxes
with idle times above 80% on average. 
Contrast this with an upgrade time of vpopmail/qmail/courier/my
proprietary stuff of roughly 2 hours for each new version of vpopmail. I
lose 0 productivity for that 1500 seconds of "lost" cpu time. I lose 2
hours of productivity having to upgrade all of these components on all
of these servers.
Obviously everyone will need to make their own choices, and I
wholeheartedly support supporting --disable-shared-library, however I
think its a waste of peoples time to use it.
Nick Harring
Webley Systems

ps - my opinions are my own and definitely not those of my employer.
They don't even pay me to have them.

Reply via email to