Application Performance Management Review

Discussions

News: Application Performance Management Review

  1. Application Performance Management Review (6 messages)

    Java Application Performance Management (APM) is about managing the performance of your Java application from start to finish. In this article Jack Shirazi reviews what APM consists of, and what it can do for you.

    Read more about: Application Performance Management (APM)
  2. What is really important when providing a J2EE application performance management solution?

    Source: http://www.devstream.com/JView2004
    "...while the database is not the cause of the problem, most J2EE performance issues stem from poor SQL usage and database tuning."

    Source: http://www.veritas.com/news/successstories/listing/SuccessStoryDetails.jhtml?successStoryId=60775
    "The system would begin to slow down when a certain number of users would log on, or the volume of traffic was too high...we were unable to identify where those bottlenecks existed....We studied various performance management tools, but none of these gave us an accurate pinpoint of the problem. Within minutes, VERITAS i3 identified ...one particular [SQL] query which was running at 0.5 secs...."

    Source: http://www.borland.com [Borland ServerTrace User Guide]
    "The JDBC Details view is probably the most important view for most users.
    Whether youÂ’re running an online store or a backend employee support
    system, accessing the database is an essential feature of your application.
    Proper caching, minimizing duplicate accesses, preventing unintended EJB
    write-backs, and investigating the slowest SQL calls, are all likely candidates
    for those interested in improving application performance.
    "

    Source: http://www.wilytech.com/solutions/caseStudies/reactive.html
    "A majority of the rogue transactions spend the most time making database calls, which are shown as the actual SQL statements that the transaction makes."

    Regards,

    William Louth
    JDBInsight Product Architect
    JInspired

    "J2EE tuning, testing and tracing with Insight"
    http://www.jinspired.com
  3. It's important to note that the quote from the Wily case study in the previous post is lifted from a scenario in which the author was describing a single case - not making a general statement about all bad transactions.

    The poster of the last message represents a product which supposedly competes with all the companies listed on his post, and took this quote far out of context to support his point.

    In fact, an ever increasing number of the most complex J2EE applications don't even have a database. I'm the Technical Field Specialist for Wily, which means I've been fortunate enough to work with some of the most complex production J2EE applications around the world, using our Wily 5 platform to analyze and isolate their significant performance and stability issues. In addition to using Introscope to pinpoint inefficient SQL statement execution, it's determined problems in the way J2EE applications interact with document management systems, messaging architectures, EAI systems, mainframe CICS apps, Tuxedo apps; name a (non-jdbc) data source, and a Wily "firefighter" has probably seen a J2EE application failing because of it, or the way the app is using it.

    Just blaming the back-end systems isn't fair, though. Take a look at the Wily's 2003 Benchmark Survey on APM for comprehensive information about the areas that plague application performance:

    http://www.wilytech.com/solutions/whitePapers/chartingJ2EE.html

    Ki Alam
    Technical Field Specialist
    Wily Technology
    http://wilytech.com/
  4. I've been doing performance consulting for the past 3 years or so, and what William Routh says has some point. Persistence layer design and SQL are the two worst offenders that I've seen (consistently.) Others can typically be traced to institutional issues, such as bad communications, resulting in either misunderstood requirements/algorithms or incorrect usage of someone else's code.

    APM can catch the symptoms, but doesn't really give solutions, as it tends to be much lower in the stack.

    I mean, come on, who deliberately writes bad code? I find that the "typical" developer (generalizing a lot here) doesn't really understand persistence or documentation very well, but they're all decent coders with good fundamentals. Nobody sets out and says, oh, I'm going to put this extra recursion here just for the fun of it.

    Jeff
  5. Hi Ki,

    I did provide the source reference so the complete context was accessible. I had to limit the size of the posting.

    If you go to the Quest (PerformaSure) site you will find a single customer case study that reports a significant performance issue for a particular transaction (user) in seconds that was reduced significantly. Do you honestly think that this was a Java code issue? It is most certainly an external resource issue and the chances are that it is a database because most messaging backends do not have such performance problems because of the high probability it is a integration into an existing workflow system. I could be wrong because the case study is so vague on environment and executional details.

    "Just blaming the back-end systems isn't fair, though."

    I never said this. The problem is new applications interacting with the database backend in sub-optimal ways due to issues in the demarcations of transactions or transactional execution sequence pattern (repeated sql executions, inefficient process design, too many rows, poor resource management).

    Lets be honest J2EE APM vendors started out profiling the application code and then quickly realized that the majority of the problems (apart from memory management) were as a result of inefficient resource transaction design in the servicing of a request. Then we had a slew of add-ins to these products. In the lastest releases of the major player products the focus has increased even futher though lucky for us not to an acceptable level.

    As a Borland J2EE architect since early 1999 when we had our first alpha release I have yet to see a piece of Java bean code directly cause a performance problem. It is always how the code interacts with its environment especially external elements.

    Regards,

    William Louth
    JDBInsight Product Architect
    JInspired

    "J2EE tuning, testing, tracing with Insight"
    http://www.jinsired.com
  6. Correction[ Go to top ]

    "J2EE tuning, testing, tracing with Insight"
    http://www.jinspired.com
  7. Pramati ships (along with the Server) a powerful J2EE Application analyzer- that analyzes all aspects of a J2EE Applications including
    - J2EE Call profiles- including the callbacks
    - J2EE Server latencies (lock waits, pool waits, et al)
    - External calls- JMS, DB
    - SQL profiles
    - Transaction dynamics
    - Multiple dimensions- trace web entry points, EJB beans,
              transactions, sepcific resources.

    With minimal overheads- under 2% CPU, Memory & response.

    Check out Pramati's 'Diagnostics' at- http://demo.pramati.com/index.htm

    Cheers,
    Ramesh