"High performance" is what everybody strives for when putting together a new system. Technical folk often spend hours hung up on the raw speed of their code, and a certain machismo can be derived from shaving milliseconds off that pesky transaction that is the latest pride and joy. Often, this time is not very well spent.

In the pursuit of raw speed, not only does readable code often get substituted for the obscure (usually to no avail - optimizing compilers are pretty good these days), thus causing a maintenance headache in the future, but in many cases the performance metric being optimized is a pretty uninteresting one in the overall scheme of things. Many people develop a blinkered focus on the amount of time it takes for one request to do a round-trip - "That debit transaction just took 20ms to debit £500 from a savings account, whoopee!!"

For a transactional system, the throughput of the system is generally far more interesting than the absolute speed of a request (although, that said, there is mostly some constraint that must be met around the time it takes to execute transactions). Throughput is a measure of the amount of work that can be driven through the system while achieving the targets for response time. More work, of course, is partly driven by more clients requesting transactions in the system. The bonus amusement factor here is that the response time and the number of clients are not independent variables - the more clients throwing work at the system, the more likely it becomes that the individual transactions will take longer. Thus, the maximum throughput of a system governs (for a given deployment environment) how many clients can throw transactions into the system at some desired rate, keeping the response time of some fraction of the transactions (say, 90 percent) within the required limit. Having arrived at this conclusion, hours of fun ensue changing various system parameters (number of execute threads, number of database connections, number of machines, etc.) in attempting to predict what the production setup needs to look like to meet the required service levels and to optimize use of server resources.

In fact, it should not be at all surprising to anyone who is using an application server that the individual round-trip time of a single transaction is of little interest. Clearly, the way to optimize that is to have as short a code path as possible between the client and the back end it affects - sticking layers of application server infrastructure between the client and the back end is clearly not going to shorten the codepath. It does, however, improve the throughput. It does this mainly by sharing scarce server-side resources (database connections, threads, etc.) among the population of clients. With the simple-minded short codepath route to performance, you will end up with a one-to-one relationship between the number of clients and the resources consumed on the server, and once all the server's resources are consumed, you have reached a performance bottleneck and the throughput can be increased no further until you can scrape together some more resources to share out. What the application server is doing in effect is economizing the number of resources consumed on the server side by sharing them out among a population of clients (at the expense of a longer codepath, implying marginally increased transaction round-trip time), thereby increasing the maximum possible throughput of the system. At this point, everyone's favorite knee-jerk reaction: "I don't use transactions, they slow things down" can be usefully reviewed.

By now we have seen a system rushing as many requests as possible through a limited set of server resources. It goes without saying that all of these requests must achieve the correct results - that is, the result of any one of the requests executing on its own should be the same if the request is executed in parallel with lots of other requests (or the requests should be isolated, to use the parlance and yes, isolation is the "I" in ACID, and transactions are what give you ACID properties). So the cost of using XA transactions is a little absolute performance, but the benefit is that the results of your transactions are correct. You can rest easy at night knowing that withdrawals from your bank account aren't going to go screwy under some obscure loading conditions IF your bank is using XA!

This discussion takes place completely at the data level - XA is all about database transactions. Each transaction locks the data in the database until the transaction is complete, whereupon the results become visible to the waiting world. Transactions cause bottlenecks when multiple requests are trying to access the same data - all but the first locker of the contended data get blocked or thrown out, which clearly hurts throughput since work is being done that will not result in a successful transaction flowing through the system.

However data in the database is not the only shared resource in a transaction system. I already talked about application servers being resource sharing mechanisms - any of these resources could be contended for, so the application server itself needs to lock in-memory data structures to avoid problems if they are accessed on behalf of multiple requests in parallel, and contention can result here too. Of course, layers other than the app. Server are resource sharing too - on a typical server, those 60 execute threads you configured for WebLogic are probably being executed across a handful of CPUs at the most - when contention for CPUs occurs, the unlucky threads must wait in line until a CPU is free and so on with memory, disk, etc.

Overall, everything I have thus far mentioned represents a massive headache - the development of the performance tests, the running of the tests while all the tuning is done, the allocation of server resources to meet the predicted demands, and all of this is repeated with changing application releases and server environment releases and the resulting sized systems then have to stand up to unpredictable real-life loading. Not only is this a headache, it is a major lifetime cost of every application.

The astute among you will have noticed that my e-mail address has changed; that's because I have joined Azul Systems, who have a unique solution to these issues. Java is highly multithreaded, so it provides systems that contain many CPUs, each with many cores so those Java threads really result in parallelization. Then it provides support for optimistic locking on synchronized Java objects, to reduce contention within the Java software layer, then it provides pools of memory that can be shared between multiple applications. In short, the Azul Appliance provides a Java execution engine that dwarfs your systems' capacity to consume resources by overwhelming your individual applications with CPU and memory resources in order to try and alleviate any bottlenecks caused by the shortage of either in the traditional VM environment.

This tactic has the additional benefit that it more or less removes the need to do tuning on a per-application basis, since the set of resources provided by the appliance is so big that it can be readily shared among multiple applications that previously each required headroom on their own servers for peaks in demand. This sharing is possible because on aggregate the demand peaks will be smoothed (since it is improbable that many unrelated applications will all hit a demand peak at once), so demand can be met from the pooled resources, which leaves you free not only from application-level sizing (and the associated costs), but also from large-scale overprovisioning of hardware on a per-application basis too. All this heralds a new era of cheaply procured and managed appliances to run highly performant Java applications. For more details, visit www.azulsystems.com. That's all for this month; watch out for a repeat performance next month.