Varnish use for purely binary files

[Poul-Henning Kamp]

In message <97F066DD-4044-46A7-B3E1-34CE928E81F3 at slide.com>, Ken Brownfield wri
tes:

>Ironically and IMHO, one of the barriers to Varnish scalability
>is its thread model, though this problem strikes in the thousands
>of connections.

It's only a matter of work to pool slow clients in Varnish into
eventdriven writer clusters, but so far I have not seen a
credible argument for doing it.

A thread is pretty cheap to have around if it doesn't do anything,
and the varnish threads typically do not do anything during the
delivery-phase:  They are stuck in the kernel in a writev(2) 
or sendfile(2) system call.

In terms of machine resources, there is no cheaper way to do it.

An important but not often spotted advantage is that the object
overhead does not depend on the size of the object:  a 1
megabyte object takes exactly as few resources as a 1 byte object.

If you change to an eventdriven model, you will have many more
system-calls, scaling O(n) with object sizes, and you will
get a lot more locking in the kernel, resulting in contention
on fd's and pcbs.

At the higher level, you will have threads getting overwhelmed
if/when we misestimate the amount of bandwidth they have to deal
with, and you will need complicated code to mitigate this.

For 32bit machines, having thousands of threads is an issue, because
you run ou of address-space, but on a 64bit system, having 1000
threads or even 10k threads is not really an issue.

Again: Don't let the fact that people have doen this simple datamoving
job wrong in the past, mislead you think it cannot be done right.

The trick to getting high performance, is not doing work you don't
need to do, no architecture or performance trick can eve beat that.

Poul-Henning

-- 
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.