Subject: Re: NT performance & UNIX (was [netatalk-admins] Trash problems)
From: PayPC System Mail Subscriber (spammail@quanta.paypc.com)
Date: Mon Sep 28 1998 - 15:22:13 EDT
David Winkel said in Re: [netatalk-admins] Trash problems at 29/Sep/1998
(Tue) 03:39:08.
> I know someone who's been doing some fairly serious performance testing,
> mostly to see why web servers do better file throughput on NT than they do
> on unix. The reason is that NT allows for one system call to transfer an
> entire file out of a socket. Which means that the entire transfer is done
> with only one system call, and everything else is handled in the kernel.
> Unix handles all files in (usually) 8K blocks, which means that for every
> 8K, there's a system call. They're not that expensive, but for large
> files, they add up significantly. But, that's most of the reason that NT
> does better than unix when handling file throughput... For those who
> care. :)
Actually even without "dirty API technology" like NT's, my unix box normally
outblasts the NT ones with less CPU usage.
Yes, serving up static content is more efficiently handled this way I
suppose, but it's not what I'm referring to. Alas, I noticed the 2.1.x
kernel notes mention a new syscall basically doing this very same thing. So
you can get it now (2.1.x) or wait a little while longer for 2.2 to be
released, which is expected before year's end. Purist kernel types like
myself really despise this kind of API boundary crossing. "File copies" are
really a "higher layer" function than kernel-level. Basically, what would
prolly do 99% of the performance win without being API child-molestors would
be a strategy to avoid buffer copying as the data percolated down into the
net i/o subsystem.
But we digress from my point... unix is obviously fast enough to saturate
ethernet sending as well as receiving from my PowerMac 8500 when using FTP...
why not with netatalk? (Also, I have no NT file servers, so the performance
is keyed to the UNIX machine even from my Windows clients)
> You could probably aid this by increasing the buffer that netatalk uses to
> read and write files, but that takes additional memory for the buffers,
> too. I haven't looked at netatalk specifically, but if you're right, and
> 16k is the size of the buffer, then increasing that may help, but won't
> fix the problem.
In today's world of cheap RAM, buffer space is cheap. However, I've found
that 8K isn't a terrible choice for most purposes. I think wu-imapd uses 16k
buffers, and when I changed to 64k, I observed no difference in performance.
Turned out I saw the biggest deltas by changing CLIENTs. Oddly enough,
outlook express on both Macintosh and Windows is one of the fastest when
connecting to a unix wu-imap server. Slogs down hundreds of e-mail headers
in mere seconds. Fun to watch, and it really shows imap4's potential, and
why it's so cool compared to pop3.
=Rob=
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:33:19 EST