How OneConnect Profile's max-size works
1. Preliminary Information
This setting controls the maximum number of idle server-side TCP connections that BIG-IP holds in the connection reuse pool split per tmm, i.e. if BIG-IP has 2 tmms setting max-size to 2 gives each tmm 1 idle connection. If HTTP requests reach the same TMM, then max-size of 1 and 2 will have the same effect in practice.
This is a quick walk through to show how OneConnect max-size works. For more general overview and description of each profile option individually please refer to one of the following resources:
- What is HTTP Part VII - OneConnect
- How OneConnect with Cookie Persistence works
- K7208: Overview of the OneConnect profile
- K2055: The BIG-IP system may not load balance traffic evenly when OneConnect is in use
- K85357500: Managing connection reuse using OneConnect source mask (12.x)
Think of this article as a quick lab test so we can quickly understand what oneconnect max-size is along with corresponding tmsh show command output
2. Lab Scenario
My BIG-IP (VE) box has 2 tmms:
I've set max-size to 2 and left everything else with default settings (setting to 1 would have the same effect)::
This roughly makes max-size = 1 per tmm.
We can now play with 'show' commands and understand a bit more about OneConnect using fewer requests.
This is the scenario:
I added the following iRule to the virtual server to make it simple and confirm whether connection has been re-used or not:
3. Lab test results
- BIG-IP adds eligible connections to OneConnect reuse pool
- max-size value set is split per tmm
- If max-size has been reached in a given tmm, new eligible connection is not added to connection reuse pool
- In such case, such connection is closed (FIN/ACK) when we receive another request that could potentially reuse it and BIG-IP creates a new one
Note: In this lab test I am using Current Idle output from tmsh show ltm profile one-connect as a reference to understand connection reuse pool because it is a controlled environment and this is the only kind of traffic BIG-IP is receiving. However, Current Idle actually shows current number of any idle server-side connection, even if it is not in connection reuse pool, i.e. either not eligible because of source-mask configuration or because it hasn't been claimed to be reused yet for the first time.
4. Explanation of show command output
Current Idle: number of current idle server-side connections regardless if it is eligible or not to be reused
Maximum: number of maximum concurrent connections a single tmm has ever handled
Total Reuses: Goes up when any idle connection is reused
New: Goes up when BIG-IP establishes any new connection server-side
5. Lab test details
I sent first HTTP requests via curl from client (10.199.3.135):
And it goes to Server1:
At this moment, server side connection is immediately added to connection reuse pool (Current Idle):
I then send 2nd request and it goes to Server2:
Because max-size is set to 1 then there is no room for another eligible idle connection and old connection is closed to give room to a new connection.
This explains why New counters increases to 2 (since this is the 2nd new connection this profile handled since the counter started) and Current Idle remains at 1 (because max-size only allows 1 idle connection server-side, remember?):
3rd request comes in and round-robin method determines it should go to Server1 but as there is an idle connection in connection reuse pool this time BIG-IP reuses it (notice port 38742 is the same port):
And fair enough Total Reuses go up:
4th request to Server2 also creates a new connection that is also closed because connection reuse pool still contains Server1 connection entry:
New entry increases again as it is a new server-side connection but Current Idle (connection reuse pool) does not:
I have now set max-size to 4 and that gives 2 max entires per tmm and now I see connection being reused once for both pool members because BIG-IP now can leave up to 2 idle connections open:
The 'tmsh show ltm profile oneconnect myoneconnect' output reflects that:
Because the same tmm instance (tmm0) handles all the requests, a max-size of 4 gives tmm0 2 spots for idle connections which also explains why a 2nd new connection is never added to Connection Reuse pool and Current Idle didn't go above 2.