(r6) RationalTeamConcert50PerformanceReport < Deployment

~~EditAttach~~Printable
r6 - 2014-05-12 - 19:25:45 - Main.waradeYou are here: TWiki >
Deployment Web > DeploymentPlanningAndDesign > PerformanceDatasheetsAndSizingGuidelines > RationalTeamConcert50PerformanceReport
<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%">
<!--
   * Set ALLOWTOPICCHANGE = Main.TWikiAdminGroup, Main.TWikiDeploymentDatasheetsAuthorsGroup, Main.GrantCovell, 
-->
---+!! <img src="https://jazz.net/wiki/pub/Deployment/WebPreferences/uc.png" alt="uc.png" width="50" height="50" align="right">Collaborative Lifecycle Management performance report: RTC 5.0 release</br>
%DKGRAY% Authors: Main.ChetnaWarade</br>
Last updated: May 12, 2014</br>
Build basis: Rational Team Concert 5.0
%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>

---++ Introduction

This report compares the performance of an unclustered Rational Team Concert version 4.0.5 deployment to the previous 4.0.4 release. The test objective is achieved in three steps:

   * Run 5.0 (build CALM-I20140430-0604) with standard 4-hour test
   * Run 4.0.6 RC2 with standard 4-hour test
   * Compare the results and file any defects observed.

---+++!! Disclaimer

%INCLUDE{"PerformanceDatasheetDisclaimer"}%

---++ Findings

---+++ Performance goals

   * Verify that there are no performance regressions between current release and prior release with 1100/1200 concurrent users using the workload described below.

---+++ Findings
   
   * RPT throughput is comparable in both 4.0.6 RC2 and 5.0 RC2.
   * GC logs show slightly different trend in pause times and gc collection trend in 4.0.6 RC2 and 5.0 RC2, however shows no significant impact on the transaction rate. 
   * Nmon data shows comparable system statistics in both 4.0.6 RC2 and 5.0 RC2.

---++ Topology

