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.")
>
[snip]
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
doing:
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
libmysqlclient
[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.
Cheers,
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.
