latest response-time data
phk at phk.freebsd.dk
Tue Aug 8 08:14:19 CEST 2006
In message <17184.108.40.206.4.1154987528.squirrel at denise.vg.no>, "Anders Berg"
>> All numbers in milliseconds.
>> FRACTILE MIN MAX AVG MEDIAN
>> 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