Subject: Re: [netatalk-admins] Trash problems
From: David Winkel (dwinkel@umich.edu)
Date: Mon Sep 28 1998 - 13:39:08 EDT
> Adrian: on another note, what sort of performance improvement areas would you
> think are best pursued. I seem to get very high transfer rates (with
> inferior os's like Windows NT) with SAMBA - but with netatalk, I get no more
> than about 600-650k/sec with netatalk. Would read-ahead/prediction code
> help? Larger i/o buffers perhaps? Or perhaps read/write overlapping
> technology
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. :)
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.
> read case
> ---------
> Request for 100k arrives
> [ 16k chunk comes in off disk] -- netatalk starts to send it down the
> wire....
> by the time the 16k chunk's sent, the rest of the 84k has arrived from disk
> and can continue being sent w/o delay.
>
> This way, the data gets sent to the client a few milliseconds sooner (at
> least). [I'm assuming 10baset ethernet and SCSI harddrives of at least
> 1.5Mb/s or greater and no fragmentation].
>
> Write case is similar, except it begins writing the data after a certain
> fraction of the data has arrived... with systems like Linux which cache so
> much and intelligently (write-accumulation happens almost all of the time),
> perhaps this isn't much of a gain, since people who write to a Linux system
> always feel like they're writing to a RAM disk (assuming the system's been
> quiescent long enough for updated to flush its dirty buffers).
>
> Anyhow - it seems like netatalk/AppleShare could be quite a bit faster. When
> i use protocols like FTP, I get the ethernet limit all of the time to/from
> the same box (1,200,000 bytes/sec, measured against wall-clock).
>
> (By the way, I do realise many of the performance issues are in the
> Appleshare client, but from the settings I've seen in the 3.7.x and 3.8
> clients (write-behind/read-ahead, large buffers, separate cache buffers,
> etc), it seems like it really should fly.
>
> =Rob=
>
>
~~~~
Dave.Winkel@umich.edu UofM/ITD Web Services
University of Michigan Webmaster
At some point you have to accept that 99% uptime means 1% downtime.
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:33:19 EST