Difference between revisions of "Scalability testing"

From Archivematica
Jump to navigation Jump to search
 
(99 intermediate revisions by 8 users not shown)
Line 1: Line 1:
[[Main Page]] > [[Development roadmap]] > Scalability testing
+
[[Main Page]] > Scalability testing
  
= Test design =
+
= Objectives =
  
Maximums to test for:
+
'''1. set up a dedicated testing environment'''
*Max number of SIPS - 10
+
<br>
*Max number of files in SIP - 10,000
+
The testing environment will start with 5 virtual machines set up in a hosted environment, where hardware resources can be scaled up and down between tests.  It is expected that the test environment will be ready to use by January 15th. 
*Max size of individual file - 30 GiB
+
[[Test Environment Documentation]]
*Max size of SIP - 100 GiB
 
  
Baseline amounts:
 
* number of SIPS - 1
 
* number of files in SIP - 10
 
* size of individual file - 1 MiB
 
* size of SIP - 100 MiB
 
  
{| class="wikitable"
+
'''2. develop a new initial repeatable test suite'''
|-
+
<br>Initial tests will focus on two main areas - file io and documenting individual micro-service performance. Data will be collected from external monitoring tools as well as from internal instrumentation.
! Test
 
! No. of SIPs
 
! No. of files in SIP
 
! Max size of individual file
 
! Max size of SIP
 
|-
 
| 1. Baseline Test
 
| 1
 
| 10
 
| 1 MiB
 
| 100 MiB
 
|-
 
| 2. No. of SIPs
 
| '''10'''
 
| 10
 
| 1 MiB
 
| 100 MiB
 
|-
 
| 3. No. of files
 
| 1
 
| '''10,000'''
 
| 1 MiB
 
| 100 MiB
 
|-
 
| 4. Max file size
 
| 1
 
| 10
 
| '''30 GiB'''
 
| 100 MiB
 
|-
 
| 5. Max SIP size
 
| 1
 
| 10
 
| 1 MiB
 
| '''100 GiB'''
 
|-
 
| ...
 
|
 
|
 
|
 
|
 
|}
 
  
*Other tests: combination of maximums
+
External monitoring will be done with two open source packages, munin and collectd.  This will provide data at the operating system level. 
 +
Internal instrumentation already exists within the Archivematica source code, where each step in the process has a start time and end time recorded in the local database.  This instrumentation will be extended and refined during the buildout of the test suite.  The data collected will be used to identify which specific micro-services, and which steps within those micro-services are taking the longest time to complete.
  
