Messages in this thread | | | Subject | Re: Thread implementations... | From | "Michael O'Reilly" <> | Date | 26 Jun 1998 14:11:26 +0800 |
| |
Rik van Riel <H.H.vanRiel@phys.uu.nl> writes: > On Thu, 25 Jun 1998, Amsden, Zachary wrote: > > > Possibly. But according to Squid's own doc, the primary problems > > in Squid performance are > > > > 1) Not enough memory > > Can indeed be alleviated by sendfile()...
No. The memory issue on squid is almost purely to do with needing to keep a very large dbase (the index for all the disks) in ram.
> > 2) Too slow disks >
> With a filesystem that can't handle the extreme dir sizes > that Squid uses.
Squid doesn't produce extreme dir sizes. No dir will have more then X files for a given configuration.
> ReiserFS or another advanced filesystem > will speed up this bottleneck by more than just a considerable > amount...
The disk issue in squid is purely driven by transaction times.
> > which as far as I can see aren't helped by sendfile. They also > > say "CPU limitations are rarely encountered except in very large > > caches". > > This situation is also better handled by tree-based filesystems > and better buffer/cache administration.
On squid 1.2, large squids are CPU bound, and the number two CPU sucker is read()s and write()s to network sockets. (squid does a LOT of copying data from network to network, and disk to network).
Michael.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |