2

We have a set of micro-services that I'd like to load test in a manner that is consistent with how they are accessed.

After settling on Locust as my tool of choice, I found out that the TCP connection underpinning has connection pooling because I keep seeing messages like these:

WARNING/requests.packages.urllib3.connectionpool: Connection pool is full, discarding connection:

As I understand it, this message is telling me that it discards a connection from the pool that it manages. I assume that it still creates a new connection, and adds it in the place of the one that it discarded.

  • Is that what it does?
  • Does it do this without the connection failing?

I don't think that our micro-services keep any sessions open. The connections are made, from a far end, to our services, which provide a result, and then the connection is closed. So, the test is handling the connections in a way that's different than the services are used. Is there a way to get the requests lib to not use a pool, and go through the work of setting up and tearing down all connections made through it, each time?

  • Is there any reason why we wouldn't want to test this way?
  • If it is preferable to test with a connection pool, how should I anticipate the difference in load when it's not done this way in production?
Cognitiaclaeves
  • 808
  • 10
  • 16

1 Answers1

0

That's correct. Unless you set the urllib3 pool to blocking, it will generate more connections than the pool is configured to hold, as needed, and then will discard them once the request is done.

This often happens when you have more threads using a pool than the number of connections the pool is configured to store. urllib3 takes a maxsize parameter (defaults to 1) which you can set to the number of threads you're running. For requests, you'll need to make a custom adapter to do this. See:

That said, it's merely a warning which some people ignore, so it's not a failure. But if this happens a lot in production, that probably means you should tweak your configuration because creating/discarding new connections all the time is fairly costly.

In general, it's a good idea to re-use connections for this reason.

My suggestions would be in this order:

  1. Re-use connections, or
  2. Increase the number of connections that get pooled to match the number of threads, or
  3. Disable the warning if you'd rather not deal with it.
Community
  • 1
  • 1
shazow
  • 17,147
  • 1
  • 34
  • 35