# Barrage testing
# Install the initial files
Create a folder
myProject/util-vsc/barrage
.Copy all the files from
COURSE-FILES/3.2-barrage-testing
into this folder.In a VSCode Terminal run these commands:
cd /workspace/myProject/util-vsc/barrage
npm install
./1.test-hello.sh
2
3
Stretch the terminal to be as large as you can make it, then run
./1.ping.sh
.Press 's' to start the test.
So what is it doing?
Each cell on the grid represents a seperate transaction. Your server is called to start each transaction, and the cell color and letter gets changed. The barrage tester provided a webhook and keeps track of the transactions, so when it receives notification of a transaction copmpleting it places a tick in the relevant position on the grid.
- The 'h' command will give you the valid commands, but in short, use 't' to set the number of tests, and then 'c' to try to get it to fit on the screen. So for example 't 10000' will set ten thousands transactions, and then hopefully 'c 250' will stop it making a mess of the page.
# Waiting transactions
Run ./2.example-pipeline.sh
and starting the test.
You will see the entire screen covered with the letter 'R'.
If you go to the queues page on MONDAT you will see that node group 'slave1' has about ten thousand transactions queued, but it has zero workers, because we've never started a server for slave1.
We'll do that in a later section, but for now we'll just leave these in the queue.
One way of handling back end outages is to continue to accept and queue transactions, but turn off the workers feeding them to the back end. In this way we don't fail the transactions - we just buffer them up until they can be processed.
This barrage tester can help you check that all the transactions complete correctly, as you experiment with various failure scenarios.
# Pre-production tests
Before putting any system into production, you should stress the system using your load testing scripts, and then run this barrage test. As the system is placed under increasing stress you may see it stutter. Ideally you place the high load pipelines in node groups behind their own queues, and you can control how much work they take on by adjusting the number of workers.
Exercise
Create a test for myPipeline
.