2

Is connection pooling still needed in a cloud native environment?

Connection pools (for example open database connections) were very popular in the past.

I guess (don't know) that in a cloud native environment they are not needed any more.

There is a pool of containers/pods. This way connection pooling is hardly needed any more.

Is this true?

guettli
  • 25,042
  • 81
  • 346
  • 663

2 Answers2

3

As always, measure, don't guess, but yes, if you care about performance you still want connection pooling in some way.

Besides the aformentioned reason (TCP 3-way handhsake) you also want connection pooling for these reasons:

  1. The database may need to fork or start a new process for each connection which may be a very costly operation
  2. Upon closing the connection the database process may have to be cleaned up by the operating system to safe memory, file descriptors, sockets etc.
  3. The database may need to validate the login credentials of the user, which in some cases could be an LDAP useraccount so another network roundtrip is involved
  4. If your connection is not a plain TCP connection but you use SSL/TLS in the worst case scenario (no session resumption possible) you may incur the overhead of a full TLS handshake, including validating RSA signatures and checking the status of the certificates through CRL or OCSP over the internet

We use this professionally and also:

  • pooling httpclients (for REST/SOAP webservices)
  • pooling connections to RabbitMQ (RabbitMQ monitors provide insight into what they call: Churn statistics, to easily see how often new connections are established)

You may also want to check out other 'cloud architecture solutions' like the: service mesh of which Istio is an implementation that try to decouple this kind of concerns from your application in a microservice architecture. These may use a local proxy server with connection pooling in the so called 'Side car pattern'. For a more complete explanation see: Red Hats explanation of a Service Mesh

JohannesB
  • 2,214
  • 1
  • 11
  • 18
1

You still need connection pooling.

Connection pooling prevents you from incurring the TCP Connection establishment overhead when you want to send, for example, an HTTP request to another service. I believe this is about two Round Trip Times (RTT) (SYN -> <- SYN-ACK -> ACK). See Connection Establishment. Network I/O is very time intensive so this can save significant time for requests.

Connection pooling is also very helpful to the underlying operating system. For example, in a Kubernetes context you may be communicating with a "Service". Kubernetes uses iptables to route traffic to services correctly. iptables uses a file called conntrack to track all of the connections that iptables is managing. This is a file with a finite size. Connection pooling can keep you from overwhelming the conntrack file. Here's a relevant blog post.

Breedly
  • 12,838
  • 13
  • 59
  • 83