F5 and a pool of webservers - what settings/algorithm to use

There are a few things to consider - to be honest I don't think you need to mess with the TCP settings on the BigIP here. It's much more likely related to your actual workload, config, and monitoring setup - at least that's my gut feeling.

 

 

1) If request concurrency is an issue you may consider your monitoring strategy - remember that the monitor requests themselves can exacerbate situations where the server is struggling to keep up, especially in I/O bound situations like this. One thing I'd suggest is putting an explicit close header in the monitor GET string, i.e. GET HTTP/1.1 \r\n Connection: close \r\n, which will hopefully help free up a few threads for requests. I don't know if this will help you, but it's definitely worth doing. Also, pull back that interval to something less aggressive and it'll help free things up a bit.

 

 

2) Consider using oneconnect with a /32 mask. This will help with your top-end thread counts.

 

3) Consider using passive monitors, with a fallback (requires v10 or higher though).

 

4) Pool level connection limits, as suggested above.

 

 

Here's the trick with least connections in a situation like this: you've described a scenario where each web server has roughly the same number of connections, and all (or most) of them are in some I/O bound connection state. In this situation, which server should the algorithm choose from a connection count standpoint, if they're all essentially the same? It sounds like this isn't the ideal LB method for this use case. Maybe look into fastest, observed, etc.

 

 

At the end of the day though, this is a problem that will probably need to be solved with the architecture itself, as opposed to BigIP. BigIP will help you deal with the situation extremely intelligently, but it can't ultimately solve it. You point out that adding more threads will exacerbate the situation on the DB or the cache bottleneck, etc. so adding servers won't help either. Ultimately you'll need to figure out how to architect for this:

 

 

-- Move static stuff off of the back end (think about enabling caching on BigIP). This frees up some resources.

 

-- Fix the I/O constraints behind the servers, if at all possible (read-only DB caches, memory stashing ala memcached, etc.)

 

-- Move to an non blocking async I/O model if possible. This means a thread won't block until a response is written back out to it. In a situation like this a queue would be helpful.

 

 

Just some suggestions, which may or may not make sense or be feasible in your environment :)

 

 

--Matt Cauthorn