> A few simple tests have shown that with alternative file systems
> we have done a great deal better. Profiling the machine while runing with
> UFS shows the thrashing that occurs in the file system. As we have said
> before a custom file system will allow us to remove the major bottleneck
> from Squid. Which will then start showing where Squid is inefficient and
> other UNIX issues that are slowing us down. At the moment Duane is working
> on SquidFS and when he has the time to get that finished we should start
> being able to make squid much faster.
Is there info about SquidFS on the web anywhere? A few days ago somebody
said the issue had beed discussed heavily on squid-dev, but I can't find
an archive of that anywhere.
>
> People should remember that at the rates that squid exibited at
> the Bake-Off it would quite happily service 5MB/Sec. Which is more than
> enough for most Squid users.
5MB/s is about half a 100-base-T LAN, and a little less than two E3's...
guess it's more than enough for most uses, including mine... :-) And one
can always gang two or three or more machines together.
I think he might have meant 5Mb/s (megabits, not megabytes). Assuming
squid performance to be 100 objects/s (bakeoff was 96 max if I recall),
5Mb/s / (100 objects/s) * 1B/8b = 6KB/object
which sounds reasonable. Note that this is 6KB per object *served*,
not per unique object on disk.
gid
