O'Reilly - Java Message Service

Java Message Service
provider for a given class of machine and eliminate the possibility of having exceeded the
limits of your hardware.
If the CPU or memory utilization does not approach its maximum, and the message
throughput does not continue to improve as you add clients, then the bottleneck is probably
disk I/O or network throughput. Disk I/O is most likely to be the bottleneck if you are
using persistent messaging.
7.1.2.4 Finding or building a test bed
Building a test bed suitable for simulating a proper deployment environment itself can be a
moderately sized effort. Most JMS vendors provide a performance test environment freely
downloadable from their web site. In most cases, they provide a test bed sufficient for
testing with one client. [1]
[1] As of publication, SonicMQ is the only vendor providing a multiclient test bed.
7.1.2.5 Long duration reliability
Testing your application over a long period of time is very important. After all, it is
expected to perform continuously once deployed. Verifying that the middleware behaves
reliably is the first step toward ensuring long-term application reliability.
Once you have a multi-client test bed in place, try running it for an extended period of time
to ensure that the performance throughput is consistent. Start out by running the test bed
while you can be there to monitor the behavior. Any long-term trends are likely to be
detected in the first few hours. Things to watch for are drops in performance throughput,
increase in memory usage, CPU usage, and disk usage. When you feel comfortable with
the results you see, you may progressively start running tests overnight, over the weekend,
or over a week.
7.1.2.6 Memory leaks
The term "memory leak" refers to a condition that can happen when new memory gets
allocated and never freed over a period of time, usually through a repeated operation, such
as repeatedly pumping messages through a messaging system. Eventually, the system runs
out of available memory; as a result, it will perform badly and may eventually crash.
Although Java has built-in memory management through garbage collection, it is an
oversimplification to think that garbage collection permanently solves the problem of
memory links. Garbage collection works effectively only when the developer follows
explicit rules for the scoping of Java objects. A Java object can be garbage collected only
if it has gone out of scope and there are no other objects currently referencing it. Even the
best code can contain memory leaks, if the developer has mistakenly overlooked an object
reference in a collection class that never goes out of scope.
Therefore, you need to monitor for memory leaks during testing. Memory that leaks in
small increments may be not be noticable at first, but eventually these leaks could
seriously impact performance. To detect them quickly, it helps to use a memory leak
detection tool like OptimizeIt! or Jprobe. Even if the JMS provider and other third-party
Java products you are using contain obfuscated classes, tools like these still help you prove
111