(r11) TuningGeneralGuidance < Deployment

Engineering Lifecycle Management Wiki - Deployment

Community information and contribution guidelines

~~EditAttach~~Printable

TWiki > Deployment Web > DeploymentConfiguringAndTuning > TuningGeneralGuidance

Revision 11 - 2013-11-30 - 17:01:27 - Main.sbeard

<div id="header-title" style="padding: 10px 15px; border-width:1px; border-style:solid; border-color:#FFD28C; background-image: url(<nop>https://jazz.net/wiki/pub/Deployment/WebPreferences/TLASE.jpg); background-size: cover; font-size:120%">
---+!! Tuning general guidance
%DKGRAY% Authors: [[Main.DavidToczala][DanToczala]] <br>
Build basis: CLM 2012, Rational Team Concert 4.0.1, Rational Quality Manager 4.0.1, Rational Requirements Composer 4.0.1
%ENDCOLOR%</div></sticky>

<!-- Page contents top of page on right hand side in box -->
<sticky><div style="float:right; border-width:1px; border-style:solid; border-color:#DFDFDF; background-color:#F6F6F6; margin:0 0 15px 15px; padding: 0 15px 0 15px;">
%TOC{title="Page contents"}%
</div></sticky>

<sticky><div style="margin:15px;"></sticky>

It is important to keep in mind that there is no single “right” configuration for a Jazz solution. Different organizations will have different usage models, different workloads, different processes, and different software development cultures. In addition, the people using the Jazz infrastructure will change over time. There may be new employees, new processes, and more efficient ways of doing things.

However, while every Jazz solution will be unique, and have its own characteristics, the general concepts should hold true. It is important to have an idea of some of the characteristics of how Jazz provides its capabilities, so future scaling needs can be better anticipated.

It is also important to keep in mind that Jazz performance is dependent on a number of different variables. When dealing with Jazz deployments, you may make tuning changes which will greatly improve performance, which you do not see immediate results from. That is because other areas of your solution architecture are throttling performance.

---++ Example of performance tuning realities

<img src="%ATTACHURLPATH%/BadPerformance.png" width="525px" />

In the scenario pictured above, a poorly configured <noautolink>WebSphere</noautolink> installation is causing performance issues that are making end users unhappy. Notice that the other major impacts on performance are tuned with varying degrees of precision. So although we have our Linux filesystem perfectly tuned, our end users never see the benefits of this. The same holds true for Jazz applications. These are tuned well, but due to the bottleneck presented by the poorly configured <noautolink>WebSphere</noautolink>, we can improve our tuning of the Jazz applications and our end users would never see any benefit in terms of improved performance.

<img src="%ATTACHURLPATH%/MediocrePerformance.png" width="525px" />

In the next diagram, we have addressed our poorly tuned <noautolink>WebSphere</noautolink> issues. This has resulted in some improved performance for our end users, but the results may not be as dramatic as we had hoped. This is because we are now being throttled by poorly configured JVM settings.

<img src="%ATTACHURLPATH%/OKPerformance.png" width="525px" />

So once we address the poorly configured JVM, we realize additional improvements in performance, and our end users appear to be satisfied. At this point, if we wanted to further improve performance, we
would need to address the bottlenecks in both DB2 and our usage model (the way that we use the Jazz applications). These are often the toughest scenarios to deal with, since isolated changes seem to have either no mpact, or a negative impact. When you see this happening in your environment, then you should believe that you have multiple chokepoints.

The key thing to remember is that as you relieve pressure from one area of the architecture, you will increase the pressure on other areas. So if we increase the throughput at the web server layer, we end up putting more pressure on the backend database, since more requests are now passing through to this layer within any given time period. I have heard it compared to a balloon filled with water, as you squeeze one end, the other end expands.

When working on Jazz solution performance, realize that at some point you will reach a point of diminishing returns. Tune your various areas of the architecture for best performance, but also realize when it is time to stop tuning, and time to scale with more infrastructure and/or Jazz application instances.

---+++++!! Related topics: [[Deployment.DeploymentTroubleshooting][Deployment troubleshooting]], [[Deployment.DeploymentMonitoring][Deployment monitoring]] 

---+++++!! External links:

   * [[http://pic.dhe.ibm.com/infocenter/clmhelp/v3r0m1/index.jsp?topic=%2Fcom.ibm.jazz.install.doc%2Ftopics%2Fc_topology_overview.html][Installation topologies]]

---+++++!! Additional contributors: None 

<sticky></div></sticky>

Copyright © by IBM and non-IBM contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use. Please read the following disclaimer.
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.