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 an ONAP installation in the Policy tenant
  14 in the UNH lab, from the admin VM running the jmeter tool to inject the load.
  15
  16 General Setup
  17 *************
  18
  19 Agent VMs in this lab have the following configuration:
  20
  21 - 16GB RAM
  22 - 8 VCPU
  23
  24 Jmeter is run from the admin VM.
  25
  26 The drools-pdp container uses the JVM memory and CPU settings from the default OOM installation.
  27
  28 Other ONAP components exercised during the stability tests were:
  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 Stability Test of Policy PDP-D
  43 ******************************
  44
  45 PDP-D performance
  46 =================
  47
  48 The tests focused on the following use cases:
  49
  50 - vCPE
  51 - vDNS
  52 - vFirewall
  53
  54 For 72 hours the following 5 scenarios ran in parallel:
  55
  56 - vCPE success scenario
  57 - vDNS success scenario.
  58 - vFirewall success scenario.
  59 - vCPE failure scenario (simulates a failure scenario returned by simulated APPC recipient through DMaaP).
  60 - vDNS failure scenario (simulates a failure by introducing in the DCAE ONSET a non-existent vserver-name reference).
  61
  62 Five threads ran in parallel, one for each scenario, back to back with no pauses.   The transactions were initiated
  63 by each jmeter thread group.   Each thread initiated a transaction, monitored the transaction, and
  64 as soon as the transaction ending was detected, it initiated the next one.
  65
  66 The results are illustrated on the following graphs:
  67
  68 .. image:: images/s3p-drools-1.png
  69 .. image:: images/s3p-drools-2.png
  70 .. image:: images/s3p-drools-3.png
  71 .. image:: images/s3p-drools-4.png
  72
  73
  74 Commentary
  75 ==========
  76
  77 There is around 1% unexpected failures during the 72-hour run.   This can also be seen in the
  78 final output of jmeter:
  79
  80 .. code-block:: bash
  81
  82     summary = 37705505 in 72:00:56 =  145.4/s Avg:    30 Min:     0 Max: 20345 Err: 360852 (0.96%)
  83
  84 The 1% errors were found to be related to the nature of the run, where each one of the 5 use case
  85 threads run without pauses starting one after the other a new round of their assigned control loop.
  86 It has been found that at times, the release time of the lock (which requires DB operations) outruns
  87 the initiation of the next control loop (using the same resource), therefore the newly initiated control
  88 loop fails.  In reality, this scenario with the same resource being used back to back in consecutive control
  89 loop rounds will be unlikely.
  90
  91