Java Reference
In-Depth Information
Once the application server is the bottleneck in this example (i.e., at four client threads),
adding load into the server is quite harmful—even by adding just a few threads on the client
side.
This example may seem somewhat contrived. Who would add more client threads when the
server is already CPU-bound? But the reason I've used this example is simply because it is
easy to understand and uses only Java programs. That means you can run it yourself to un-
derstand how it works, without having to set up database connections and schemas and what-
not.
The point is that the same principle holds here for an application server that is sending data-
base requests to machine that is CPU- or I/O-bound. You might look only at the application
server CPU, see that is it well below 100% and that it has additional requests to process, and
assume that increasing the number of application server threads is a good idea. That would
lead to a big surprise, because increasing the number of threads in that situation will actually
decrease the total throughput (and possibly quite significantly), just as it did in the Java-only
example.
This is another reason why it is quite important to know where the actual bottleneck in a sys-
tem is: if load is increased into the bottleneck, performance will decrease significantly. Con-
versely, if load into the current bottleneck is reduced, performance will likely increase.
This is also why self-tuning of thread pools is quite difficult. Thread pools usually have some
visibility into the amount of work that they have pending, and perhaps even how much CPU
the machine has available—but they usually have no visibility into other aspects of the entire
environment in which they are executing. Hence, adding threads when work is pending—a
key feature of many self-tuning thread pools (as well as certain configurations of the
ThreadPoolExecutor )—is often exactly the wrong thing to do.
Unfortunately, this is also why setting the maximum size of a thread pool is often more art
than science. In the real world, a self-tuning thread pool may get you 80% to 90% of the pos-
sible performance of the system under test, and overestimating the number of threads needed
in a pool may exact only a small penalty. But when things go wrong with this sizing, they
can go wrong in a very big way. Adequate testing in this regard is, unfortunately, still a key
requirement.
Search WWH ::




Custom Search