docs/development/devtools/drools-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 .. _drools-s3p-label:
   6
   7 .. toctree::
   8    :maxdepth: 2
   9
  10 Policy Drools PDP component
  11 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
  12
  13 Both the Performance and the Stability tests were executed against a default ONAP installation in the policy-k8s tenant in the windriver lab, from an independent VM running the jmeter tool to inject the load.
  14
  15 General Setup
  16 *************
  17
  18 The kubernetes installation allocated all policy components in the same worker node VM and some additional ones.
  19 The worker VM hosting the policy components has the following spec:
  20
  21 - 16GB RAM
  22 - 8 VCPU
  23 - 160GB Ephemeral Disk
  24
  25 The standalone VM designated to run jmeter has the same configuration.  The jmeter JVM
  26 was instantiated with a max heap configuration of 12G.
  27
  28 Other ONAP components used during the stability tests are:
  29
  30 - Policy XACML PDP to process guard queries for each transaction.
  31 - DMaaP to carry PDP-D and jmeter initiated traffic to complete transactions.
  32 - Policy API to create (and delete at the end of the tests) policies for each
  33   scenario under test.
  34 - Policy PAP to deploy (and undeploy at the end of the tests) policies for each scenario under test.
  35
  36 The following components are simulated during the tests.
  37
  38 - SO actor for the vDNS use case.
  39 - APPC responses for the vCPE and vFW use cases.
  40 - AAI to answer queries for the use cases under test.
  41
  42 In order to avoid interferences with the APPC component while running the tests,
  43 the APPC component was disabled.
  44
  45 SO, and AAI actors were simulated within the PDP-D JVM by enabling the
  46 feature-controlloop-utils before running the tests.
  47
  48 PDP-D Setup
  49 ***********
  50
  51 The kubernetes charts were modified previous to the installation with
  52 the changes below.
  53
  54 The feature-controlloop-utils was started by adding the following script:
  55
  56 .. code-block:: bash
  57
  58     oom/kubernetes/policy/charts/drools/resources/configmaps/features.pre.sh:
  59
  60     #!/bin/bash
  61     bash -c "features enable controlloop-utils"
  62
  63 Stability Test of Policy PDP-D
  64 ******************************
  65
  66 The 72 hour stability test happened in parallel with the stability run of the API component.
  67
  68 Worker Node performance
  69 =======================
  70
  71 The VM named onap-k8s-09 was monitored for the duration of the 72 hours
  72 stability run.  The table below show the usage ranges:
  73
  74 .. code-block:: bash
  75
  76     NAME          CPU(cores)   CPU%
  77     onap-k8s-09   <=1214m      <=20%
  78
  79 PDP-D performance
  80 =================
  81
  82 The test set focused on the following use cases:
  83
  84 - vCPE
  85 - vDNS
  86 - vFirewall
  87
  88 For 72 hours the following 5 scenarios ran in parallel:
  89
  90 - vCPE success scenario
  91 - vCPE failure scenario (failure returned by simulated APPC recipient through DMaaP).
  92 - vDNS success scenario.
  93 - vDNS failure scenario.
  94 - vFirewall success scenario.
  95
  96 Five threads ran in parallel, one for each scenario.   The transactions were initiated
  97 by each jmeter thread group.   Each thread initiated a transaction, monitored the transaction, and
  98 as soon as the transaction ending was detected, it initiated the next one, so back to back with no
  99 pauses.
 100
 101 All transactions completed successfully as it was expected in each scenario, with no failures.
 102
 103 The command executed was
 104
 105 .. code-block:: bash
 106
 107     ./jmeter -n -t /home/ubuntu/drools-applications/testsuites/stability/src/main/resources/frankfurt/s3p.jmx  -l /home/ubuntu/jmeter_result/jmeter.jtl -e -o /home/ubuntu/jmeter_result > /dev/null 2>&1
 108
 109 The results were computed by taking the ellapsed time from the audit.log
 110 (this log reports all end to end transactions, marking the start, end, and
 111 ellapsed times).
 112
 113 The count reflects the number of successful transactions as expected in the
 114 use case, as well as the average, standard deviation, and max/min.   An histogram
 115 of the response times have been added as a visual indication on the most common
 116 transaction times.
 117
 118 vCPE Success scenario
 119 =====================
 120
 121 ControlLoop-vCPE-48f0c2c3-a172-4192-9ae3-052274181b6e:
 122
 123 .. code-block:: bash
 124
 125     Max: 4323 ms, Min: 143 ms, Average: 380 ms [samples taken for average: 260628]
 126
 127 .. image:: images/ControlLoop-vCPE-48f0c2c3-a172-4192-9ae3-052274181b6e.png
 128
 129
 130 vCPE Failure scenario
 131 =====================
 132
 133 ControlLoop-vCPE-Fail:
 134
 135 .. code-block:: bash
 136
 137    Max: 3723 ms, Min: 148 ms, Average: 671 ms [samples taken for average: 87888]
 138
 139 .. image:: images/ControlLoop-vCPE-Fail.png
 140
 141 vDNS Success scenario
 142 =====================
 143
 144 ControlLoop-vDNS-6f37f56d-a87d-4b85-b6a9-cc953cf779b3:
 145
 146 .. code-block:: bash
 147
 148    Max: 6437 ms, Min: 19 ms, Average: 165 ms [samples taken for average: 59259]
 149
 150 .. image:: images/ControlLoop-vDNS-6f37f56d-a87d-4b85-b6a9-cc953cf779b3.png
 151
 152 vDNS Failure scenario
 153 =====================
 154
 155 ControlLoop-vDNS-Fail:
 156
 157 .. code-block:: bash
 158
 159     Max: 1176 ms, Min: 4 ms, Average: 5 ms [samples taken for average: 340810]
 160
 161 .. image:: images/ControlLoop-vDNS-Fail.png
 162
 163 vFirewall Success scenario
 164 ==========================
 165
 166 ControlLoop-vFirewall-d0a1dfc6-94f5-4fd4-a5b5-4630b438850a:
 167
 168 .. code-block:: bash
 169
 170     Max: 4016 ms, Min: 177 ms, Average: 644 ms [samples taken for average: 36460]
 171
 172 .. image:: images/ControlLoop-vFirewall-d0a1dfc6-94f5-4fd4-a5b5-4630b438850a.png