Skip to end of banner
Go to start of banner

PTF-EBSCONET Workflow

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Overview

This is initial report for EBSCONET workflow testing. The purpose of this document is to highlight KPI of EBSCONET workflow, find possible bottlenecks/ issues. Define baseline

Summary

[ A bulleted-list of the most important and relevant observations from the test results. What are the most important things the readers need to know about this testing effort? Some suggestions

  • Comparison to previous test or release of response times or API durations
  • Any notable changes
  • Particular response time or durations
  • Service memory and/or CPU utilization
  • RDS memory and/or CPU utilization 
  • Other interesting observations

]


used modules:

  • mod-organizations
  • mod-organizations-storage
  • mod-finance
  • mod-finance-storage
  • nginx-edge
  • mod-ebsconet
  • nginx-okapi
  • mod-orders
  • mod-orders-storage
  • okapi
  • mod-mod-notes
  • mod-configuration 
  • edge-orders

Recommendations & Jiras (Optional)

[ If there are recommendations for the developers or operations team, or anything worth calling out, list them here. Also include any Jiras created for follow-up work]

Test Runs 

[Table of tests with short descriptions. If there are motivations to run additional tests because of any reason, include a note column to explain]

Test #

VUsers

Data setLoad generator size Load generator Memory(GiB) 
  1. normal conditions
2 users
  • Number of order lines being renewed 1000
  • Number of orders being renewed 804
  • 4 of these orders have 50 POLs each - 800 orders with 1 POL each


t3.medium3
2. normal conditions2 users
  • Number of order lines being renewed 1000
  • Number of orders being renewed 804
  • 4 of these orders have 50 POLs each - 800 orders with 1 POL each


t3.medium3

3. extreme conditions

10 users
  • Number of order lines being renewed 5000
  • Number of orders being renewed 4804
  • 4 of these orders have 50 POLs each - 4800 orders with 1 POL each
t3.medium3
4 extreme conditions10 users
  • Number of order lines being renewed 5000
  • Number of orders being renewed 4804
  • 4 of these orders have 50 POLs each - 4800 orders with 1 POL each
t3.medium3

Results


Test #VUsersDurationError rate
127 min 10 s2.6% (52 calls)
227 min3.3% (67 calls)
3104 min 30 s1.14% (57 calls)
4104 min 10 s1.56% (78 calls)


Memory Utilization

[Description of notable observations of memory utilization with screenshots(of all modules and involved modules) and tables]



Nolana Avg

Nolana Min

Nolana Max

mod-circulation-storage24%23%25%
mod-patron-blocks34%33%34%

CPU Utilization 

[Description of notable observations of modules and instances CPU utilization with screenshots (of all modules and involved modules) and tables]



RDS CPU Utilization 


Additional information from module and database logs (Optional)

[ Although it is optional to look at logs it is always recommended to look at the logs to see if there were any errors,  exceptions, or warnings.  If there were any, create Jiras fo rthe module that generated the warnings/errors/exceptions]

Appendix

Infrastructure

PTF -environment ncp3-pvt

  • m6i.2xlarge EC2 instances located in US East (N. Virginia)us-east-1 
  • 2 instances of db.r6.xlarge database instances, one reader, and one writer
  • MSK ptf-kakfa-3 [ kafka configurations]
    • 4 m5.2xlarge brokers in 2 zones
    • Apache Kafka version 2.8.0

    • EBS storage volume per broker 300 GiB

    • auto.create.topics.enable=true
    • log.retention.minutes=480
    • default.replication.factor=3


Modules memory and CPU parameter

Modules

Version

Task Definition

Running Tasks 

CPU

Memory

MemoryReservation

MaxMetaspaceSize

Xmx

mod-organizations

1.6.0221281024896128700

mod-organizations-storage

4.4.022128

1024

896

128700

mod-finance

4.6.2221281024896128700

mod-finance-storage

8.3.1221281024896128700

nginx-edge

nginx-edge:2022.03.02121281024896N/AN/A

mod-ebsconet

1.4.0221281024896256700

nginx-okapi

nginx-okapi:2022.03.02121281024896N/AN/A

mod-orders

12.5.422102420481440256896
mod-orders-storage13.4.0221281024896128700
okapi4.14.713102416841440922922

mod-mod-notes

4.0.0221281024896128322
mod-configuration5.9.0321281024896128768

edge-orders

2.7.0221281024896128700

Methodology/Approach

[ List the high-level methodology that was used to carry out the tests.  This is important for complex tests that involve multiple workflows. It's important to inform readers of how the tests were performed so that they can comment on any flaw in the test approach or that they can try to reproduce the test results themselves.  For example:

  1. Start CICO test first
  2. Run a Data Import job after waiting for 10 minutes
  3. Run an eHoldings job after another 10 minutes
  4. On another tenant run another DI job after 30 minutes in

The steps don't need to be very specific because the details are usually contained in the participating workflow's README files (on GitHub).  However, anything worth calling out that was not mentioned elsewhere should be mentioned here.] 

Additional Screenshots of graphs or charts (Optional)

[ Optionally include additional screenshots of graphs on the Cloudwatch and Grafana dashboards for completeness sake. These don't have to be solely included in here but can be added in any section if they complement other graphs and fit the narrative. ]

  • No labels