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:

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 (

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.

Published May 07, 2020
Version 1.0

Was this article helpful?

No CommentsBe the first to comment