Then add a safety factor of 10% for example (emphasised, since other posters seem to take my examples as fixed recommendations). What you should measure specifically is the maximum amount of threads in concurrent use (e.g., waiting on a return from the DB call) under load. In response to the "what exactly should I measure?" question: If, for some reason, your usage goes to 100% of available for a significant time (so that it would affect the performance of clients), you should bump up the maximum allowed until it's once again B% higher. You should also be monitoring for behaviour changes. The maximum number of threads should be your historical maximum + B%. The minimum you should have running is the minimum number that you've ever had running + A%, with an absolute minimum of (for example, and make it configurable just like A) 5. Then, the number of threads you should have depend on your historical use. This may be a hard limit unless you can increase it at the DBMS - I'm going to assume your DBMS can take an unlimited number of connections in this case (although you should ideally be measuring that as well). The first is the number of DB connections available. There are two factors that affect how many threads you should allow for. As you state, the vast majority of your threads will be waiting for a response from the database so they won't be running. (B) will generally be a delay in the processing of requests as they arrive as you need to wait for a thread to become available. (A) is generally memory usage (stacks and so on) since a thread doing no work will not be using much of the CPU. You need to balance the resource usage of having unused threads (A) against the resource usage of not having enough threads to do the work (B). The third returns you to the baseline in quiet times so as to minimise resource use. The second sets a restriction on resource usage by active threads. The first sets a baseline for minimum performance in terms of the thread pool client (this number of threads is always available for use). shutting down threads that haven't been used for a while.I've written thread and database connection pooling code and they have the following features (which I believe are essential for performance): But, since you were asking about a good cut-off point for threads, I assume your thread pool implementation has the ability to limit the maximum number of threads created (which is a good thing). I'm not advocating rolling your own thread pooling subsystem, by all means use the one you have. You could actually have your code itself monitor usage and adjust the configuration for the next time it starts but that's probably overkill. If it remains at 100 for most of the day, bump it up to 200 and see what happens. If your thread usage peaks at 3, then 100 is too much. One suggestion is to make it configurable and initially set it to 100, then release your software to the wild and monitor what happens. Some people would say that two threads is too many - I'm not quite in that camp :-)
0 Comments
Leave a Reply. |