----- Original Message ----- From: "Ian C. Sison" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, February 21, 2003 7:44 PM Subject: Re: [plug] (no subject)
> > squid is a single thread and single process therefore it cant take advantage > > on smp environment, its main bottleneck is on the disk i/o... squid > > performs very well if you spread your cache on multiple disks or on a > > single cache under raid 0 environment... > > > > Using diskd and asyncio squid can take advantage of SMP. yup im fully aware of diskd (an external process) and aufs (using posix-threads) as squid's disk i/o managers but smp can take just a little advantage of it... but the main program or the squid program is just a single thread and single process... i discussed this on squid mailing list before that the squid developers keep on saying that in order for squid to improve its request per second throughput, it must improve its disk i/o system.... they created diskd and aufs but still, squid cant increase its request per second throughput greater than 200.... actually the real bottleneck of squid is on the main program design logic... everything is under select() or poll() system call... as load increases, for example, more incoming connections, more connections to read() and more connections to write(), squid's design logic processes every connection one at time because of select() or poll() functions... therefore this doesnt scale very well when load increases... thats the reason why squid cant go higher greater than 200 request per second... furthermore, actual transfer rate throughput of squid is very low at around 7 megabytes per second .....i propose to them to make squid a multi-threaded process... meaning one thread for every sub-system... for example, one thread for incoming connections, another thread for read connections, another thread for write connections, etc... so that if there is one sub-system blocks, the other sub-system continues to process.... with this it will scale very well on heavy loads compare to the current design logic of squid, if one sub-system blocks, all sub-systems wait for it in which majority of blocking is on the disk i/o sub-system.... joe cooper from swell technology asked me if im willing to volunteer to redesign squid but unfortunately i told him i will if i have the time to do it.... > I've run squid > on a dual P3 with squid on aio, on reiserfs, mounted with notail/noatime > and it flies! aside from notail and noatime, squid performs very well under the raid 0 environment versus spreading its caches across multiple disks.... furthermore, based on my benchmark and other people's benchmark, squid performs very well if it runs under freebsd... a big plus and big improvement if you used freebsd's inode filesystem (IFS) inode filesystem is a filesystem that doesnt used namespace... having to maintain the directory structures means wasting a lot of disk i/o and/or memory... since most applications these days have their own database containing object to ufs namespace mapping, IFS can effectively bypass namespace together and talk instead to just inodes.... here is the link of joe's benchmark using different filesystem under linux which the throughput is very low http://swelltech.com/pengies/joe/benchmarks.html fooler. _ Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph To leave: send "unsubscribe" in the body to [EMAIL PROTECTED] Fully Searchable Archives With Friendly Web Interface at http://marc.free.net.ph To subscribe to the Linux Newbies' List: send "subscribe" in the body to [EMAIL PROTECTED]
