latest response-time data

Poul-Henning Kamp phk at
Tue Aug 8 08:14:19 CEST 2006

In message <1720. at>, "Anders Berg" 
>> All numbers in milliseconds.
>> 0-90%		0.028		0.052		0.039 		0.038
>> 90-99%		0.052		0.895		0.121		0.121
>> 99-100%		100		535		320		329
>> The 0-90% fractile is very stable, the other two depend a lot on
>> the backend.
>> It looks like avoiding the extensible printf shaved a microsecond
>> off those numbers.
>With numbers like these it's probably safe to say that varnish will
>probably never be the bottleneck :)

Well, _never_ is such a big word, but compared to the competition:
no, it will not.

This morning after having gobbeled up 23000 objects, varnish is a
bit slower, 45 microseconds for a hit.

That is in all likelyhood the hash-chains that has gotten longer,
with my usual faith in MD5's spectrum, they would all be around
23000/256 = 89 entries long, which is too long IMO.

The default value of 256 hash buckets may be too conservative.

Increasing the number of hash-buckets can be done, but it's a
mess: you basically have a list of hash arrays and always insert
in the top most one, but you search them all to have a miss.
Then once objects have expired from the lower levels, you can
remove those levels.

It's clearly a "would be nice to have, but not really critical"

Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

More information about the varnish-dev mailing list