(r14) RationalQualityManagerOnlineMigrationTestMatrix < Deployment

Engineering Lifecycle Management Wiki - Deployment
Community information and contribution guidelines
~~EditAttach~~Printable
TWiki > Deployment Web > DeploymentInstallingUpgradingAndMigrating > RationalQualityManagerOnlineMigrationTestMatrix
Revision 14 - 2014-09-17 - 22:17:45 - VaughnRokosz
<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%">
---+!! <img src="https://jazz.net/wiki/pub/Deployment/WebPreferences/new.png" alt="Under construction" width="50" height="50" align="right"> Rational Quality Manager online migration test matrix
%DKGRAY% Authors: Main.JingQian, Main.DavidWalker, Main.VaughnRokosz <br>
Build basis: Rational Quality Manager 4.0.6, 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>

---++ Disclaimer

The information in this testing matrix table is distributed AS IS.  The use of this information is a customer responsibility and depends on the customer’s ability to evaluate into their operational environment. While each item may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or similar results will be obtained elsewhere. Any performance data contained in this document was determined in a controlled environment, and therefore, the results that may be obtained in other operating environments may vary drastically. Users of this document should verify the applicable data for their specific environment.

The actual throughput or performance that any user will experience will vary depending upon many factors, including considerations such as the network latency between servers, the I/O configuration, the storage configuration, the workload processed, the DB server tuning and the specific data shape. Therefore, no assurance can be given that an individual user will achieve results similar to those stated here. 

---++ Summary

Starting in Rational Quality Manager V4.0.6, you can choose to migrate data from an older version of the product to the latest product version while the production server is still online. This migration method is called pre-upgrade online migration. Before implementing an online migration, determine whether offline or online migration is warranted for your repository by running the migration estimation command and then checking the following test results matrix for guidance on the results.

If your database contains a large amount of data, online migration reduces server downtime by running a few of the database migration tasks while the old server remains active.  Which would otherwise exceed the acceptable downtime window using the traditional offline migration.

