Lighttpd

Many web applications achieve a significant boost in speed by caching data, such as user session info. To take maximum advantage of caching on the backend, many commercial load balancers have an optional 'sticky' flag which causes connections coming from the same outside ip to forward to the same backend server. By going to the same backend server, there is an improved chance that the backend server will have cached data capable of greatly improving response time.

Applying that same concept to FastCGI, significant speed gains could be made in situations when the backend process is written to cache user data. Sending the same browser to the same backend FastCGI process, as opposed to just the 'least busy' one at the top of the list may actually give better much performance in the (common) case where the backend process is slow on new connections but fast on repeat connections because of internal caching. It would be nice if Lighty's FastCGI load balancing feature had a sticky flag that could be used to implement this.

Determining which backend process to send to could be done simply by client ip at first, but would be best if augmented with a session cookie or some other session/auth tracking system at the web server level, think along the lines of Apache's mod_usertrack. (Actually this would probably be just the tip of the iceberg of what could be done by combining mod_auth with mod_usertrack.)

-- mdepot