O'Reilly - Java Message Service

Java Message Service
• The amount of data to be processed through the messaging system over a given
period of time. This can be measured in messages per second, bytes per second,
messages per month, etc.
• The typical size of the messages being processed. Performance data will vary
depending on the message size.
• Any atypical message sizes being produced. If 90% of the messages being
processed through the system are 100 bytes in size, and the other 10% are 10
megabytes, it would be important to know how well the system can handle either
scenario.
• The messaging domain to be used, and how it will be used. Does the entire
application use one p2p queue? Are there many queues? Is it pub/sub with 1,000
topics? One-to-many, many-to-one, or many-to-many?
• The message delivery modes to be used. Persistent? Nonpersistent? Durable
subscribers? Transacted messages? A mixture? What is the mixture?
7.1.2 Testing the Real-World Scenario
Any vendor can make any software product run faster, provided the company has the right
amount of time, proper staffing, commitment, and enough hardware to analyze and test a
real-world deployment environment.
The simplest scenario for a vendor to optimize is the fastest performance throughput
possible with one or two clients connected. This is also the easiest scenario to test, but is
not the kind of testing we recommend; for one thing, it's difficult to imagine a realistic
application that only has one or two clients. More complex testing scenarios that better
match your system's real-world environment are preferable.
It is important to know ahead of time if the vendor you have chosen will support the
requirements of your application when it is deployed. Because JMS is a standard, you may
switch JMS vendors at any time. However, you may soon find yourself building vendorspecific
extensions and configurations into your application. It's always possible to change
vendors, if you're willing to expend some effort. However, if you wait to find out whether
or not your application scales, you may no longer be able to afford the time to switch to
another vendor.
This is not intended to imply that using JMS is a risky proposition. These same issues
apply to any distributed infrastructure, whether third-party or home-grown, whether it is
based on a MOM or based on CORBA, COM, EJB, or RMI, and whether it is based on an
established vendor or an emerging one. Everything should be sized and tested prior to
deployment.
7.1.2.1 Testing with one client
The most important thing to realize is this:
performanceWithOneClient != performanceWithManyClients;
Many issues come into play once a message server starts to scale up to a large number of
clients. New bottlenecks appear under heavy load that would never have occurred
otherwise. Examples include thread contention, overuse of object allocation, garbage
collection, and overflow of shared internal buffers and queues.
109