Forum Discussion
CirrostratusLoad Balancing Not Happening for Pool Members of a Performance Layer VIP
EmployeeYou have a Fast-L4 virtual. This is TCP connection oriented, so there is only one load-balancing decision made per TCP connection.
As per your screenshot of the back-end service, it allows long-lived TCP connections that will accept multiple HTTP requests on that single connection.
If you disable that option, then the TCP connection is closed after each HTTP request, and you get your expected request distribution.
If you want per-Request distribution, then you need a Standard Virtual (not Fast-L4) with an HTTP profile and a OneConnect profile to ensure per-Request load-balancing decisions.
SubrunScreenshot you see I attached , if that Yellow Marked Option is selected then I see connections are distributed within backend servers. If that option is not selected I see 1 single connection ( TCP Connection ) to Only 1 node. Screenshot says HTTP Connection I am not sure if that means TCP Connection or HTTP Connection. Confused actually.
Assuming in the screenshot it meant TCP Connection , how does that work for HTTP Traffic once TCP Connection is closed. Sorry for my knowledge limitation.
- Simon_Blakely
HTTP request/responses are (currently) passed over a TCP connection.
A HTTP client (browser) can open a TCP connection, send an HTTP request, wait for the HTTP response, and then close the TCP connection.
More commonly, the HTTP client will open a TCP connection, send an HTTP request, wait for the HTTP response, send another HTTP request, wait for the HTTP response, and then eventually close the TCP connection. This is called HTTP Keep-alive or HTTP persistent connection.
The highlighted SoapUI option Close connection after request is actually referring to closing the TCP connection after the HTTP response, disabling HTTP persistent connection.
- Subrun
Hello,
Can you explain why do we need One Connect Profile ? in this situation ?
- Simon_Blakely
A OneConnect profile works with the HTTP profile, and when there is an HTTP Request/Response, it detaches the server-side connection from the client-side connection. Then, when the client makes a new HTTP Request, there is a new load-balancing decision for a pool member. If a pool member is selected that already has a server-side connection, that connection is reused, otherwise a new server-side connection is created.
This is not only more efficient, but is ensures that each HTTP Request has a load-balancing decision - without the One-Connect profile (or an irule that does a LB::detach on HTTP_RESPONSE) then there will still only be a load-balancing decision on the first request.
- Subrun
For my scenario , If I create a Standard Virtual Server ( Not L4 ) and do not create a One Connect Profile , it does not load balance the traffic ? Just to give an idea regarding client there are 3/4 clients will be making thousands of connections to this VIP.
Reason I ask is trying to clear the justification to create a Standard Virtual Sever with and Without OneConnect Profile based on my scenario.
- Simon_Blakely
> For my scenario , If I create a Standard Virtual Server ( Not L4 ) and do not create a One Connect Profile , it does not load balance the traffic ? Just to give an idea regarding client there are 3/4 clients will be making thousands of connections to this VIP.
You have to distinguish between connections and requests - the Standard Virtual Server will load-balance connections, but not requests.
The One-Connect profile in conjunction with an HTTP Profile will load-balance requests.
