On Friday, 17 September 1999 at 11:17:48 -0700, Matthew Dillon wrote:
> : Might I then request that you help rewrite it so that it performs
> :a much more comprehensive testing of OS/filesystem throughput?
> :Myself, I'd really love to see something that lets you seriously
> :stress your syste
: Note that with a mail server, this is precisely the sort of thing
:that happens with /var/spool/mqueue. In particular, with sendmail, a
:qf/df pair of files get created, the message is received, the sender
:is told "250 Ok", then sendmail goes to deliver the message in the
:background
Ok, these are on duel P3 450 boxes running -CURRENT, with the NFS
performance enhancements. Local disk is an 18G seacrate on an LVD/W
scsi bus.
UFS tests: on 1G duel P3-450 machine, 1x18G seagate SCSI-LW bus
NFS tests: 1G duel P3-450 client, 512M duel P3-450 server, 100Base
At 1:02 PM -0700 1999/9/17, Matthew Dillon wrote:
> Sendmail does not get into trouble with queue files it is able to retire
> quickly. Where sendmail gets into trouble is with queue files it ISN'T
> able to retire quickly. This is why you *see* 10,000+ files in mqueue
> at time
At 11:56 AM -0700 1999/9/17, Matthew Dillon wrote:
> In real-life... for example, with a mail or web server, the namecache
> tends to be somewhat more effective then 50%. The web servers at BEST
> generally had a 95%+ name cache hit rate. The name cache misses are
> what are cau
At 11:17 AM -0700 1999/9/17, Matthew Dillon wrote:
> What we really need is something that generates a performance
> curve based on several variables, including block size, locality of
> reference (seek randomosity), amount of parallelism, locality of
> parallelism (i.e. operating