The topology under test is based on Standard Topology (E1) [[https://jazz.net/library/article/820#Enterprise_Distributed_Linux__DB2]]

<img src="%ATTACHURLPATH%/E1_Topology_Config.jpg" alt="Server Overview" width="750" height="500" />

The specifications of machines under test are listed in the table below. Server tuning details listed in *[[#AppendixA][Appendix A]]*

				<table class="gray-table">
					<tbody>
						<tr>
							<th valign="top">
								Function</th>
							<th valign="top">
								Number of Machines</th>
							<th valign="top">
								Machine Type</th>
							<th valign="top">
								CPU / Machine</th>
							<th valign="top">
								Total # of CPU Cores/Machine</th>
							<th valign="top">
								Memory/Machine</th>
							<th valign="top">
								Disk</th>
							<th valign="top">
								Disk capacity</th>
							<th valign="top">
								Network interface</th>
							<th valign="top">
								OS and Version</th>
						</tr>
						<tr>
							<td>JTS Application Server </td>
							<td>1</td>
							<td>Intel Tylersburg (Loaner)</td>
							<td>2 x Intel® Xeon® X5560 CPUs (4-Core 2.8 GHz 64-bit)</td>
							<td>4</td>
							<td>18 GB</td>
							<td>SATA</td>
							<td>450 GB</td>
							<td>Gigabit Ethernet</td>
							<td>Red Hat Linux 6.4 64-bit</td>
						</tr>
                                                <tr>
							<td>CCM Application Server </td>
							<td>1</td>
							<td>Intel </td>
							<td>4 x Intel® CPUs (6-Core 2.66 GHz 64-bit)</td>
							<td>6</td>
							<td>32GB</td>
							<td>SATA</td>
							<td>150GB</td>
							<td>Gigabit Ethernet</td>
							<td>Red Hat Linux 6.4 64-bit</td>
						</tr>
                                                <tr>
							<td>IBM HTTP Server 8.5.5.0</td>
							<td>1</td>
							<td>Intel</td>
							<td>2 x Intel® Xeon® CPUs (2-Core 3.0 GHz 64-bit)</td>
							<td>2</td>
							<td>8 GB</td>
							<td>SATA</td>
  							<td>300 GB</td>
							<td>Gigabit Ethernet</td>
							<td>Red Hat Linux 6.4 64-bit</td>
						</tr>
						<tr>
							<td>Database Server</td>
							<td>1</td>
							<td>IBM System x3950 M2</td>
							<td>2 x Intel® Xeon®X7350 CPUs (4-Core 2.93GHz 64-bit)</td>
							<td>4</td>
							<td>32 GB</td>
							<td>Netapp LUN FC</td>
							<td>600 GB</td>
							<td>Gigabit Ethernet</td>
							<td>Red Hat Linux 6.4 64-bit</td>
						</tr>
						<tr>
							<td>RPT Workbench</td>
							<td>1</td>
							<td>IBM x3250 M3</td>
							<td>1 x Intel® Xeon®X3480 CPU (4-Core 3.06GHz 64-bit)</td>
							<td>4</td>
							<td>16 GB</td>
							<td>RAID 0</td>
							<td>100 GB</td>
							<td>Gigabit Ethernet</td>
							<td>Red Hat Linux 5.8 64-bit</td>
						</tr>
<tr>
							<td>RPT Agents</td>
							<td>5</td>
							<td>VM Image</td>
							<td>1 x AMD Opteron 3.0GHz</td>
							<td>2</td>
							<td>6GB</td>
							<td>SATA</td>
							<td>35GB</td>
							<td>Gigabit Ethernet</td>
							<td>Red Hat Linux 5.2 64-bit</td>
						</tr>
							<td>RPT Agents</td>
							<td>5</td>
							<td>VM Image</td>
							<td>4 x Intel(R) Xeon(R) CPU E5-2687W 3.10GHz</td>
							<td>8</td>
							<td>8GB</td>
							<td>SATA</td>
							<td>90GB</td>
							<td>Gigabit Ethernet</td>
							<td>Red Hat Linux 5.8 64-bit</td>
						</tr>
						<tr>
							<td>Network switches</td>
							<td>N/A</td>
							<td>Cisco 2960G-24TC-L</td>
							<td>N/A</td>
							<td>N/A</td>
							<td>N/A</td>
							<td>N/A</td>
							<td>N/A</td>
							<td>Gigabit Ethernet</td>
							<td>24 Ethernet 10/100/1000 ports</td>
						</tr>
					</tbody>
				</table>

N/A: Not applicable.

---+++Network connectivity

All server machines and test clients are located on the same subnet.
The LAN has 1000 Mbps of maximum bandwidth and less than 0.2 ms latency in ping.

---+++Data volume and shape

The artifacts were distributed between 2 components in 1 project, 50 scm streams and  artifacts.

The repository contained the following data:

   * 134 folders
   * 983 files
   * 50 streams
   
   * Database size = 15 GB
   * JTS index size = 1 MB
   * CCM index size = 1 MB


---++Methodology

---+++Test cases and workload characterization
For release to release baseline performance comparison a rate controlled workload is used, named Rational Performance Platform (RPP). A rate controlled user is a user thread that runs at a controlled rate based on the user factors such as Builds (4): Developer (12): Contributors (10): Feeds (35). It may run at a multiple of the target rate to represent more than one user but it will run no faster than the target rate and will report exceptions if it can't keep up. In addition, the use of ratio-based sequences RPPSequences as explained below ensures that the proportion of user types is maintained as new threads are created. The default ratio is Builds(1): Developers(7): Contributors(14): Feeds(7)

This section describes in more detail what the RTC sequences do to emulate user activity.

RPPSequences are Java-based schedules that provide the setup and runtime iteration logic to drive a series of custom-code based "tasks" simulating user operations and use cases. Different user types are represented by named sequences to simulate activity by different user roles. A single user thread may be running at a higher than normal speed to simulate more than one user; for this reason each sequence has "factors" estimating how many individual tasks each user type would perform per hour and the estimated number of users is based on dividing total tasks for a user class by that "factor" to estimate number of users.

Communication between Developer and Build users rely on an intermediate API layer that calls an external process known as the "SCM Daemon" which handles the actual server connections; an agent usually has two of these daemons to distribute load. Contributor users include some local API calls as well as REST calls to simulate web browser 
traffic.

---+++File Downloads:

Projects and Streams: Users are assigned to different streams in the same project to spread them out into small to medium teams working in each stream. The project/stream structure is up to the tester but is typically 10-50 streams.

Components and Workspaces: User workspaces work with one of two components for different operations:

   * "Stable" component is fixed size and is not subject to changes or growth during the run. The file number and size are up to the tester but are typically 5 K to 10 K files with an average size of 10 Kbytes per file. This is used to get predictable behavior for Load operations.

   * "Active" component usually starts empty but this is where Developer users create and modify files, so it grows quickly with a lot of users in the same stream.

---+++Builds (!BuildJavaSequence)
 Builds simulate an RTC Build Engine by requesting work (!BuildRequests), then simulating a Build cycle by loading a workspace, sending status messages, and publishing artifacts to the server to simulate a load, compile, test, and publish build cycle. One build per hour is meant to simulate one build engine; in the test harness, a build "user" may perform one or more builds per hour, depending on configuration.

Currently one complete build cycle per hour represents one "build".

ONETIME SETUP:
   * Create !BuildDefinition, !BuildEngine, and workspace as needed

RUNTIME LOOP:

!BuildRequests: Simulate build engines by making multiple requests before build assignment by invoking the most commonly called webservices through the !BuildToolkit at 6 different points in the sequence, doing the following each build cycle:

   * 6 times 10x (getBuildDefinition)
   * 6 times 30x (getBuildEngine, getNextRequest)
   * 6 times 4x (setLastContactTime)

Build Cycle simulation: Send status messages and artifacts to the server simulating the communication process during real builds.
Workspace Loading: Completely unload and load the workspace STABLE component once

_Note: Longest operation_

Start build: getBuildDefinition, getBuildEngine, requestAndStartBuild, getBuildResult

Activities: Each activity begings with startBuildActivity and ends with completeBuildActivity

!PublishLinks: Publish (one URL)

Compile: Publish (compile.logs.xml, compile.logs)

!PublishArtifacts: Publish (test-artifact.txt, 2x(smallzipfile.zip), link)

Testing: Publish (5 different results.xml files plus buildlog.txt)

_Note: Time intensive because artifacts are parsed on client side and cause many web service calls_

Complete: makeBuildComplete (signal build finished)

---+++ !WorkItems (!ContributorSequence)

The !WorkItem Contributor sequence simulates a mix of activities in specific proportions. A single contributor is set to perform 20 tasks per hour in the RPP simulation. Workitem traffic consists of some REST calls isolated from early SVT HTTP script based tests and a series of API based tests that create and modify workitems, refresh workitem contents, and create, run, and delete queries.

ONETIME SETUP:
   * Create initial workitem

RUNTIME LOOP:


#TestCases
				<table class="gray-table">
					<tbody>
						<tr>
							<th align="center">
								Use case
							</th>
							<th align="center">
								Description
							</th>
							<th align="center">
								% of Total Workload
							</th>
						</tr>
						<tr>
							<td>Login
							</td>
							<td>Logout/Login - Relogin to the current account
							</td>
							<td align="center">2
							</td>
						</tr>
						<tr>
							<td>Refresh Workitem</td>
							<td>Lookup and retrieve an existing workitem</td>
							<td align="center">78</td>
						</tr>
						<tr>
							<td>Browser REST calls simulating some browser operations</td>
							<td> !WorkItemRESTNavigation - !IQueryRestService/queries and 10x(!IQueryRestSerice/query). Other calls in this operation have been disabled over time because of version incompatibilities

        !WorkItemRESTOpenWIPage - !IWorkItemReservice/allValues, !IQueryRestService/queriesForOwner, !IQueryRestService/scopedQueries</td>
							<td align="center">1</td>
						</tr>
						<tr>
							<td>Browser REST calls simulating other operations</td>
							<td> 	!GetEditorPresentation - !IWorkItemRestService/editorPresentation

!GetPredefinedQueries - !IQueryRestService/scopedQueries

!GetQuickInfoPresentation - !IWorkItemRestService/quickInformationPresentation

!GetValueSets - !IWorkItemRestService/workItemEditableProperties</td>
							<td align="center">2</td>
						</tr>
						<tr>
							<td>Create/Modify Workitems</td>
							<td> !WorkItemCreateWorkItem - Create a new workitem. Recent changes add a larger description

 !WorkItemModify - Add link, subscripter, comment, approval, and change state of existing workitem</td>
							<td align="center">14</td>
						</tr>
						<tr>
							<td>Add Attachment to Workitem</td>
							<td>Add a 1 megabyte attachment to an existing workitem. Recent changes reduce this to 20K but allow the test to control the size.</td>
							<td align="center">1
							</td>
						</tr>
						<tr>
							<td>Queries</td>
							<td> !CreateQuery2 - Create a new query looking for summary containing "test1"

!CreateQueryAndDelete - Create same query but immediately delete it

2x !RunQuery - Run a pre-established query and confirm it returns same 30 results expected

2x !RunQueryAndOpen - Run same query and open first workitem in it

!ModifyQuery - Modify and save the query created by !CreateQuery2</td>
							<td align="center">1</td>
						</tr>
						<tr>
							<td>Reports</td>
							<td>Disabled</td>
							<td align="center">1</td>
						</tr>
						
					</tbody>
				</table>

---+++Developer (!DeveloperSequence)

Developers generally use the Eclipse rich client to download files, checkin changes, accept changes from other users and make deliveries; in addition they rely on Feeds data and perform Contributor operations. This sequence runs at 25 tasks per hour per developer. Each developer should be matched by a Feeds "user" at 40 tasks/hour and some additional Contributor traffic.

ONETIME SETUP:

   * Create a new workspace and load the "Active" component used for making and receiving changes
   * Create a private work directory of roughly 50 files and folders to use as a personal "scratch box" for making changes without conflicting with other users.

_Note: Doing fresh setup periodically will probably smooth out longer runs_

RUNTIME LOOP

Workspace operations

#TestCases
				<table class="gray-table">
					<tbody>
						<tr>
							<th align="center">Use case</th>
							<th align="center">Description</th>
							<th align="center">% of Total Workload</th>
						</tr>
						<tr>
							<td>Workspace Load</td>
							<td>Unload and Load the "Stable" component, an unchanging component of 5-10K files</td>
							<td align="center">1</td>
						</tr>
						<tr>
							<td>Workspace refresh</td>
							<td>Load the "Active" component, requiring workspace compare but usually no file downloads</td>
							<td align="center">15</td>
						</tr>
						<tr>
							<td>Clone Workspace</td>
							<td>Clone and make another copy of workspace</td>
							<td align="center">1</td>
						</tr>
						<tr>
							<td>Do nothing</td>
							<td> </td>
							<td align="center">83</td>
						</tr>											
					</tbody>
				</table>

"During Day" activity loop (Runs 10 times within each runtime loop)

#TestCases
<table class="gray-table">
	<tbody>
		<tr>
			<th align="center">Use case</th>
			<th align="center">Description</th>
			<th align="center">% of Total Workload</th>
		</tr>
		<tr>
			<td>Make file changes in the private directory</td>
			<td>Make changes: Checkin changes to current changeset after making 1-8 changes to local filespace (change files(82%), create files(12%), delete files (5%), create folder(1%)) Modify the changeset: !CloseChangeSet (8%), Suspend/Resume(6%), Discard(5%), do nothing (81%)</td>
			<td align="center">50	</td>
		</tr>
		<tr>
			<td> !CompareWorkspace</td>
			<td> Compare workspace to another workspace</td>
			<td align="center">5</td>
		</tr>
		<tr>
			<td>Accept/Deliver changes</td>
			<td>Accept/Deliver changes to and from local workspace to repository workspace</td>
			<td align="center">5</td>
		</tr>
		<tr>
			<td>Accept incoming changes</td>
			<td>Accept incoming changes from repository workspace into local workspace</td>
			<td align="center">20</td>
		</tr>
		<tr>
			<td>RefreshPendingChanges</td>
			<td>Refresh pending changes to see local changes made versus incoming changes</td>
			<td align="center">10</td>
		</tr>
		 <tr>
			<td>History</td>
			<td>Get history on single file</td>
			<td align="center">5</td>
		</tr>
		 <tr>
			<td>Deliver/Baseline</td>
			<td>Deliver changes to repository workspace or take a baseline off the workspace</td>
			<td align="center">3</td>
		</tr>
		  <tr>
			<td>CompareWorkspaceBaseline</td>
			<td>Compare baselines on a workspace</td>
			<td align="center">2</td>
		</tr>
		 <tr>
			<td>Do nothing</td>
			<td> </td>
			<td align="center">10</td>
		</tr>						
	</tbody>
</table>

---+++Feeds (!FeedsSequence)

Feeds simulate a feature of the Eclipse rich client which checks the server for recent workitem or build events of interest to the user. Feeds are normally repeated for each user every 10 minutes for the projects they are working with. RTC Development early on indicated that they had seen roughly 40 feeds operations per developer (Eclipse user) per hour and that is the basis for our simulation rate.

ONETIME SETUP:

Create one feed channel for the current project and one feed channel for the associated team area. Usually sets up two feeds channels per user; RTC developers average around eight.

RUNTIME LOOP:

!RefreshFeeds: Called repeatedly during run

Request each feed channel parse its input (make a query to the server and parse results)

Reset time window: Simulate how client works by creating a new dummy news item to reset the time window subsequent feeds requests should use. Without doing this, all feeds produce news from the beginning of time.

---++Results

---+++User Estimation

<table class="gray-table">
					<tbody>
						<tr>
							<th> 	</th>
							<th>4.0.6 RC2</th>
							<th>5.0 RC2</th>
						</tr>
						<tr>
							<td># of users</td>
							<td>2,337</td>
							<td>2,387</td>
						</tr>
						<tr>
							<td>download/hr</td>
							<td>12.01 GB</td>
							<td>12.69 GB</td>
						</tr>
						<tr>
							<td>upload/hr</td>
							<td>4.08 GB</td>
							<td>4.39 GB</td>
						</tr>												
					</tbody>
				</table>


<img src="%ATTACHURLPATH%/BytesSentRcd50RC2.jpg" />

---+++Task throughput
<table class="gray-table">
					<tbody>
						<tr>
							<th> </th>
							<th>4.0.6 RC2</th>
							<th>5.0 RC2</th>
						</tr>
						<tr>
							<td># of completed tasks</td>
							<td>341,568</td>
							<td>341,820</td>
						</tr>									
					</tbody>
				</table>

Tasks represents use-cases based on frequently done standard user operations. Task throughput is the number of completed tasks throughout the run duration.

---+++ CCM Server web services

Server side web services data are collected from the CCM server using !JazzMon / JTSMon monitoring tool. 

<img src="%ATTACHURLPATH%/WebservicesRsp50RC2.jpg" />
<img src="%ATTACHURLPATH%/WebservicesCnt50RC2.jpg" />


---+++System comparison

*OS resource usage - average CPU*

<img src="%ATTACHURLPATH%/CPUChart50RC2.jpg" />


*OS resource usage - average memory*

<img src="%ATTACHURLPATH%/MemoryChart50RC2.jpg" />


---+++ *Garbage collection*

Verbose garbage collection is enable to create the GC logs. The GC logs shows very little variation between runs except at 30 min duration there is a long pause time in 4.0.5 GA. There is also no discernible difference between versions.  

Below is one example of the output from the GC log.

*4.0.6 RC2 CCM garbage collection*

<img src="%ATTACHURLPATH%/406RC2CCMgc.jpg"  />

*5.0 RC2 CCM garbage collection*

<img src="%ATTACHURLPATH%/50RC2CCMgc.jpg"  />

*4.0.6 RC2 JTS garbage collection*

<img src="%ATTACHURLPATH%/406RC2JTSgc.jpg"  />

*5.0 RC2 JTS garbage collection*

<img src="%ATTACHURLPATH%/50RC2JTSgc.jpg"  />


---++ Appendix A
#AppendixA
<table class="gray-table">
	<tbody>
		<tr>
			<th align="left" width="200"><strong>Product</strong><br></th>
			<th align="left" width="100"><strong>Version</strong></th>
			<th align="left" width="600"><strong>Highlights for configurations under test</strong></th>
		</tr>
		<tr>
			<td style="vertical-align: top;">IBM HTTP Server for !WebSphere Application Server</td>
			<td style="vertical-align: top;">8.5.0.0</td>
			<td style="vertical-align: top;">IBM HTTP Server functions as a reverse proxy server implemented
via Web server plug-in for !WebSphere Application Server. Configuration details can be found from the [[http://pic.dhe.ibm.com/infocenter/clmhelp/v4r0/index.jsp?topic=%2Fcom.ibm.jazz.install.doc%2Ftopics%2Ft_config_reverse_proxy_ihs.html][CLM infocenter]].

*HTTP server (httpd.conf)*:

   * !MaxClients: increase value for high-volume loads [[http://publib.boulder.ibm.com/httpserv/ihsdiag/ihs_performance.html][(adjust value based on user load)]]
   * !ThreadsPerChild = default
   * disable the large logging file(s)

*OS Configuration*:

   * increase max user processes = 65536
   * decrease stack size = 512K [[http://publib.boulder.ibm.com/httpserv/ihsdiag/ihs_performance.html][(limit the value for the httpd threads for a large user load in the envvars file)]]
   * Edit /proc/sys/kernel/pid_max and /proc/sys/kernel/threads-max to more than 65536 run sysctl -w kernel.pid_max=65536 on linux command line.
			</td>
		</tr>
		<tr>
			<td style="vertical-align: top;">IBM !WebSphere Application Server</td>
			<td style="vertical-align: top;">8.5.5.0</td>
			<td style="vertical-align: top;"><strong>JVM settings:</strong>

   * GC policy and arguments, max and init heap sizes:

				<verbatim>
-Xgcpolicy:gencon -Xmn768m -Xmx6g -Xms6g -Xgc:preferredHeapBase=0x100000000 -Xloaminimum0.02 -Xsoftrefthreshold5 -Xdump:none -XX:MaxDirectMemorySize=1500M 
</verbatim>

				*Thread pools:*

   * Maximum !WebContainer = 300
   * Minimum !WebContainer = 50

				*OS Configuration:*

				Increase system wide resources for the app server process owner:
   * max user processes = unlimited
   * core file size = unlimited
   * open files = 65536
   * stack size = 65536

			</td>
		</tr>
		<tr>
			<td>DB2</td>
			<td>DB2 Enterprise Server 10.1.0.2</td>
			<td>Tablespace is stored on Netapp LUN storage device. </td>
		</tr>
		<tr>
			<td>LDAP server</td>
			<td>Microsoft Active Director v2008 R2</td>
			<td>Defaults</td>
		</tr>
		<tr>
			<td>License server</td>
			<td>Same as CLM version</td>
			<td>Hosted locally by JTS server</td>
		</tr>
		<tr>
			<td>RPT workbench</td>
			<td>8.2.1.5</td>
			<td>Defaults</td>
		</tr>
		<tr>
			<td>RPT agents</td>
			<td>8.2.1.5</td>
			<td>Defaults</td>
		</tr>
		<tr>
			<td>Network</td>
			<td> </td>
			<td>Shared subnet within test lab</td>
		</tr>
	</tbody>
</table>


---++ Appendix B - References

   * [[https://jazz.net/wiki/bin/view/Deployment/RationalTeamConcert405PerformanceReport][Comparison of 4.0.4 GA vs 4.0.5 GA]]
   * [[https://jazz.net/wiki/bin/view/Deployment/RationalTeamConcert404PerformanceReport][Comparison of 4.0.4 vs 4.0.3]]
   * [[https://jazz.net/wiki/bin/view/Main/CLMBaseline2013_403M4Week4][Comparison of 4.0.2 RC1 vs 4.0.3 M4 CALM-I20130411-0627]]

---++ Appendix C - History

Prior reports are located on jazz.net development wiki:
   
   * 4.0.X: https://jazz.net/wiki/bin/view/Deployment/PerformanceDatasheetsAndSizingGuidelines
   * 4.x: https://jazz.net/wiki/bin/view/Main/CLMBaselines2012
   * 3.x: https://jazz.net/wiki/bin/view/Main/CLM301Performance


---++++!! About the authors

Main.ChetnaWarade is has been a Software Engineer at IBM for over 9 years. She is part of the Rational Performance Engineering group.

--------------------
---+++++!! Questions and comments:
   * What other performance information would you like to see here?
   * Do you have performance scenarios to share? 
   * Do you have scenarios that are not addressed in documentation?
   * Where are you having problems in performance?

%COMMENT{type="below" target="PerformanceDatasheetReaderComments" button="Submit"}%

%INCLUDE{"PerformanceDatasheetReaderComments"}%

<sticky></div></sticky>
Attachments
Topic attachments
I	Attachment	Action	Size	Date	Who
jpg	406RC2CCMgc.jpg	manage	71.7 K	2014-05-12 - 17:11	UnknownUser
jpg	406RC2JTSgc.jpg	manage	49.2 K	2014-05-12 - 17:11	UnknownUser
jpg	50RC2CCMgc.jpg	manage	65.2 K	2014-05-12 - 17:10	UnknownUser
jpg	50RC2JTSgc.jpg	manage	48.1 K	2014-05-12 - 17:10	UnknownUser
jpg	BytesSentRcd50RC2.jpg	manage	60.6 K	2014-05-12 - 17:11	UnknownUser
jpg	CPUChart50RC2.jpg	manage	83.3 K	2014-05-12 - 17:12	UnknownUser
jpg	E1_Topology_Config.jpg	manage	59.4 K	2014-05-12 - 17:15	UnknownUser
jpg	MemoryChart50RC2.jpg	manage	86.8 K	2014-05-12 - 17:12	UnknownUser
jpg	WebservicesCnt50RC2.jpg	manage	198.4 K	2014-05-12 - 17:15	UnknownUser
jpg	WebservicesRsp50RC2.jpg	manage	207.5 K	2014-05-12 - 17:12	UnknownUser
Deployment
Community information and contribution guidelines
Status icon key:
To do
Under construction
New
Updated
Constant change
None - stable page
Smaller versions of status icons for inline text:
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.