问题
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?
回答1:
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:
- The database may need to fork or start a new process for each connection which may be a very costly operation
- Upon closing the connection the database process may have to be cleaned up by the operating system to safe memory, file descriptors, sockets etc.
- 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
- 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
回答2:
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.
来源：https://stackoverflow.com/questions/60578173/connection-pooling-in-cloud-native-environment