Is your middleware delivering middling performance? Is your SOA just so-so? You need some sensible tips to get your stack on track. The Server Side recently had the opportunity to interview Matt Brasier, coauthor of the Oracle SOA Suite 11g Performance Cookbook and head consultant at C2B2 as well as Richard Walburton, lead of Java SE track at Devoxx UK. Here’s some of the advice we gleaned from our conversations with these experts.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
The cloud doesn’t let you drift lazily along
Brasier agrees that cloud services such as PaaS may do some tuning for you, especially around issues like sizing. But he says garbage collection tuning is still something that you’ll need to have a hand in adjusting if you want to get the most out of your platform. “There are simply no ‘best’ garbage collection settings. A workload that’s dealing with lots of small requests is going to generate a lot of small objects. This scenario requires different garbage collection settings than a workload with mostly large requests that persist over a long period of time.”
He say’s today’s JVM is pretty good at making guesses for you, but it’s not always going to come up with the right answers. The technology and automation in optimizing garbage collection hasn’t quite arrived yet. This means you could be over-provisioning and over-spending on cloud boxes if you don’t take the time to tune “by hand”. You need to learn to use the monitoring tools that are available so you can dictate what rules apply to provisioning more capacity. Monitoring allows you to pick up on the nuances affecting increased load such as temporary CPU usage, number of requests per second, number of file descriptors, or other components. Understanding what’s behind your higher load lets you refine the parameters for telling Amazon EC2 what you need.
How do you find problems in a SOA suite?
The key to finding any problem is getting information out of the system. No SOA should be a black box where stuff goes in and stuff comes out, but you can’t see what’s going on inside. Again, Matt says it all comes down to monitoring and testing throughout the application lifecycle. In order to make use of monitoring, you need to understand what normal and abnormal behavior looks like. Every system has resource bottlenecks. Logically speaking, if there were no bottlenecks, applications would run infinitely fast. Examples of common bottleneck areas might include CPU utilization, memory utilization, network bandwidth, or a lock on pool resources. Walburton adds that checking the GC log or the MXBeans can be helpful in narrowing down problems. With a tool like VisualVM, you can figure out what’s happening with your memory profile instead of just rewriting code to try to fix a problem. Vmstat command may help you find additional information such as whether you have too much paging occurring.
Finally, Brasier cautions against performing testing as a pass/fail exercise. You can’t breathe a sigh of relief and crack open the champagne just because your system passed a test. It’s critical to dig deeper. Monitoring allows you to see what’s close to failing – what the hot components are and where the stressors arise. Otherwise, you can’t head off potential problems. It’s not a success if you run a test for an hour and don’t realize that running for an extra 15 minutes would have crashed the whole system.
Richard points out that optimization is only necessary when there’s a specific issue that impacts business functionality. He puts it very succinctly, “The point in the application life cycle management when you should optimize is when your app isn’t meeting your requirements based on your business needs”. On the other hand, if you know up front that a given app isn’t going to do what you need it to do in terms of keeping the customer satisfied and driving revenue, you should build in optimization from the start. That’s particularly important with time budgets in apps where latency is likely to drive users batty. Testing for optimization in an iterative way (along with all other important requirements) allows you to fine tune performance without overdoing it.
What tips do you have to offer for fine tuning your SOA suite? Let us know.