= Test metrics =
+
'''3. document a full matrix of test parameters'''
* Success: completed/not completed
+
<br>Archivematica workflow can vary considerably depending on use case.  Artefactual will document all testing efforts on this wiki, building out a matrix of test cases.  For example, we expect that adding additional storage subsystem capacity will allow for linear growth in scalability (add more disks, it should all go faster).  This will be one of the first 'columns' in our test matrix, repeating tests with the same workload, changing the capacity (maximum io's per second) of the storage subsystem between tests. 
* Time: by (a) each micro-service or by (b) receiveSIP to completion of storeAIP/uploadDIP?
 
* Number of errors
 
* ?
 
* ?
 
  
 +
Initial tests will focus on the 4 primary stages in the Archivematica workflow - Transfer, Ingest, creation of SIP, creation of AIP.  There are additional steps required, both before Transfer, and after creation of AIP, however these steps do not necessarily involve the use of Archivematica code.  For example, moving digital objects to a shared folder that Archivematica can access is a prerequisite of the Transfer stage, and can take a considerable amount of time.  We will document best practices for how to complete that work after initial scalability testing is complete.
  
Setup:
+
'''4. repeat test suite at customer sites'''
* dual core AMD 2.2ghz
+
<br>The two initial customer sites have been identified by Archivematica and tests will be repeated at both customer sites.
* 2gb of ram
 
* 2x2TB in raid 0
 
* archivematica installed bare metal
 
  
= Test results =
+
= Test Structure =
  
== Transfer ==
+
Scalability testing is done using a scripted workload, where all decision points, that are normally left to the Archivist to make using the Dashboard, are instead automated through the use of a configuration file.  This allows for repeatable test cases.  Example test scripts will be posted here over the coming weeks.
  
{| border="1" cellpadding="10" cellspacing="0" width=90%
 
|-
 
! Test date
 
!System setup
 
!No. transfers
 
!No. files
 
!Total file size
 
!Largest file size
 
!Pass/fail
 
!Total time
 
!Comments
 
|-
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|-
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|-
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|-
 
|}
 
</br>
 
  
== Ingest ==
+
= Test File Sets =
 +
[http://archivematica.org/downloads/docZips/ Test Documents]
  
{| border="1" cellpadding="10" cellspacing="0" width=90%
+
= Archived Scalability Test Results =  
|-
+
Historical test results are available [[Archived Scalability Test Results]]
! Test date
 
!System setup
 
!No. SIPS
 
!No. files
 
!Total file size
 
!Largest file size
 
!Pass/fail
 
!Total time
 
!Comments
 
|-
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|-
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|-
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|-
 
|}
 
</br>
 
 
 
</br>
 
 
 
== Old test findings ==
 
 
 
Findings when running a 2,000 and 10,000 object sip through:
 
* the dashboard would loose contact with the MCP intermittently this maybe fixed with more cores in a processor
 
* transcoder extract packages was producing ALOT of log, causing the logs to rotate every few seconds.  Is a less verbose log possible, with option for debug mode?
 
* Sanitize (/usr/lib/sanitizeNames.py) names hung For a very long time, MCPServer and MCPClient seemed fine however. My 2,000 object sip contained ~1,000 objects with spaces in the name, the 10,000 object sip contained ~9,000 objects with spaces in the name.  On both the 2,000 object sip and the 10,000 object SIP the processing failed to complete.
 

Latest revision as of 18:08, 16 October 2013

Main Page > Scalability testing

Objectives[edit]

1. set up a dedicated testing environment
The testing environment will start with 5 virtual machines set up in a hosted environment, where hardware resources can be scaled up and down between tests. It is expected that the test environment will be ready to use by January 15th. Test Environment Documentation


2. develop a new initial repeatable test suite
Initial tests will focus on two main areas - file io and documenting individual micro-service performance. Data will be collected from external monitoring tools as well as from internal instrumentation.

External monitoring will be done with two open source packages, munin and collectd. This will provide data at the operating system level. Internal instrumentation already exists within the Archivematica source code, where each step in the process has a start time and end time recorded in the local database. This instrumentation will be extended and refined during the buildout of the test suite. The data collected will be used to identify which specific micro-services, and which steps within those micro-services are taking the longest time to complete.

3. document a full matrix of test parameters
Archivematica workflow can vary considerably depending on use case. Artefactual will document all testing efforts on this wiki, building out a matrix of test cases. For example, we expect that adding additional storage subsystem capacity will allow for linear growth in scalability (add more disks, it should all go faster). This will be one of the first 'columns' in our test matrix, repeating tests with the same workload, changing the capacity (maximum io's per second) of the storage subsystem between tests.

Initial tests will focus on the 4 primary stages in the Archivematica workflow - Transfer, Ingest, creation of SIP, creation of AIP. There are additional steps required, both before Transfer, and after creation of AIP, however these steps do not necessarily involve the use of Archivematica code. For example, moving digital objects to a shared folder that Archivematica can access is a prerequisite of the Transfer stage, and can take a considerable amount of time. We will document best practices for how to complete that work after initial scalability testing is complete.

4. repeat test suite at customer sites
The two initial customer sites have been identified by Archivematica and tests will be repeated at both customer sites.

Test Structure[edit]

Scalability testing is done using a scripted workload, where all decision points, that are normally left to the Archivist to make using the Dashboard, are instead automated through the use of a configuration file. This allows for repeatable test cases. Example test scripts will be posted here over the coming weeks.


Test File Sets[edit]

Test Documents

Archived Scalability Test Results[edit]

Historical test results are available Archived Scalability Test Results