CODEWITHSUNDEEP
google-app-engineload-balancinggoogle-compute-enginegoogle-cloud-endpointsgoogle-cloud-platform
user2618324
user2618324

Reputation: 111

Google Cloud LoadBalancer is unable to map tcp connection between client and LB with tcp connection between LB and backed instance

I am seeing an issue during performance testing of our application. The issue is LoadBalancer is unable to map tcp connection between client and LB with tcp connection between LB and backed instance.

When a client sends a http request first time, LB opens a new TCP connection with backed instance but when same client sends another http request then also LB creates a new TCP connection with backend instance. When we execute the same scenario directly sending requests from client to backend instance, same tcp connection is reused.

We have a limit on open TCP connections per process at backed instance so we want to know following.

  1. Why LB uses an ip range when sending requests to backed servers and where it is configured ?

  2. How LB maps clients TCP connections with backend TCP connections ? If there is no mapping then what is the limit of open tcp connections imposed by LB.

  3. What is the response code returned by LB in case of connection reset by backed instance ?

  4. What is the response code returned by LB in case of backed server’s SYN backlog queue is full.

Upvotes: 1

Views: 758

Answers (1)

Antonio Vicente
Antonio Vicente

Reputation: 86

  1. Client requests are processed by a collection of load balancers, which is why you will see changes to the direct connected host when processing a stream of requests from a client.

  2. Traffic from a client IP will be processed by a subset of the global load balancer pool, but from the sound of your question even this subset ends up being effectively too large to result in high backend TCP connection reuse. There are some hidden parameters of the load balancer that affect the number of connections created to the backends and circumstances where the load balancer can use existing connections to handle new requests. These internal parameters may change in the future in order to reduce the number of TCP connections required between the load balancer and backends. Until then, allowing more connections at the backend and more generous timeouts on those connections should increase backend connection reuse.

Turning on session affinity by client ip or generated cookie will result in the LB using a specific backend when handling traffic from a client, but you will still see traffic arriving from multiple LB IPs. In the absence of session affinity there is effectively no mapping between client ips and backend VMs used. For instructions on how to enable session affinity see: https://cloud.google.com/compute/docs/load-balancing/http/#session_affinity

  1. The LB will reply with a 502 response code if it is not able to get a response from a backend.

  2. The load balancer will consider the backend as unhealthy and direct traffic to other available healthy backends. If there are no healthy backends, the load balancer will reply with 502 after a timeout.

Upvotes: 2

Related Questions