Changing the delivery of IT

Tony Bishop

Subscribe to Tony Bishop: eMailAlertsEmail Alerts
Get Tony Bishop: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Article

Improving Performance, Avoiding Hung Threads, and Keeping It Simple

Improving Performance, Avoiding Hung Threads, and Keeping It Simple

Q. What are some quick steps I can take to improve CPU utilization?
A.
If your application is experiencing serious performance problems, I recommend that you perform a thorough analysis to determine the root cause. But if you're looking for some quick ways to optimize application performance, here are a few tips that may help.

  • Distribute your JSPs. Much of the CPU burn for many applications is consumed by parsing back-end data up into data structures for handoff to the application's view (JSPs typically). If the CPU is burned in that part of the application, then chances are very good that it also gets burned while pulling apart these data structures when building the JSP itself. Try distributing your JSPs into a container separate from the business logic. As a result, more CPU will be available to help out with back-end data requests. Better yet, you'll understand whether the "front" or the "back" of your architecture burns more resources, so you can tune and/or add resources accordingly.

  • Review the semantics of your application's back-end connection usage (JDBC, JMS, etc.). Make sure all calls to distributed remote systems are wrapped with sensible timeouts (i.e., if a call hasn't come back in 15 or 30 seconds when it normally takes less than 5, then send a sensible error message back to the user). This helps you avoid the risk of hanging the entire application server due to a single failed resource.

  • Reduce the amount of data offered in search results. If your application returns search results, make sure it hands back less data at a time - not just to the user but to the WebLogic Server instance itself. If your application is fast, they won't mind clicking again. Large amounts of data can create a "pig in the python" problem throughout your entire application architecture.
  • Reduce unnecessary logging. As I mentioned in an earlier column (WLDJ, Vol. 2, issue 7), while logging is a great analytical tool, too much logging can cause excess CPU utilization. Consider putting a dynamic switch into your application that will allow you to redirect the logging to /dev/null whenever it is unnecessary. Additionally, when logging, you can use the features available in JDK 1.4 to select the appropriate level of granularity.

  • Measure, measure, measure. This final point is very important. There is no substitute for gaining a complete understanding of where your application is using resources and why. If you understand the answer to those questions, you'll know what it takes to improve your performance.

    Q: What are some good defensive programming techniques I can mandate for my developers to avoid a "hung thread" or "hung server" in production?
    A:
    In another column (WLDJ, Vol. 2, issue 6), I discussed finding the causes of stalled threads. Here are some techniques that can help you avoid them altogether. In most cases, a "hung thread" is one that has blocked on contacting a back-end system for data needed to dispatch its request. The most common of these is a database, in which case it is probably being contacted via JDBC. If your application is passing messages, it may be a JMS implementation. If it is a proprietary or legacy system, it might talk only a specific protocol over TCP/IP. The list goes on.

    The key is to make sure that the application knows what to do if the resource it needs is just not available. Most of the time, this isn't a problem because the code for timing out sockets to the remote DB server is all in the JDBC driver.

    When you have to handle timing out a connection yourself, the situation is significantly more complicated. David Reilly wrote a very informative article on handling network timeouts entitled "Simple Handling of Network Timeouts," which can still be found on the Web.

    There is no replacement for understanding how your transactions will behave at the code level when remote resources become unavailable. There are, however, a number of parameters in the various layers of software supporting your application that may be tuned to obtain better failure patterns right away. WebLogic Server itself includes a number of parameters for tuning how the EJB container transactions are timed out (http://edocs.bea.com/wls/docs70/ejb/ reference.html#1072610).

    The moral of the story is: if you're struggling with hung threads and suspends in your application, or you want to avoid struggling with them, spend time thinking about how each and every one of the connector components in your application will behave when the back-end resource on which they rely disappears.

    Q. Of the application architectures you've seen, which have been the most successful?
    A:
    When it comes to matters like this, my philosophy has always been to keep it simple. In my experience, the projects that usually end up on time and under budget are those that have been completed in the most straightforward way possible.

    Does this mean that you can ignore the principles of object-oriented design? No, but there may be times when you have too much of a good thing. Most architects of object-oriented applications will rightly object to two different teams creating their own versions of a thread pool. Doing this will result in a larger, less maintainable code base; bugs in one version will not necessarily get fixed in the other. But what about the logging strategy adopted for an application? One application may need logging for debugging and performance analysis. Another may need it to audit every transaction, perhaps for security purposes. Insisting on a unified logging framework for an entire enterprise might result in a logging approach that doesn't necessarily make sense for each application. For many applications, having a separate servlet for every important application use case, a small library of business logic that is not necessarily EJBs, and a JSP for each customer view of the Web application just might be exactly what you need. The bottom line is, keep it simple but be sensible; don't break the rules unless you know them first.

  • More Stories By Lewis Cirne

    Lew Cirne is the founder of New Relic, the first provider of on-demand (SaaS) application management tools for cloud or datacenter applications. A seasoned entrepreneur, technologist, and enterprise software pioneer, he has been focused on application performance management for more than ten years. Cirne holds seven patents related to application performance technology. Most recently he was an Entrepreneur in Residence at Benchmark Capital. He founded and was first CEO of Wily Technology and earlier held senior engineering positions at Apple and Hummingbird Communications.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.