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

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