docs/development/devtools/testing/s3p/pap-s3p.rst

   1 .. This work is licensed under a
   2 .. Creative Commons Attribution 4.0 International License.
   3 .. http://creativecommons.org/licenses/by/4.0
   4
   5 .. _pap-s3p-label:
   6
   7 .. toctree::
   8    :maxdepth: 2
   9
  10 Policy PAP component
  11 ~~~~~~~~~~~~~~~~~~~~
  12
  13 Both the Performance and the Stability tests were executed by performing requests
  14 against Policy components installed as part of a full ONAP OOM deployment in Nordix lab.
  15
  16 Setup Details
  17 +++++++++++++
  18
  19 - Policy-PAP along with all policy components deployed as part of a full ONAP OOM deployment.
  20 - A second instance of APEX-PDP is spun up in the setup. Update the configuration file (OnapPfConfig.json) such that the PDP can register to the new group created by PAP in the tests.
  21 - Both tests were run via jMeter.
  22
  23 Stability Test of PAP
  24 +++++++++++++++++++++
  25
  26 Test Plan
  27 ---------
  28 The 72 hours stability test ran the following steps sequentially in a single threaded loop.
  29
  30 Setup Phase (steps running only once)
  31 """""""""""""""""""""""""""""""""""""
  32
  33 - **Create Policy for defaultGroup** - creates an operational policy using policy/api component
  34 - **Create NodeTemplate metadata for sampleGroup policy** - creates a node template containing metadata using policy/api component
  35 - **Create Policy for sampleGroup** - creates an operational policy that refers to the metadata created above using policy/api component
  36 - **Change defaultGroup state to ACTIVE** - changes the state of defaultGroup PdpGroup to ACTIVE
  37 - **Create/Update PDP Group** - creates a new PDPGroup named sampleGroup.
  38       A second instance of the PDP that is already spun up gets registered to this new group
  39 - **Check PdpGroup Query** - makes a PdpGroup query request and verifies that both PdpGroups are in ACTIVE state.
  40
  41 PAP Test Flow (steps running in a loop for 72 hours)
  42 """"""""""""""""""""""""""""""""""""""""""""""""""""
  43
  44 - **Check Health** - checks the health status of pap
  45 - **PAP Metrics** - Fetch prometheus metrics before the deployment/undeployment cycle
  46       Save different counters such as deploy/undeploy-success/failure counters at API and engine level.
  47 - **Check PdpGroup Query** - makes a PdpGroup query request and verifies that both PdpGroups are in the ACTIVE state.
  48 - **Deploy Policy for defaultGroup** - deploys the policy defaultDomain to defaultGroup
  49 - **Check status of defaultGroup policy** - checks the status of defaultGroup PdpGroup with the defaultDomain policy 1.0.0.
  50 - **Check PdpGroup Audit defaultGroup** - checks the audit information for the defaultGroup PdpGroup.
  51 - **Check PdpGroup Audit Policy (defaultGroup)** - checks the audit information for the defaultGroup PdpGroup with the defaultDomain policy 1.0.0.
  52 - **Check PdpGroup Query** - makes a PdpGroup query request and verifies that 2 PdpGroups are in the ACTIVE state and defaultGroup has a policy deployed on it.
  53 - **Deployment Update for sampleGroup policy** - deploys the policy sampleDomain in sampleGroup PdpGroup using pap api
  54 - **Check status of sampleGroup** - checks the status of the sampleGroup PdpGroup.
  55 - **Check status of PdpGroups** - checks the status of both PdpGroups.
  56 - **Check PdpGroup Query** - makes a PdpGroup query request and verifies that the defaultGroup has a policy defaultDomain deployed on it and sampleGroup has policy sampleDomain deployed on it.
  57 - **Check Audit** - checks the audit information for all PdpGroups.
  58 - **Check Consolidated Health** - checks the consolidated health status of all policy components.
  59 - **Check Deployed Policies** - checks for all the deployed policies using pap api.
  60 - **Undeploy policy in sampleGroup** - undeploys the policy sampleDomain from sampleGroup PdpGroup using pap api
  61 - **Undeploy policy in defaultGroup** - undeploys the policy defaultDomain from PdpGroup
  62 - **Check status of policies** - checks the status of all policies and make sure both the policies are undeployed
  63 - **Check PdpGroup Query** - makes a PdpGroup query request and verifies that PdpGroup is in the PASSIVE state.
  64 - **PAP Metrics after deployments** - Fetch prometheus metrics after the deployment/undeployment cycle
  65       Save the new counter values such as deploy/undeploy-success/failure counters at API and engine level, and check that the deploySuccess and undeploySuccess counters are increased by 2.
  66
  67 .. Note::
  68    To avoid putting a large Constant Timer value after every deployment/undeployment, the status API is polled until the deployment/undeployment
  69    is successfully completed, or until a timeout. This is to make sure that the operation is completed successfully and the PDPs gets enough time to respond back.
  70    Otherwise, before the deployment is marked successful by PAP, an undeployment could be triggered as part of other tests,
  71    and the operation's corresponding prometheus counter at engine level will not get updated.
  72
  73 Teardown Phase (steps running only once after PAP Test Flow is completed)
  74 """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
  75
  76 - **Change state to PASSIVE(sampleGroup)** - changes the state of sampleGroup PdpGroup to PASSIVE
  77 - **Delete PdpGroup sampleGroup** - delete the sampleGroup PdpGroup using pap api
  78 - **Change State to PASSIVE(defaultGroup)** - changes the state of defaultGroup PdpGroup to PASSIVE
  79 - **Delete policy created for defaultGroup** - deletes the operational policy defaultDomain using policy/api component
  80 - **Delete Policy created for sampleGroup** - deletes the operational policy sampleDomain using policy/api component
  81 - **Delete Nodetemplate metadata for sampleGroup policy** - deleted the nodetemplate containing metadata for sampleGroup policy
  82
  83 The following steps can be used to configure the parameters of test plan.
  84
  85 - **HTTP Authorization Manager** - used to store user/password authentication details.
  86 - **HTTP Header Manager** - used to store headers which will be used for making HTTP requests.
  87 - **User Defined Variables** -  used to store following user defined parameters.
  88
  89 ===========   ===================================================================
  90  **Name**      **Description**
  91 ===========   ===================================================================
  92  PAP_HOST      IP Address or host name of PAP component
  93  PAP_PORT      Port number of PAP for making REST API calls
  94  API_HOST      IP Address or host name of API component
  95  API_PORT      Port number of API for making REST API calls
  96 ===========   ===================================================================
  97
  98 The test was run in the background via "nohup", to prevent it from being interrupted:
  99
 100 .. code-block:: bash
 101
 102     nohup apache-jmeter-5.5/bin/jmeter -n -t stability.jmx -l stabilityTestResults.jtl &
 103
 104 Test Results
 105 ------------
 106
 107 **Summary**
 108
 109 Stability test plan was triggered for 72 hours. There were no failures during the 72 hours test.
 110
 111
 112 **Test Statistics**
 113
 114 =======================  =================  ==================  ==================================
 115 **Total # of requests**  **Success %**      **Error %**         **Average time taken per request**
 116 =======================  =================  ==================  ==================================
 117     102290                    100 %             0.15 %              782 ms
 118 =======================  =================  ==================  ==================================
 119
 120 .. Note::
 121
 122    There were 0.15% failures during the 72 hours test, due to the timing between the update of the metric "undeploySuccessCount" and the Undeploy itself.
 123    We suggest for the next test to increase the timeout timing up to 130s between "Undeploy policy in defaultGroup" and "PAP Metrics after deployments"
 124
 125 **JMeter Screenshot**
 126
 127 .. image:: pap-s3p-results/pap_stability_jmeter_results.png
 128
 129 **Memory and CPU usage**
 130
 131 The memory and CPU usage can be monitored by running "top" command in the PAP pod.
 132 A snapshot is taken before and after test execution to monitor the changes in resource utilization.
 133 Prometheus metrics is also collected before and after the test execution.
 134
 135 Memory and CPU usage before test execution:
 136
 137 .. image:: pap-s3p-results/pap_top_before_72h.png
 138
 139 :download:`Prometheus metrics before 72h test  <pap-s3p-results/pap_metrics_before_72h.txt>`
 140
 141 Memory and CPU usage after test execution:
 142
 143 .. image:: pap-s3p-results/pap_top_after_72h.png
 144
 145 :download:`Prometheus metrics after 72h test  <pap-s3p-results/pap_metrics_after_72h.txt>`
 146
 147 Performance Test of PAP
 148 ++++++++++++++++++++++++
 149
 150 Introduction
 151 ------------
 152
 153 Performance test of PAP has the goal of testing the min/avg/max processing time and rest call throughput for all the requests with multiple requests at the same time.
 154
 155 Setup Details
 156 -------------
 157
 158 The performance test is performed on a similar setup as Stability test. The JMeter VM will be sending a large number of REST requests to the PAP component and collecting the statistics.
 159
 160
 161 Test Plan
 162 ---------
 163
 164 Performance test plan is the same as the stability test plan above except for the few differences listed below.
 165
 166 - Increase the number of threads up to 10 (simulating 10 users' behaviours at the same time).
 167 - Reduce the test time to 2 hours.
 168 - Usage of counters (simulating each user) to create different pdpGroups, update their state and later delete them.
 169 - Removed the tests to deploy policies to newly created groups as this will need a larger setup with multiple pdps registered to each group, which will also slow down the performance test with the time needed for registration process etc.
 170 - Usage of counters (simulating each user) to create different drools policies and deploy them to defaultGroup.
 171       In the test, a thread count of 10 is used resulting in 10 different drools policies getting deployed and undeployed continuously for 2 hours.
 172       Other standard operations like checking the deployment status of policies, checking the metrics, health etc remains.
 173
 174 Run Test
 175 --------
 176
 177 Running/Triggering the performance test will be the same as the stability test. That is, launch JMeter pointing to corresponding *.jmx* test plan. The *API_HOST* , *API_PORT* , *PAP_HOST* , *PAP_PORT* are already set up in *.jmx*.
 178
 179 .. code-block:: bash
 180
 181     nohup apache-jmeter-5.5/bin/jmeter -n -t performance.jmx -l performanceTestResults.jtl &
 182
 183 Test Results
 184 ------------
 185
 186 Test results are shown as below.
 187
 188 **Test Statistics**
 189
 190 =======================  =================  ==================  ==================================
 191 **Total # of requests**  **Success %**      **Error %**         **Average time taken per request**
 192 =======================  =================  ==================  ==================================
 193 19886                    100 %              0.00 %              3107 ms
 194 =======================  =================  ==================  ==================================
 195
 196 **JMeter Screenshot**
 197
 198 .. image:: pap-s3p-results/pap_performance_jmeter_results.png