Enterprise

Highway and Java enterprise application projects have much in common. Both can suffer from design flaws, stalled flow, and unforeseen performance glitches. But in the case of Java enterprise applications, performance management tools can help developers highlight potential problems before they derail these critical projects.

Java's infancy in the late '90s began as a free-for-all with simple applications that exposed information to an exploding number of users. As the Java language and Java developers matured, J2EE emerged and enterprises began a more cautious approach to developing Java applications. Applications moved away from simple presentation layers into a torrent of complex Java deployments.

Today we see massive, composite applications built on platforms like WebLogic, WebSphere, and SAP NetWeaver, changing the way the world conducts business. But they, like huge engineering projects, sometimes become so complex that it is difficult to gain visibility into all elements of the application, and to proactively manage it so that small problems are identified and solved before they impact performance and availability. Are there lessons that Java application developers can learn from engineers to ensure applications move smoothly from development through QA and into production?

Consider Boston's Big Dig, one of the largest American public engineering projects since the Hoover Dam was built in the 1930s. Consider its magnitude in terms of money (over $14 billion thus far) and scale (diverting miles of highway underneath the city).

This project has become one of the biggest engineering missteps in recent history; the latest problem to beset the project is a flood of millions of gallons of water gushing from over 400 leaks breaching the tunnel walls. Moreover, the mistake wasn't fully realized until thousands were using the tunnel daily. The city of Boston is now knee-deep in problem analysis, fingerpointing among vendors, and questions such as: Could this have been predicted and prevented? Why didn't the project team isolate the problem during testing?

A business enterprise may be considering not so dissimilar engineering projects in mass and scale, investing millions of dollars in information technologies. And project goals are likely the same: optimize throughput and increase user satisfaction while minimizing time and cost.

Today, many projects that depend on integration and collaboration will rely on enterprise portals and J2EE technologies. Multiple silos within an enterprise can integrate seamlessly and share information. Reusable components lead to faster time to development and more robust applications. The success of these projects is critical to the success of business processes - in many cases they are the business.

With so much at stake, how can companies isolate and eliminate the blunders that eluded Boston's engineers? How can they maintain quality and ensure that minor issues do not escalate into massive outages? How can they predict and eliminate problems before they affect their customers?

Proven Performance Management Solution
Based on Wily Technology's extensive experience helping its customers manage the performance of their J2EE environments, we have identified the following criteria as essential for effective application performance management:

• Monitor application health and availability 24x7 in real time.
• Isolate the cause of performance issues throughout the application environment, at each stage of the application life cycle, from the J2EE application itself to back-end systems.
• Provide customized, detailed data to everyone with a stake in the performance of the application.

An effective management solution must provide monitoring, issue analysis, and problem triage of the J2EE application platform, all with 360 degree visibility into Web application components and their interaction. Components include user response, network latency, the virtual machine, the J2EE application server database, messaging, Web services, and back-end applications.

Further, this information must be shared among development and operations within IT, and in some cases with the business units themselves. This requires the use of a single tool that draws on the same consistent data to produce highly customized dashboards, highlighting the specific areas of concern for each stakeholder.

Consider the Big Dig again. The 400 gushing leaks were once minor cracks. Cracks escalated into holes and holes into inch-wide fissures. Applications behave the same way; a management solution must detect minor issues in the application before they become critical outages.

Leaks can become as severe as system crashes every few hours in a production application. Java developers are not burdened by memory management, since the JVM does garbage collection. In many cases, however, data structures are misused in memory. Monitoring the most aggressively growing data structures is necessary to eliminate misuse in the source code.

J2EE applications have resources - called threads - to perform a unit of work. The number of threads in an application is limited, like the number of lanes on the underground highway. To move beyond the limit requires new hardware - a new tunnel or new CPU.

Construction or accidents can block highways. Application threads become stalled for a variety of reasons - back-end systems are down, resources are over-utilized, or the network is busy.

It is necessary to detect these stalled threads. Because performance response time is a lagging indicator, monitoring leading indicators such as stalls can predict and isolate problems before they escalate.

Measuring and Monitoring Flow
Imagine "concurrency" on a highway as the number of lanes holding a car within a highway cross-section. Concurrency for a highway can be predicted for the time of day but go unpredicted for events such as heavy rains. Similarly, applications are quantified by throughput - requests processed per second. Concurrency monitoring provides a deeper analysis of where application threads are busy.

Concurrency in an application can be base lined for a particular time of the day. When levels exceed normal, concurrency will show which application components are problematic. Historical performance data helps determine which components need to scale as user load increases. After all, the goal is to ensure and increase user acceptance.

Consider the Big Dig one last time. Critics blame the vendors for discovering the problems only after commuters started using the tunnel. Let's assume that the vendors performed due diligence. Leaks could indicate the stress of both user load and time. Applications may also pass user-acceptance testing and system-integration testing, but usage-testing scenarios may not expose deficiencies.

Most problems occur only when real customers start to use the application. Retesting the application after implementation will not work either. That J2EE is the middleware between different systems increases the risks dramatically. A production-monitoring tool is needed to expose these problems - one that can provide full visibility with negligible overhead. An early warning system should alert operators and support personnel of potential problems before traffic is slowed or halted altogether.

J2EE projects face issues similar to those of large-scale engineering projects. Problems are inevitable, but nevertheless resolvable and often times predictable. Wily research shows that problems are seldom caused by the vendor platform, but often lie in back-end connections or custom development. The earlier those problems are detected, the less likely they will escalate into major setbacks. Problem mitigation becomes more difficult further along the project timeline. Projects can minimize these issues effectively by using a management solution that meets the requirements for successful application deployment.

Ultimately, projects that include performance management throughout the application life cycle are more likely to succeed and provide faster time to value.
Can you dig it?

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...