AISM Platform Load Test For SCU4 with DI PoC

monitor-2021-07-21_11-22-paxdelay-2sec

test run parameters:

• count: 600
• paxdelay: 2 seconds
• groupsize: 100
• groupdelay: 10 seconds

outcomes:

• paxwait: 600 pass 100%
• purchase plan: 562 pass 93.6%

anomalies:

• Data includes 1 additional device outside the automated test was connected to the pax network and registered an additional purchase.

The process:

Devices are simulated using headless browsers running on a cisco blade center. Each browser is run in a container with its own MAC address and DHCP-retrieved IP address. The containers are created and perform dhcp prior to the test. (This process is not included in the results.)

One headless browser is started every 2 seconds. After 100 browsers have been started, a delay of 10 seconds is inserted to provide a short amount of time for the system to recover from some of the load. (There is a balance here in simulating enough load in a short period of time to be useful, but not overloading the server with an entirely unrealistic situation.)

Each headless browser:

1. Tries to talk to the web
2. Gets captured and redirected to the DI portal
3. Sends some traffic to the DI portal
4. Triggers pax-wait
5. 'Purchases' on the ground ISP page
6. Loads an 'idle' page from the internet that cycles between 2 large non-cachable images (of cats, of course) in order to create some data flow.
7. Stays on the above page for a while. Then it stops that page and will hit the idle-timeout some time later.

This load test run is right on the edge of failing. With a delay of 2 seconds between passenger device 'kick off', we see a 93% success rate. (If we drop that delay to 1 second, we see mass failure. If we increase the delay to 3 seconds we see 100% success.) Given that this is an un-optimized prototype system, and we have 600 passenger devices represented, we feel comfortable that the final integrated system should support the passenger loads expected on KAL.

Notes:

• There was a problem with the idle-timeout during the run. This was caused by a bug in the ground system used for the load test. It doesn't have any impact on the aircraft or the overall results.
• The SNMP errors in the PM OID chart are normal behavior. The load test system hits the snmp daemon harder than normal flight loads, and it falls behind at times.

Load

* Values of -1 are an indication of an SNMP read error.

Monitoring

SCU Host (Hardware)

UCP/AM (VM hosted by SCU)

PM (VM hosted by UCP)

Load Test Infrastructure

Docker machine that hosts PAX Device containers