1. Batch jobs with application threads that utilize most of the CPU will typically get
better performance from the throughput collector.
2. Batch jobs that do not consume all the available CPU on a machine will typically
get better performance with a concurrent collector.
GC algorithms and throughput tests
When a test measures throughput, the basic trade-offs in GC algorithms are the same as for
batch jobs, but the effect of the pauses is quite different. The overall system impact on CPU
still plays an important role.
This section uses the stock servlet as the basis for its testing; the servlet is run in a GlassFish
instance with a 2 GB heap, and the previous 10 requests are saved in each user's HTTP ses-
sion (to put more pressure on the GC system). Table 5-2 shows the throughput the test
achieves when running with the throughput and CMS collectors. In this case, the tests are run
on a machine with four CPUs.
Table 5-2. Throughput with different GC algorithms
Number of clients Throughput TPS (CPU usage)
CMS TPS (CPU usage)
Two tests are run to measure the total throughput. In the first test, a single client is emulated
by the fhb program; the second case drives the load from 10 clients so that the target-ma-
chine CPU is fully utilized.
When there are available CPU cycles, CMS performs better here, yielding 5% more TPS
than the throughput collector. The throughput collector in this test had 24 full GC pauses dur-
ing which it could not process requests; those pauses were about 5% of the total steady-state
time of the test. By avoiding those pauses, CMS provided better throughput.