If online migration is recommended for your repository, follow the detailed instructions in the [[http://www-01.ibm.com/support/knowledgecenter/api/content/SSYMRC_5.0.1/com.ibm.rational.test.qm.doc/topics/c_online_mig_rqm.html][Online migration for Rational Quality Manager data]]

---++ Understanding Performance Measure and Online Migration

Besides the ones mentioned above, the following factors also have significant impact on your migration performance results.
   * The network latency from the server running migration to the database where your repository resides
   * If your database table index is up to date
   * The shape of your RQM data, specifically
      * The number of manual execution script state (you can get the count from the onlineEstimate command)
      * The number of script steps in each of the script state
      * The content size of each script step, does it contain large amount of rich text, images.
   
The purpose of this testing matrix is to help customers extrapolate in terms of rough scale on what the migration performance might be.  So customer could make a decision on migration using online vs. offline mode.  We strongly recommend customers whose repository exceeds 100GB and has 1,000,000 or more script states should perform an online migration to minimize production downtime. If you are unsure of whether or not online migration is correct for your deployment we suggest you reach out to your support representative and the team will guide you to make the best decision for your organization.

During online migration, online migration process is running as a separate JVM against your live DB server.  The data is migrated in such a way as to not affect users on the existing server.  RQM online migration process does not make modifications to your existing data.  It only migrates data into new tables in the database.  Online migration is designed can be stopped and resumed at any given time.  If there are failure during online migration, once the underline issues are fixed, online migration can resume from where it was left off.  

%RED%
 *As a best practice, customer should have a sandbox environment that replicates production data in order to do a dry run of migration to get a more accurate estimate time.*
%ENDCOLOR%

---++ Testing matrix

| *Customer data* | *Database* | *Repository size* | *Artifact counts <br/>ManualExecutionScript state counts* | *Data migration completed* | *Fully offline migration* | *Online migration recommended?* | *Online (priority=50) / Offline / Server impact <br /> (default setting)* | *DB statistics updated (Yes OR No)* |
| <b>Internal customer data</b>  |   |   |   |   |   |   |   |   |
| IGA (4.0.2) | DB2  | 380GB| 1 Million test script states | Yes | 38 hrs 35 minutes | Yes | 66 hrs / 1.5 hrs / negligible | Yes |
| IGA (3.0.1) | DB2  | 35GB| 46,000 test script states | Yes | 6 hours | No | Not applicable | No |
| Jazz.net (CLM selfhost test teams) | DB2  | 10GB| 1,000 test script states | Yes | One hour | No | 54 minutes / 6 minutes / Negligible | No |
| RESRQM01 | DB2  | 150GB| 120,000 test script states | Yes | 7 hrs 45 minutes  | No | 11 hrs 50 minutes / 40 minutes / Negligible | Yes |
| <b>External customer data</b>  |   |   |   |   |   |   |   |   |
| Healthcare sandbox | Oracle | 2GB| 200,000 test script states | Yes | 3 hours  | No | Not applicable | No |
| Healthcare production data |  |  |  |  |  |  |  |  |
| <b>Other</b> |  |  |  |  |  |  |  |  |
| rqmx64d (RQM testbed) | DB2 | 42GB | 7,000 test script states | Yes | 35 minutes | No | Not applicable | No |

---++ Understanding how network latency can impact migration times

Our in-house testing identified network latency as one of the main factors that influence the total migration time.     Network latency refers to the overhead of sending a data packet over the network from the computer that is running the migration process to the database server.    You can get an estimate of network latency by running the "ping" utility - run "ping" on the computer on which you plan to run the migration utility, and "ping" the database server.    

In the example below, the network latency can be estimated as the average ping time (here, .36 millseconds)

     <img src="%ATTACHURLPATH%/PingExample.png" alt="PingExample.png" width="780" height="300" />

Even small values of network latency (half a millisecond) will increase the time required for migration, and this is magnified as the number of test scripts to be migrated increases.

The chart below shows how the time required to migration 125,000 test scripts increases as network latency is increased from .02 to 3 milliseconds.    Each of these test runs used a priority of 100.   The migration was done while the Rational Quality Manager server was shut down, to better isolate the impact of network latency from other factors.    In these tests, a network delay was injected artificially using software running on the test system.

     <img src="%ATTACHURLPATH%/MigTimeVsLatency.png" alt="MigTimeVsLatency.png" width="689" height="393" />

Each additional millisecond of network latency adds 343 minutes of migration time for a 125K repository containing simple test scripts with 4 steps.

To estimate the additional time added to the migration process due to network latency, you will first need to get the average ping time in milliseconds between the migration server and the database server.   You'll also need the total number of test scripts to be migrated (which you can get by running "reptools-qm.sh -onlineMigrateEstimate" - use the count of test script states but ignore the auditable link counts).    Use the following formula to estimate the overhead of network latency:

   * Migration time added due to network latency (minutes) = (343 / 125000) * (Average Ping Time) * Total Script States * ( 100 / Priority)

For example, if you had 2 million script states to migrate, with an average ping time of 2 milliseconds and priority=100 , the amount of additional time required to migrate would be:

   * 2 milliseconds * 2,000,000 scripts ( 343 / 125000) (100 / 100) = 10976 minutes (7.6 days) 

If you ran the migration with priority=50, this would double the migration time:

   * 2 milliseconds * 2,000,000 scripts ( 343 / 125000) (100 / 50) = 21952 minutes (15.2 days) 

If you have complex test scripts (more than 20 steps, or steps which include images), increase the estimate by 25%.

Note that this time is the additional cost due to network latency.   To get the total time, you can estimate the base migration time in a 0 latency environment and then add in the additional time due to latency.    For complex test scripts, a good rule of thumb is to assume that you can migrate 300 scripts per minute (at priority = 100).   In the prior example, migration of 125,000 scripts would therefore take 125,000/300 = 416 minutes (7 hours).    Over a 2 millisecond latency network, the total migration time would be (Base time + latency cost) = 416 minutes + 21952 minutes = 15.5 days.

---+++ Recommendations for dealing with latency

To reduce the total migration time, be sure to minimize the network latency between the migration system and the database server.    Consider running the migration process on the database server if you don't have a system with fast network access to the database server.

You can copy the "JazzTeamServer" directory to a temporary location on your database server in order to run the migration.     The migration process is single-threaded, so it will add a small amount of CPU overhead.    The migration process will also consume roughly 1.5G of RAM.    For a typical database server which will have multiple CPU cores and RAM sizes of 16G or more, the impact of running migration locally on the database server will be small.


---+++++!! Related topics: [[DeploymentWebHome][Deployment web home]]

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


   * [[http://www-01.ibm.com/support/knowledgecenter/api/content/SSYMRC_5.0.1/com.ibm.rational.test.qm.doc/topics/c_online_mig_rqm.html][Online migration for Rational Quality Manager data]]
   * [[https://www.ibm.com][IBM]]

---+++++!! Additional contributors: Main.JingQian, Main.JohnNason, Main.RosaNaranjo

<sticky></div></sticky>
Attachments
Topic attachments
I	Attachment	Action	Size	Date	Who	Comment
png	MigTimeVsLatency.png	manage	7.9 K	2014-09-17 - 21:42	VaughnRokosz	Migration time as a function of network latency
png	PingExample.png	manage	67.7 K	2014-09-17 - 21:52	VaughnRokosz	Example output from the ping command, to estimate network latency
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.