...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
| Table of Contents |
|---|
Overview
...
Overview
The Data Import Task Force (DITF) implements a feature that splits large input MARC files into smaller ones, resulting in smaller jobs, so that the big files could be imported and be imported consistently. This document contaest 1. Test with 1, 2, and 3 tenants' concurrent jobs with configurins the results of performance tests on the feature and also an analysis the feature's performance with respect to the baseline tests. The following Jiras were implemented.
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
Summary
- The file-splitting feature is stable and offers more robustness to Data Import jobs even with the current infrastructure configuration. If there were failures, it's easier now to find the exact failed records to take actions on them.
- No stuck jobs in all tests performed.
- There were errors (see below) in some partial jobs, but they still completed so the entire job status is "Completed with error".
- Both of kinds of imports, create and update MARC BIBs worked well with this file-splitting feature enabled and also disabled.
- There is no performance degradations, jobs not getting slower, on single-tenant imports. On multi-tenants imports, performance is be a little better
- Duration for DI correlates with number of the records imported (100k records- 38 min, 250k - 1 hour 32 min, 500k - 3 hours 29 min).
- Multitenant DI could be performed successfully for up to 9 jobs in parallel. If jobs are big they will start one by one in order for each tenant but processed in parallel on 3 tenants. Small DI (1 record) could be finished faster not in order.
- No memory leak is suspected for all of the modules.
- Average CPU usage for mod-inventory -was 144%, mod-di-converter-storage was about 107%, and for all other modules did not exceed 100 %. We can observe spikes in CPU usage of mod-data-import at the beginning of the Data Import jobs up to 260%. Big improvement over previous version (without file-splitting) for 500K imports where mod-di-converter-storage's CPU utilization was 462% and other modules were above 100% and up to 150%.
- Approximately DB CPU usage is up to 95%.
Recommendations and Jiras
- One record on one tenant could be discarded with error: io.netty.channel.StacklessClosedChannelException.
Reproduces in both cases with and without splitting feature enabled in at least 30% of test runs with 500k record files and multitenant testing.Jira Legacy server System Jira serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key MODDATAIMP-748 - During the new Data Import splitting feature testing, items for update were discarded with the error: io.vertx.core.impl.NoStackTraceThrowable: Cannot get actual Item by id: org.folio.inventory.exceptions.InternalServerErrorException: Access for user 'data-import-system-user' (f3486d35-f7f7-4a69-bcd0-d8e5a35cb292) requires permission: inventory-storage.items.item.get. Less than 1% of records could be discarded due to missing permission for 'data-import-system-user'. Permission was not added automatically during the service deployment. I added permission manually to the database and the error does not occur anymore.
Jira Legacy server System Jira serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key MODDATAIMP-930 - UI issue, when canceled or completed with error Job progress bar cannot be deleted from the screen.
Jira Legacy server System Jira serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key MODDATAIMP-929 - Usage:
- Should not use less than 1000 for RECORDS_PER_SPLIT_FILE. The system is stable enough to ingest 1000 records consistently and smaller amounts will incur more overheads, resulting in longer jobs' durations. CPU utilization for mod-di-converter-storage for 500 RECORDS_PER_SPLIT_FILE(RPSF) = 160%, for 1000RPSF =180%, for 5K RPSF =380% and for 10K RPSF =433%, so in the case of selecting configurations 5K or 10K we recommend to add more CPU to mod-di-converter-storage service.
- When toggling the file-splitting feature, mod-source-record-storage, mod-source-record-manager's tasks need to be restarted.
- Keep in mind about the Kafka broker's disk size (as bigger jobs - up to 500K - can be run now), consecutive jobs may use up the disk quickly because the messages' retention time currently is set at 8 hours. For example with 300GB disk size, consecutive jobs of 250K, 500K, 500K sizes will exhaust the disk.
- More CPU could be allocated to mod-inventory and mod-di-converter-storage
Results
| Test # | Splitting Feature Enabled | Results | Splitting Feature Disabled | Results | Before Splitting Feature Deployed | Results | ||
|---|---|---|---|---|---|---|---|---|
| 1 | 100K MARC BIB Create | PTF - Create 2 | 37 min -39 min | Completed | 40 min | Completed | 32-33 minutes | Completed |
| 1 | 250K MARC BIB Create | PTF - Create 2 | 1 hour 32 min | Completed | 1 hour 41 min | Completed | 1 hour 33 min - 1 hour 57 min | Completed |
| 1 | 500K MARC BIB Create | PTF - Create 2 | 3 hours 29 min | Completed* | 3 hours 55 min | Completed | 3 hours 33 min | Completed |
| 2 | Multitenant MARC Create (100k, 50k, and 1 record) | PTF - Create 2 | 2 hours 40 min | Completed* | 2 hours 43 min | Completed* | 3 hours 1 min | Completed |
| 3 | CI/CO + DI MARC BIB Create (20 users CI/CO, 25k records DI on 3 tenants) | PTF - Create 2 | 24 min 18 sec | Completed | 31 min 31 sec | Completed | 24 min | Completed * |
| 4 | 100K MARC BIB Update (Create new file) | PTF - Updates Success - 1 | 58 min 25 sec 57 min 19 sec | Completed | 1 hour 3 min | Completed | - | - |
| 4 | 250K MARC BIB Update | PTF - Updates Success - 1 | 2 hours 2 min ** 2 hours 12 min | Completed with errors ** Completed | 1 hour 53 min | Completed | - | - |
| 4 | 500K MARC BIB Update | PTF - Updates Success - 1 | 4 hours 43 min 4 hours 38 minutes | Completed Completed | 5 hour 59 min | Completed | - | - |
...
** - up to 10 items were discarded with the error: io.vertx.core.impl.NoStackTraceThrowable: Cannot get actual Item by id: org.folio.inventory.exceptions.InternalServerErrorException: Access for user 'data-import-system-user' (f3486d35-f7f7-4a69-bcd0-d8e5a35cb292) requires permission: inventory-storage.items.item.get. Less than 1% of records could be discarded due to missing permission for 'data-import-system-user'. Permission was not added automatically during the service deployment. I added permission manually to the database and the error does not occur anymore.Jira Legacy server System Jira serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key MODDATAIMP-930
Test 1,2. 100k, 250K, 500k and Multitenant MARC BIB Create
Memory Utilization
This has memory utilization increasing due to previous modules restarting (everyday cluster shot down process) no memory leak is suspected for DI modules.
...
Test#2 Multitenant DI (9 concurrent jobs)
Service CPU Utilization
MARC BIB CREATE
Average CPU usage for mod-inventory -was 144%, mod-di-converter-storage was about 107%, and for all other modules did not exceed 100 %. We can observe spikes in CPU usage of mod-data-import at the beginning of the Data Import jobs up to 260%.
Test#1 500k records DI
Test#2 Multitenant
Instance CPU Utilization
Test#1 500k records DI
Test#2 Multitenant DI (9 concurrent jobs)
RDS CPU Utilization
MARC BIB CREATE
Approximately DB CPU usage is up to 95%
...
Maximal DB CPU usage is about 95%
RDS Database Connections
MARC BIB CREATE
For DI job Create- 535 connections count.
Test#1 500k records DI
Test#2 Multitenant
Test 3 With CI/CO 20 users and DI 25k records on each of the 3 tenants Splitting Feature Enabled &
Splitting Feature Disabled
Response time without DI Before Splitting Feature Deployed | Response time with DI Before Splitting Feature Deployed | Response time without DI Splitting Feature disabled | Response time with DI Splitting Feature disabled | Response time without DI Splitting Feature enabled | Response time with DI (Average) Splitting Feature enabled | |
|---|---|---|---|---|---|---|
| Check-In | 0.517s | 1.138s | 0.542s | 1.1s | 0.505s | 1.067s |
| Check-Out | 0.796s | 1.552s | 0.841s | 1.6s | 0.804s | 1.48s |
...
* - Same approach testing DI: 3 DI jobs total on 3 tenants without CI/CO. Start the second job after the first one reaches 30%, and start another job on a third tenant after the first job reaches 60% completion. DI file size: 25k
Response time graph
With CI/CO 20 users and DI 25k records on each of the 3 tenants Splitting Feature Disabled
ocp3-mod-data-import:12
Data Import Robustness Enhancement
...
* T1 - "00:33:35.1" Error T2 - "01:23:36.144" T3 - "01:16:26.391" on the first tenantproccesing stoped wit error "io.vertx.core.impl.NoStackTraceThrowable: Connection is not active now, current status: CLOSED "
it caused the spike of CPU utilization on Kafka (tenant cluster) up to 94%
Instance CPU Utilization
Test 1. Test with 1, 2, and 3 tenants' concurrent jobs with configuration RECORDS_PER_SPLIT_FILE = 500, 2 runs for each test. The maximal CPU Utilization value is 38%.
...
Test 2. Test with 1, 2, and 3 tenants' concurrent jobs with configuration RECORDS_PER_SPLIT_FILE = 10K, 2 runs for each test. The maximal CPU Utilization value is 37%.
Memory Utilization
Test 1. Test with 1, 2, and 3 tenants' concurrent jobs with configuration RECORDS_PER_SPLIT_FILE = 500, 2 runs for each test.
...
Memory utilization rich maximal value for mod-source-record-storage-b 88% and for mod-source-record-manager-b 85%.
Test 2. Test with 1, 2, and 3 tenants' concurrent jobs with configuration RECORDS_PER_SPLIT_FILE = 10K, 2 runs for each test.
Service CPU Utilization
Test 1. Test with 1, 2, and 3 tenants' concurrent jobs with configuration RECORDS_PER_SPLIT_FILE = 500, 2 runs for each test.
...
Test 2. Test with 1, 2, and 3 tenants' concurrent jobs with configuration RECORDS_PER_SPLIT_FILE = 10K, 2 runs for each test.
RDS CPU Utilization
Test 1. Test with 1, 2, and 3 tenants' concurrent jobs with configuration RECORDS_PER_SPLIT_FILE = 500, 2 runs for each test. Maximal CPU Utilization = 95%
...
Test 2. Test with 1, 2, and 3 tenants' concurrent jobs with configuration RECORDS_PER_SPLIT_FILE = 10K, 2 runs for each test. Maximal CPU Utilization = 94%
RDS Database Connections
Test 1. Test with 1, 2, and 3 tenants' concurrent jobs with configuration RECORDS_PER_SPLIT_FILE = 500, 2 runs for each test.
...
Test 2. Test with 1, 2, and 3 tenants' concurrent jobs with configuration RECORDS_PER_SPLIT_FILE = 10K, 2 runs for each test. Maximal CPU Utilization = 94%
Retesting DI file-splitting feature on Poppy release
Retest the DI feature to be sure that the new changes have not affected performance negatively. Retest the DI file-splitting feature for the following scenarios:
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
Brief comparison summary
The duration of the import date has increased, in particular(diff= Poppy time processing - Orchid time processing ):
...
Release: Orchid DI Duration with CI/CO | Release: Poppy DI Duration with CI/CO | |
|---|---|---|
| Tenant _1 | 16 min 53 sec | 34 min 55 sec |
| Tenant _2 | 20min 39 sec | 27 min 39 sec |
| Tenant _3 | 17min 54 sec | 25 min 17 sec |
Resource utilization during testing
Test 1.1. Data-import of 250K records file with "PTF - Create 2" job profile
Service CPU Utilization
The shark spike of CPU at the beginning of test 1, We see similar behavior in all of the DI tests. СPU consumption was uniform during the test.
Memory Utilization
The memory consumption was not affected, the mod-source-records-manager service increased the memory usage from 45% to 60% during the test, but after the test, the memory started to return to the pre-test value.
RDS CPU Utilization
Consumption of the database CPU was 97% throughout the test
RDS Database Connections
The average number of DB connections during the test was about 550.
Test 1.2. Data-import of 250K records file with "PTF - Update" job profile
Service CPU Utilization
СPU consumption was stable during the test, except mod-inventory service at the beginning of the test the CPU usage was about 140% at the end of the test CPU value was about 200%. 
Memory Utilization
The memory was stable and without memory leaks.
RDS CPU Utilization
Consumption of the database CPU was 97% throughout the test
RDS Database Connections
The average number of DB connections during the test was about 550.
Test 1.3. Multitenant MARC Create (100k, 50k, and 1 record)
Service CPU Utilization
СPU consumption was stable during the test. However, in the last hour of the test, the services mod-inventory and mod-quick-mark increare the CPU utilization by 75%
Memory Utilization
The memory was stable and without memory leaks.
RDS CPU Utilization
Consumption of the database CPU was 96% throughout the test
RDS Database Connections
The average number of DB connections during the test was about 800.
Test 1.4. Data-import of 250K records file with "PTF - Update" job profile
Service CPU Utilization
Memory Utilization
The memory was stable and without memory leaks.
RDS CPU Utilization
Consumption of the database CPU was 96% throughout the test
RDS Database Connections
The average number of DB connections during the test changed from 400 to 1200.
CICO responce time graph
Retesting DI file-splitting feature on Poppy release with Refresh Token Rotation (RTR) and file-splitting feature
The goal of the tests was to investigate how the file-splitting feature caused Data-import on Poppy release and the impact of Refresh Token Rotation (RTR). The tests were performed on ocp3(Poppy), pcp1(Poppy) and ncp5(Orchid) environments.
Refresh Token Rotation (RTR)Jira Legacy server System Jira serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key PERF-723
Brief comparison summary
Refresh Token Rotation (RTR)-3c2e-90f1-ee9b165564fc key PERF-723
Brief comparison summary
- Refresh Token Rotation configuration does not affect the data import process in any way, whether creating or updating a profile.
- In the Poppy release 250,000 records of data import with PTF - Create-2 job profile failed, and 50,000 records of data import with PTF - Updates Success - 1 job profile also failed in all of the tests, except configuration when FSF=ture;
- Data import works slowly on Poppy compared to the Orchid
- As the number of records in the file for data import increases, the processing time also increases. Up to 25,000 records, the duration of the data import is approximately the same.
- In the Poppy release data-import with an enabled file-splitting feature works slower compared to data-import with a disabled file-splitting feature.
- Data import is performed approximately 5% faster when the file-splitting feature parameters are absent in the task definition configuration.
Test results
| DI tests/ Configuration | ncp5 Orchid | ocp3 FSF true without RTR token | ocp3 FSF false without RTR token | *ocp3 FSF deleted without token | ocp3 FSF false AT =RT= 300; | ocp3 FSF false AT =RT= 1000000000 | pcp1 FSF false AT =RT= 10000000 | pcp1 FSF false without token retest* |
|---|---|---|---|---|---|---|---|---|
| 250k_bib_Create_1.mrc | not tested | not tested | failed | failed | failed | failed | failed | failed |
| 100k_bib_Create.mrc | 00:41:41 | 00:54:32 | 00:54:36 | 00:53:59 | 00:48:56 | 00:54:42.05 | 00:47:17 | "01:01:39" |
| 50k_bib_Create.mrc | 00:19:43 | 00:30:40 | 00:3025:2039 | 00:22:17 | 00:27:05 | 00:30:09 | 00:21:45 | 00:20:46 |
| 25k_bib_Create.mrc | 00:10:11 | 00:13:53 | 00:1712:2046 | 00:10:33 | 00:12:42 | 00:13:25 | 00:11:54 | 00:10:53 |
| 10k_bib_Create.mrc | 00:04:19 | 00:07:22 | 00:05:35 | 00:04:38 | not tested | 00:05:33. | 00:04:42 | 00:04:36 |
| 5k_bib_Create.mrc | 00:02:35 | 00:04:31 | 00:02:43 | 00:02:55 | not tested | 00:03:07 | 00:02:55 | 00:02:30 |
| 1k_bib_Create.mrc | not tested | not tested | not tested | not tested | not tested | not tested | 00:00:54 | not tested |
| DI-25K-Update.mrc | not tested | not tested | finished successfully | failed | failed | finished successfully | failed | finished successfully |
Column with "pcp1 FSF false without token" has testing results on the configuration similar to "ocp3 FSF deleted without token".
Resource utilization during testing
Service CPU utilization during the Data-import process
The next data import jobs were carried out
1) 5k_bib_Create 2) 10k_bib_Create 3) 25k_bib_Create 4) 50k_bib_Create 5) 50k_bib_Create 6) 100k_bib_Create 7) 50k_bib_Create 8) 25k_bib_Create 9) 25k_bib_Update 10) 50k_bib_Update(stopped)
CPU utilization was stable during all jobs, but some spikes of data-import jobs were at the beginning of all tests.
| Expand | ||
|---|---|---|
| ||
|
Memory Utilization
Most of the modules were stable during the test, and no memory leak is suspected for DI modules, except mod-inventory-b which consumed about 92% of memory during all DI processes. 
RDS CPU Utilization
Maximal CPU Utilization = 95%
RDS Database Connections
The maximal number of DB connections during the tests was about 580.
Database load
Top SQL queries
Appendix
Infrastructure ocp3 with the "Bugfest" Dataset
Records count :
- tenant0_mod_source_record_storage.marc_records_lb = 9674629
- tenant2_mod_source_record_storage.marc_records_lb = 0
- tenant3_mod_source_record_storage.marc_records_lb = 0
- tenant0_mod_source_record_storage.raw_records_lb = 9604805
- tenant2_mod_source_record_storage.raw_records_lb = 0
- tenant3_mod_source_record_storage.raw_records_lb = 0
- tenant0_mod_source_record_storage.records_lb = 9674677
- tenant2_mod_source_record_storage.records_lb = 0
- tenant3_mod_source_record_storage.records_lb = 0
- tenant0_mod_source_record_storage.marc_indexers = 620042011
- tenant2_mod_source_record_storage.marc_indexers = 0
- tenant3_mod_source_record_storage.marc_indexers = 0
- tenant0_mod_source_record_storage.marc_indexers with field_no 010 = 3285833
- tenant2_mod_source_record_storage.marc_indexers with field_no 010 = 0
- tenant3_mod_source_record_storage.marc_indexers with field_no 010 = 0
- tenant0_mod_source_record_storage.marc_indexers with field_no 035 = 19241844
- tenant2_mod_source_record_storage.marc_indexers with field_no 035 = 0
- tenant3_mod_source_record_storage.marc_indexers with field_no 035 = 0
- tenant0_mod_inventory_storage.authority = 4
- tenant2_mod_inventory_storage.authority = 0
- tenant3_mod_inventory_storage.authority = 0
- tenant0_mod_inventory_storage.holdings_record = 9592559
- tenant2_mod_inventory_storage.holdings_record = 16
- tenant3_mod_inventory_storage.holdings_record = 16
- tenant0_mod_inventory_storage.instance = 9976519
- tenant2_mod_inventory_storage.instance = 32
- tenant3_mod_inventory_storage.instance = 32
- tenant0_mod_inventory_storage.item = 10787893
- tenant2_mod_inventory_storage.item = 19
- tenant3_mod_inventory_storage.item = 19
PTF -environment ocp3
- 10 m6i.2xlarge EC2 instances located in US East (N. Virginia)us-east-1
2 database instances, one reader, and one writer
Name API Name Memory GIB vCPUs max_connections R6G Extra Large db.r6g.xlarge 32 GiB 4 vCPUs 2731 - MSK ptf-kakfa-3
- 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
- Kafka topics partitioning: - 2 partitions for DI topics
...
| Module | Task Def. Revision | Module Version | Task Count | Mem Hard Limit | Mem Soft limit | CPU units | Xmx | MetaspaceSize | MaxMetaspaceSize | R/W split enabled |
| mod-circulation-storage | 16 | mod-circulation-storage:17.1.0 | 2 | 2880 | 2592 | 1536 | 1814 | 384 | 512 | FALSE |
| mod-source-record-storage | 13 | mod-source-record-storage:5.7.0 | 2 | 5600 | 5000 | 2048 | 3500 | 384 | 512 | FALSE |
| mod-calendar | 8 | mod-calendar:2.5.0 | 2 | 1024 | 896 | 128 | 768 | 88 | 128 | FALSE |
| mod-inventory | 13 | mod-inventory:20.1.0 | 2 | 2880 | 2592 | 1024 | 1814 | 384 | 512 | FALSE |
| mod-circulation | 10 | mod-circulation:24.0.0 | 2 | 2880 | 2592 | 1536 | 1814 | 384 | 512 | FALSE |
| mod-di-converter-storage | 9 | mod-di-converter-storage:2.1.0 | 2 | 1024 | 896 | 128 | 768 | 88 | 128 | FALSE |
| mod-pubsub | 10 | mod-pubsub:2.11.0 | 2 | 1536 | 1440 | 1024 | 922 | 384 | 512 | FALSE |
| mod-users | 10 | mod-users:19.2.0 | 2 | 1024 | 896 | 128 | 768 | 88 | 128 | FALSE |
| mod-patron-blocks | 10 | mod-patron-blocks:1.9.0 | 2 | 1024 | 896 | 1024 | 768 | 88 | 128 | FALSE |
| mod-source-record-manager | 15 | mod-source-record-manager:3.7.0 | 2 | 5600 | 5000 | 2048 | 3500 | 384 | 512 | FALSE |
| mod-quick-marc | 8 | mod-quick-marc:5.0.0 | 1 | 2288 | 2176 | 128 | 1664 | 384 | 512 | FALSE |
| nginx-okapi | 8 | nginx-okapi:2023.06.14 | 2 | 1024 | 896 | 128 | 0 | 0 | 0 | FALSE |
| okapi-b | 9 | okapi:5.1.1 | 3 | 1684 | 1440 | 1024 | 922 | 384 | 512 | FALSE |
| mod-feesfines | 9 | mod-feesfines:19.0.0 | 2 | 1024 | 896 | 128 | 768 | 88 | 128 | FALSE |
| mod-notes | 8 | mod-notes:5.1.0 | 2 | 1024 | 896 | 128 | 952 | 384 | 512 | FALSE |
| pub-okapi | 8 | pub-okapi:2023.06.14 | 2 | 1024 | 896 | 128 | 768 | 0 | 0 | FALSE |
| mod-data-import | 36 | 579891902283.dkr.ecr.us-east-1.amazonaws.com/folio/mod-data-import:3.0.3 | 1 | 2048 | 1844 | 256 | 1292 | 384 | 512 | FALSE |
| mod-search | 31 | 579891902283.dkr.ecr.us-east-1.amazonaws.com/folio/mod-search:3.0.0 | 2 | 2592 | 2480 | 2048 | 1440 | 512 | 1024 | FALSE |
| mod-configuration | 9 | mod-configuration:5.9.2 | 2 | 1024 | 896 | 128 | 768 | 88 | 128 | FALSE |
| mod-bulk-operations | 8 | mod-bulk-operations:1.1.0 | 2 | 3072 | 2600 | 1024 | 1536 | 384 | 512 | FALSE |
| edge-ncip | 8 | edge-ncip:1.9.0 | 2 | 1024 | FALSE | |||||
| mod-inventory-storage | 8 | mod-inventory-storage:27.0.0 | 2 | 8961 | FALSE |
Methodology/Approach
To set splitting feature: Detailed Release Notes for Data Import Splitting Feature
...