1

Is there something as a common sense accepted ratio between the

  • HTTP Connector maxThreads (max HTTP threads handling the users requests),
  • HTTP Connector acceptCount (max queue length for incoming connection requests when all possible request processing threads are in use)
  • DB pool maxActive (max DB connections in the pool) configuration properties

when it comes to a web base application using tomcat with heavy usage of the database ?

What I mean is that for example we have almost each HTTP request connection is using the database intensively. So, when we have, f.e., much less configured DP pool maxActive (e.g. 100) while the HTTP Connector maxThreads (e.g. 200) is twice bigger. Then there could be a possibility to have one and same DB connection to be shared between the HTTP connections. And that could leads to heavy DB usage / DB stalls connections.

I am aware that web HTTP requests configuration in most of the cases has no relation with the database pool configuration, but are there common cases/practices for a ratio between the properties (maxThreads/acceptCount maxActive) ? E.g. is a common practice the HTTP maxThreads to be larger than the DB maxActive (but thinking 100% larger is too much as per our example - could be let's say 20 or 50% max larger? ) and let's say we have accpetCount with a bigger value, so to queue the HTTP requests by the time the others HTTP requests are processed by the application ?

There is similar question here: Tomcat - Configuring maxThreads and acceptCount in Http connector but with no more precise answer to it

Simeon Angelov
  • 470
  • 4
  • 18

1 Answers1

1

First, a few clarifications:

  • JDBC connections are not shared between threads to avoid breaking the isolation requirement. If the pool is exhausted the request will wait in a queue until a connections is assigned or a timeout occurs.
  • Requests are served as they arrive up to maxThreads value, any additional requests are placed in a queue up to acceptCount value.

acceptCount: The maximum queue length for incoming connection requests when all possible request processing threads are in use.

  • maxActive is the bottleneck in your example so requests beyond that number will be waiting for a db connection. More precisely, the bottleneck is on the db connection pool.You won't get stalled db connections but rather threads waiting for a connection from the pool.

That said, there's not much value on finding a ratio between those values since maxActive will impose the limit. maxThreads >= maxActive is the obvious rule of thumb.

maxThreads will never be reached unless your application load says so but then your database pool should be able to cope with that load or your app will fail.

Tuning performance in this case is more about adjusting database connections pool and thread pool dynamics than setting limits. Once limits are reached there's not much to do, either find the code causing the slowness or scaling up.

Pool dynamics refers to minimum idle conn/threads, how long are kept idle, how many new entries in the pool are created at once, etc.

Hope this helps!

Tomcat 7 HTTP connector docs.

LMC
  • 10,453
  • 2
  • 27
  • 52
  • Thank you Luis for your descriptive response. Following your opinion, in order to avoid http threads to wait for a DB connection (we are assuming the users http requests are using intensively the DB) maybe is worth to make both values maxActive and maxThreads more similar in a meaning the value of maxThreads to be not much more bigger than the value of maxActive, as we could face in that case some frontend stall connections (as the frontend http threads will wait for an available db connection) ? E.g. maxActive=100 and maxThreads=130 or similar - but not double/triple the number of maxThreads – Simeon Angelov Nov 07 '18 at 10:55
  • maxThreads=200 by default, why not leaving it as is? Lowering the value will not improve performance. On the other hand, stalled connections are probably caused by the app not answering on time. Perhaps maxActive=100 is not enough for your workload. Performance tuning is about finding bottlenecks and fixing them rather than setting limits. – LMC Nov 07 '18 at 12:34
  • 1
    yeah, but in our case the http threads are waiting for a db connection from the pool, when the db pool is full -all db connections are being used by the other http threads. Making both properties with similar values could potentially avoid stall connections, and scaling up horizontally the application itself - the number of instances.Unfortunately, increasing the number of the db connections per instance will constraint on the other side the DB-limits of DB connections to the DB instance.At the end is a combination of H scale up/maxThreads/maxActive - diff perf tests will show best combination – Simeon Angelov Nov 08 '18 at 13:19
  • So If I need a jdbc connection for any http request setting maxThreads == maxActive is good ? And if I have some other threads (cron or whatever) may be maxThreads < maxActive of 5 connections ? I think that default conf is in other way because of static file requests that no need jdbc usually. – Mr_Thorynque Jan 13 '21 at 10:41
  • maxActive should follow what maxThreads dictates in some way and that depends on http requests load. Both should accommodate to serve the max stable load on your application plus some reasonable overhead. `maxThreads < maxActive` is not a usual case I guess, jdbc pool could be oversized in that case. – LMC Jan 13 '21 at 20:04