When that is the case, adding threads to the thread pool is quite detrimental. Although I said
(only somewhat tongue-in-cheek) in Chapter 1 that the database is always the bottleneck, the
bottleneck can be any external resource.
As an example, consider the stock servlet with the roles reversed: what if the goal is to make
optimal use of the load generator machine (which, after all, is simply running a threaded Java
In typical usage, if the servlet application is run in an application server with four CPUs and
has only a single client requesting data, then the application server will be about 25% busy,
and the client machine will be almost idle. If the load is increased to four concurrent clients,
then the application server will be 100% busy, and the client machine will be perhaps only
Looking only at the client, it is easy to conclude that because the client has a lot of excess
CPU, it should be possible to add more threads to the client and improve its scaling.
Table 9-3 shows how wrong that assumption is: when additional threads are added into the
client, performance is drastically affected.
Table 9-3. Average response time for calculating mock stock price histories
Number of client threads Average response time Percent of baseline