Guaranteeing Performance Throughout The Development Lifecycle

443 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
443
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 80% according to Aberdeen research
  • 80% according to Aberdeen research
  • Users and companies are demanding complex and powerful security frameworks be implemented very quickly Many have come on the market recently and, often the performance and scalability is lacking
  • In its simplest form, a J2EE application operates in a layered execution model.   J2EE App -> App Server -> JVM -> OS -> Hardware Each of these layers effects the others – keeping all of them healthy and fast is a delicate balancing act (Vertical Complexity)
  • Web applications have evolved from simple static pages to functionally rich and complex applications. As complexity of the applications increased, we are required to scale the J2EE components into their respect tiers and increases database processing to support the application. This means that we now have multiplied our layered complexity of the last slide over several machines and sometimes across domains. In addition, more and more J2EE applications are being interconnected, increasing the extent to which a single bad app can bring down the performance of a whole system (Horizontal Complexity)
  • There are many stakeholders in J2EE application performance management all with different needs and different perspectives on the problem. To be successful you have to keep everyone on the same page and communicating clearly. This is becoming increasing difficult with geographically remote campuses and outsourcing moving some of all of these groups away from each other. If communication is allowed to break down then the application will almost always suffer
  • Given the complexity of today’s J2EE applications and all of the stakeholders involved, we are presented with something of a conundrum: How do we quickly identify the root cause and speed time to resolution of the performance problem?
  • Performance means different things to different people and to different stakeholders
  • Tune your application to address the needs/expectations of your users; if users expect certain transactions to run fast then they better run fast; on the other hand if they can tolerate slow response time for other aspects of your application (e.g. credit card processing) then you can better understand where you need to tune…
  • Need to see the entire architecture, you cannot focus only on the database or only on the code or only on the environment (JVM, hardware, etc.) Document how you tuned your environment, where you found performance problems, how you resolved performance problems, etc. This will better equip you to handle future problems of a similar nature.
  • Eliminate components in the system architecture as the problem, web server, app server, OS, hardware, network, etc. Eliminate application code as the problem Diagnosing components in the system architecture often quickly leads us to investigating code.
  • Effective use of tools make it much easier to guarantee application quality. If you can’t measure it, you can’t fix it.
  • Specific: e.g. Response time under 2 seconds for 95% of up to 100 users Realistic: unrealistic SLAs will be ignored by everyone – e.g. all transactions must respond in less than a second and seamlessly integrate with all legacy apps and … Flexible: <insert more info here> Make sure that SLAs are possible by involving the parties that are responsible for the implementation of the application to support the SLA; a collaborative effort How are you going to measure performance? How will you know if your application is running well?
  • Define object lifecycles in UML docs: help the garbage collector do its job! Er on the side of caution – if in doubt clean it out of memory and then recreate it later. From an application-level use case you must define (1) when objects are created, (2) the duration of their usefulness, and (3) at what point they should be eliminated from the runtime environment.
  • Perform performance tests along with unit tests; make sure that there are no memory leaks and performance is acceptable in components before moving those components to the final application. E.g. it is much more difficult to build a car with parts that haven’t been tested – where is the problem? Creating a “Festival of Pain”.
  • Applications are rarely deployed in isolation; they need to be tested working together; e.g. small dinky flash game brought down a billion dollar company’s web site… Perception of QA: there to help you (developers)! They need to be highly qualified individuals, not “geeks that couldn’t make it as developers”
  • Revenue: In B2B e-commerce industry, 1 hour down time for some backs can equate to millions of dollars of losses Credibility: e.g. high-profile bank customers (>$10million per account): low volume usage, but VERY important that the site is available and good response time.
  • Armed with the methodology to diagnose application/database performance issues, all of the performance stakeholders can have application confidence Developers Optimize code to resolve the problems Deliver high-quality apps to testing Avoid firefighting QA/Testing Rapidly isolate poorly performing components during load testing Accurately assess scalability DBAs Identify slow SQL Asses performance of the database system Know when the DB is at fault … and when it’s not Application Support Rapidly isolate problems in production Automatically trigger deeper diagnostics Asses the Performance of the application server Meet SLAs
  • As I have explained throughout the presentation, there are many stakeholders in J2EE application performance management that will get involved at sometime during the lifecycle of the application. Given the complexity and all of the stakeholders involved in J2EE application performance management, diagnosing and quickly resolving performance problem can be a very daunting task. To identify the root cause of performance problems and ultimately speed up time to resolution, we need a methodology to quickly detect, diagnose, and resolve performance issues and an integrated tool set the enable us the act upon that methodology.
  • Guaranteeing Performance Throughout The Development Lifecycle

    1. 1. Guaranteeing Performance Throughout The Development Lifecycle Steven Haines J2EE Architect and Evangelist Quest Software
    2. 2. Agenda <ul><li>Speaker introduction </li></ul><ul><li>Understanding the importance of performance in J2EE custom applications </li></ul><ul><li>Overview of the processes that can ensure performance for your users </li></ul><ul><li>Performance considerations in development, testing and production </li></ul><ul><li>Introducing the Performance Management Suite </li></ul><ul><li>Questions & Answers </li></ul>
    3. 3. Speaker Introduction <ul><li>J2EE Architect and Evangelist for Quest Software </li></ul><ul><li>Author of Java 2 Primer Plus and Java 2 From Scratch </li></ul><ul><li>Co-Author of Java Web Services Unleashed </li></ul><ul><li>Java Host and columnist on InformIT.com (Pearson Education) </li></ul><ul><li>Java Instructor at the University of California, Irvine (UCI) and previously Learning Tree University (LTU) </li></ul><ul><li>Recruited as a J2EE architect in the “real world” </li></ul>
    4. 4. The Importance of Performance in J2EE Custom Applications
    5. 5. J2EE Performance in the Market <ul><li>Customers demand performance and scalability from your J2EE systems </li></ul><ul><li>80% of production J2EE applications don’t meet their performance requirements </li></ul><ul><li>This can jeopardize your business through lost revenue from e-business sales or lost confidence (and partnerships) from B2B site failures </li></ul>
    6. 6. J2EE Performance in the Market <ul><li>Companies are beginning to understand that performance and scalability are problems that must be avoided early on in the cycle </li></ul><ul><li>Performance Management software for J2EE is one of the hottest segments of the market </li></ul><ul><li>However even with tools many feel overwhelmed </li></ul>
    7. 7. Why Is It So Overwhelming? <ul><li>J2EE is easy to learn and quick to develop </li></ul><ul><li>This has increased its popularity and means bigger, more complex and interrelated systems </li></ul><ul><li>Architecture neutrality means apps need to work in difficult and disparate environments </li></ul><ul><li>Frameworks add black-box areas to your application </li></ul><ul><ul><li>Frameworks upon frameworks </li></ul></ul><ul><ul><li>Performance and scalability is often unknown </li></ul></ul>
    8. 8. J2EE Layered Execution Model
    9. 9. J2EE Layered Execution Model
    10. 10. The Performance Stakeholders <ul><li>What code is behind the symptom? </li></ul><ul><li>Is the application architecture a problem? </li></ul><ul><li>What component is at fault? </li></ul><ul><li>Who should fix the problem? </li></ul>? <ul><li>Which SQL statements need tuning? </li></ul><ul><li>Is the DB really the problem? </li></ul>? <ul><li>Is the application available? </li></ul><ul><li>Is the app server configured correctly? </li></ul>? ?
    11. 11. The Challenge: Ensuring Application Performance <ul><ul><li>A systematic approach to detect the problem, correctly diagnose the root cause and resolve the issue in a timely manner </li></ul></ul><ul><ul><li>An integrated tool set to provide detection of performance problems, power diagnostic capabilities, and quick resolution of problems once diagnosed </li></ul></ul>Requires two things:
    12. 12. Performance From Start to Finish: General Guidelines
    13. 13. Understand What Performance Is <ul><li>Web Page Response Time </li></ul><ul><li>Application Server Resource Utilization </li></ul><ul><li>JVM Heap Utilization </li></ul><ul><li>System Resource Utilization </li></ul><ul><li>Database Resource Utilization </li></ul><ul><li>Network Activity </li></ul>
    14. 14. Know Your Users <ul><li>What do they expect? </li></ul><ul><li>What Inconveniences them? </li></ul><ul><li>What can they realistically put up with? </li></ul>
    15. 15. Build Your Knowledge Base <ul><li>Learn outside your comfort zone </li></ul><ul><li>Keep notes, review them periodically and develop wisdom </li></ul>
    16. 16. Methodology <ul><li>Establish performance criteria for successful applications </li></ul><ul><ul><li>E.g. with 100 users, response time should be less than five seconds </li></ul></ul><ul><li>Measure application performance throughout the development process </li></ul><ul><li>Open lines of communication between all domain experts </li></ul><ul><ul><li>Application Architects, Developers, Testers, Database Administrators, System Administrators and Application Owners all have a role to play </li></ul></ul><ul><ul><li>If they aren’t communicating effectively it will effect your application </li></ul></ul>Build application performance into your development process
    17. 17. Know How Tools Can Help <ul><li>Use Monitoring Tools to detect problems early </li></ul><ul><ul><li>Before your users start complaining! </li></ul></ul><ul><li>Use Diagnostic Tools to quickly locate the problem </li></ul><ul><ul><li>Drill down to the root cause of the problem </li></ul></ul><ul><ul><li>Measure the effect of the problem </li></ul></ul><ul><li>Use Resolution Tools to isolate and fix the problem </li></ul><ul><ul><li>Which line of Java code? Which SQL call? Which system resource? </li></ul></ul><ul><ul><li>Measure the performance of changes designed to resolve the problem </li></ul></ul><ul><ul><li>Did the fix have have the desired effect? </li></ul></ul>Simplify the Detection, Diagnosis and Resolution of application problems
    18. 18. Performance From Start to Finish: Specific Suggestions
    19. 19. Get a Head-Start <ul><li>Define what you mean by performance </li></ul><ul><li>Setting performance SLAs </li></ul><ul><ul><li>Specific </li></ul></ul><ul><ul><li>Realistic </li></ul></ul><ul><ul><li>Flexible </li></ul></ul><ul><li>Collaborate with parties responsible for ensuring SLAs </li></ul>
    20. 20. Avoid Problems with Early Detail <ul><li>Explicit design documents that include an understanding of: </li></ul><ul><ul><li>When objects are to be created </li></ul></ul><ul><ul><li>The duration of their usefulness </li></ul></ul><ul><ul><li>The point at which they should be eliminated </li></ul></ul><ul><li>You can’t be too explicit about your requirements </li></ul>
    21. 21. Development Pitfalls <ul><li>Test performance at every milestone </li></ul><ul><li>If you have a unit test for functionality, test for memory efficiency and performance at the same time </li></ul><ul><li>Watch for common errors </li></ul><ul><ul><li>Come back for our next webinar for more on this! </li></ul></ul>
    22. 22. QA / Testing Concerns <ul><li>Functionality, performance, scalability </li></ul><ul><li>Remember: Applications are rarely deployed in isolation so why are you testing them as if they will be? </li></ul><ul><li>Change the perception of QA </li></ul><ul><li>How to test for performance and scalability </li></ul><ul><ul><li>The third webinar in this series will address this! </li></ul></ul>
    23. 23. Production Dangers <ul><li>Be realistic about resource requirements (hardware, network, app server) </li></ul><ul><li>You should see fewer problems if you’ve done your work up-front in development and testing </li></ul><ul><li>Monitor closely and dynamically </li></ul><ul><ul><li>The fourth and final webinar in this series will discuss this! </li></ul></ul>
    24. 24. Application Confidence: The Payoff
    25. 25. What Are Your Fears? <ul><li>Lost credibility </li></ul><ul><li>Lost revenue </li></ul><ul><li>Lost job </li></ul>
    26. 26. What Is Application Confidence? <ul><li>The knowledge that thanks to your testing process you are assuring your application’s success </li></ul><ul><li>A feeling of calm when you application is rolled out </li></ul>
    27. 27. Application Confidence For Performance Stakeholders <ul><li>Optimize code to resolve the problems </li></ul><ul><li>Deliver high-quality apps to testing </li></ul><ul><li>Avoid firefighting </li></ul><ul><li>Rapidly isolate poorly performing components during load testing </li></ul><ul><li>Accurately assess scalability </li></ul><ul><li>Identify slow SQL </li></ul><ul><li>Asses performance of the database system </li></ul><ul><li>Know when the DB is at fault … and when it’s not </li></ul><ul><li>Rapidly isolate problems in production </li></ul><ul><li>Automatically trigger deeper diagnostics </li></ul><ul><li>Asses the Performance of the application server </li></ul><ul><li>Meet SLAs </li></ul>
    28. 28. The Application Performance Management Suite
    29. 29. Detection: Monitoring In Production <ul><li>Foglight </li></ul><ul><ul><li>24x7 Distributed application monitoring solution </li></ul></ul><ul><ul><li>Cartridges for application servers, databases, etc. </li></ul></ul><ul><ul><li>Intelligent rules help you keep track of the health of your OS, Databases, J2EE Applications, Packaged Applications, and warn you of dangerous situations with progressive alerts </li></ul></ul><ul><ul><li>Lightweight web console allows anyone in the company to view the data they need when they need it </li></ul></ul><ul><ul><li>MyFoglight allows you to customize your views to suit each individual or group with data that’s relevant to them </li></ul></ul>
    30. 30. Lightweight Production Diagnosis <ul><li>Spotlight </li></ul><ul><ul><li>A real-time diagnostic tool that identifies bottlenecks on the server and troubleshoots problems with deployed J2EE applications. </li></ul></ul><ul><ul><li>Eliminate guess work with color-coded alerts and intelligent drill-down that lead you quickly to the heart of the problem </li></ul></ul><ul><ul><li>Expert advice helps solve the problem and tuning suggestions can be used to improve performance </li></ul></ul>
    31. 31. Deep Diagnosis in Production and QA <ul><li>PerformaSure </li></ul><ul><ul><li>End-to-End power diagnostic tool for production or pre-production analysis of J2EE problems </li></ul></ul><ul><ul><li>Low, configurable overhead can give you detail down to the method-level for Java as well as give you insight into inefficient SQL and stored procedures </li></ul></ul><ul><ul><li>Intuitive interface makes finding the root cause easy, even if you’re not a J2EE expert </li></ul></ul><ul><ul><li>Share analysis sessions between developers, DBAs, QA testers and Production support groups to speed time to resolution </li></ul></ul>
    32. 32. Problem Resolution <ul><li>JProbe </li></ul><ul><ul><li>The premier Java Profiling tool </li></ul></ul><ul><ul><li>Get statement-level performance and object allocation data </li></ul></ul><ul><ul><li>Find memory leaks quickly and easily </li></ul></ul><ul><ul><li>Integrated with PerformaSure </li></ul></ul><ul><li>Quest Central </li></ul><ul><ul><li>Quest Central provides everything you need to manage single or multi-platform database environments within an integrated console </li></ul></ul><ul><ul><li>Has set the industry standard for heterogeneous database administration, performance diagnostics, SQL tuning, and space management </li></ul></ul>
    33. 33. Summary <ul><li>There are many stakeholders in J2EE application performance </li></ul><ul><li>Diagnosing performance problems in real-world J2EE applications can be challenging </li></ul><ul><li>We need two things to simplify the process of identifying and resolving the root cause of performance problems: </li></ul><ul><ul><li>Methodology </li></ul></ul><ul><ul><li>Tools </li></ul></ul>
    34. 34. Thank you http://www.quest.com

    ×