Re: [squid-users] low squid throughput/scalability

I did some test http_load and it maxed out my card, getting about
700req/sec! thx for all your help!

mike

At 04:40 PM 3/11/2006, Henrik Nordstrom wrote:
>lör 2006-03-11 klockan 13:46 -0800 skrev Mike Leong:
>
> > I get 100mbps speed if I scp a large file from server ->
> > client. Definitely not cabling/nic issues.
>
>Best test it with netperf in bidirectional mode just to be sure..
>
>
>In my unscientific tests using httperf hitting a single 20KByte object
>on A 1GHz PIII laptop with e100 mini-pci nic with one request per
>connection (no keep-alive):
>
>
>concurrency replies/s responsetime bandwidth
>
>memory:
>20 485 10,6/23,1 9,8 MByte/s
>100 561 62,2/92,2 11,5 MByte/s
>400 556 209,3/412,0 11,4 Mbyte/s
>1000 546 629,9/848,5 11,1 Mbyte/s
>
>ufs:
>20 478 11,4/23,6 9,6 MByte/s
>400 530 238,7/425,4 11,0 MByte/s
>1000 509 727,9/947,1 10,5 MByte/s
>
>aufs:
>20 442 13,3/27,2 9,0 MByte/s
>400 545 228,9/409,3 11,4 MByte/s
>1000 530 690,1/759,4 11,0 MByte/s
>
>
>bandwidth measured at the packet level, counting the number of octets in
>each ethernet frame received.
>
>response time is in milliseconds, with the first number being the time
>until httperf had received the response header and the second the
>complete transfer time.
>
>
>As long as the dataset fits in memory numbers should be pretty much
>constant no matter how many objects is involved.
>
>
>Note: I have no explanation to why the aufs numbers is slightly better
>than ufs in the above tests. Did seriously expect the opposite as aufs
>by it's async design adds a bit of CPU and latency overhead compared to
>ufs and should not be faster on hot objects.. (hot == already in the OS
>maintained filesystem buffer/cache)
>
>The station running httperf is a Athlon 64 4200+ if anyone wonders.
>
>Regards
>Henrik
>
Received on Sat Mar 11 2006 - 22:23:11 MST