back

Configuring and performing load testing for the platform

This page outines the resources and approach to implement load a and performance testing as a core part of the platform functionality. Here are some resource overviews:

• https://techbeacon.com/app-dev-testing/web-performance-testing-18-free-open-source-tools-consider
• https://www.blazemeter.com/blog/open-source-load-testing-tools-which-one-should-you-use
• https://octoperf.com/blog/2017/11/21/open-source-load-testing-tools

Out of these the following seems strong: jmeter locust.io

Approach

1. One user story will be regarded as one activity. E.g Loading the application, Login, New instance workflow creation, opening a profile etc.

2. We will write a setup script which will read setup table from MySQL and create user accounts, create kwantu_local DB in the main database, and also it will create create kwantu_local_browser and kwantu_local_dataset DB in the test database for the user.

3. Setup script will also read the activities to be performed in the current test session, accordingly it will create required documents in kwantu_local_dataset DB where document id will be suffixed by revision ID, so that we can have different revisions of the document. In this process script will also manage the UUIDs used in the document so that it should not conflict.

4. We will log network calls for each activity using some network monitoring plugin for a single user.

5. We will filter out the required calls from that log as per our need.

6. Now we will run our test script to perform actual test. This script will read the activities to be performed in this session. We can combine multiple activities in one session as needed.

7. Test script will read the setup that for how many users what all activities to be performed. It will start each user thread with a gap of 30 seconds initially so that it simulates the actual production behaviour.

8. Test script will start shooting network calls as it comes in the flow with the correct time gap as per timestamp logged in the activity queries table.

9. In the calls, test script will replace the parameters passed to the server with the correct ones. Also the post and put calls will be replaced by a trigger call, where it will actually pick the data packet from kwantu_local_dataset database and save it to kwantu_local_browser database with the correct id by removing the revision number from the ID. Then it will trigger the replication from kwantu_local_browser DB to kwantu_local DB, which will simulate the replication and transaction manager will then follow the normal route.

10. We need to finalise monitoring tools which will collect the statistical data for network, memory and CUP utilisation on node and couchDB server.