[FOLIO-1052] Performance testing Created: 04/Feb/18  Updated: 18/Jan/19

Status: Open
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Task Priority: P3
Reporter: shale99 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: File inventory_csv_with_fulldisplay_limit_offset.jmx     Microsoft Word inventory_queries.csv     PNG File jmeter configuration.png    
Sprint:
Development Team: Core: Platform

 Description   

These are initial thoughts about adding performance tests to folio modules. We have done alot of work optimizing mod-inventory-storage to perform on millions of instances. We want to make sure we maintain that performance even when changes to the database / queries need to be made to support new functionality / improve existing functionality

1. set up an existing environment with 3M records - each module will need to provide a way to load relevant data. for example, mod-inv-storage may use the data loader to load the harvard data with some scripts to load holdings and item info (will attach examples for that below) - i dont believe we will have too many modules managing that amount of data.
a. the environment should be static - in aws, this means we can potentially create an image with our own postgres installation and the 3M records. and bring it up for testing and down when tests complete. Will need to get updated manually / custom script when schema changes are needed (this is similar to an upgrade script that should be supported by rmb modules OOTB - so this may potentially be used and exercised). but re-loading data should be done occasionally and not daily or even weekly, unless changes are needed (so this can be scripted / sql'd / if needed for production - this can be additional functionality added to the module (loading data))
2. jmeter script template - a template that can run a GET with cql and then a random full display on the returned results - with perf configurable thresholds for each of the two request types - including avg, std, saved to csv for reference - for example, we can start with a baseline for instances based on the existing implementation - run on a per git pull request. high response times should block? the merge...
a. it should take a couple of minutes to get the image up and running (unless it is always running), and running a 50-100 query sanity query file should not take more then a minute or two to run

when a change to an sql / db is needed - implement the unsupported sql in the module using postgresClient select / mutate functions and if a decision is made that the functionality should be supported by rmb, add to rmb and migrate to that rmb version in next release



 Comments   
Comment by shale99 [ 05/Feb/18 ]

the attached jmeter script is a modified version of the script that can be found at FOLIO-1019 Closed
0. login to the target URL
1. it will run (in a single thread) a list of queries found in a file as a warm up phase
a. it will verify that the return code was 200 for each query
2. it will then re-run the list of queries
3. for every query
a. it will verify that the return code was 200
b. verify that the response time was lower than the defined threshold
c. will randomly pick a result from the returned json and based on the uuid request the full display
i. verify that the response time for the full display is lower then the defined threshold
ii. verify that the return code was 200
4. expose statistics
a. per request
b. for the entire run (std, avg...)
the script is generic

inventory_csv_with_fulldisplay_limit_offset.jmx

inventory_queries.csv

this is an important first step and one that we can probably get out the door pretty quickly by integrating this into jenkins. we need to decide on the static environment for a specific module (for example - folio-alpha2 ) and load the data - for inventory , we are already doing this in folio-alpha - so this is basically a clone of that.

Generated at Thu Feb 08 23:10:28 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.