Java Reference
In-Depth Information
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
program)?
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
20% busy.
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
1
0.05 seconds
100%
2
0.05 seconds
100%
4
0.05 seconds
100%
6
0.076 seconds
152%
8
0.104 seconds
208%
16
0.212 seconds
424%
32
0.437 seconds
874%
64
0.909 seconds
1818%
Search WWH ::




Custom Search