In message <[email protected]>, 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 [email protected] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ varnish-misc mailing list [email protected] http://projects.linpro.no/mailman/listinfo/varnish-misc
