Skip to end of banner
Go to start of banner

A few approaches to automation performance testing of DI

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 2 Next »

Currently, our DI does not work in the true parallel mode. This means that all DI processes load all chunks of files into Kafka and wait when the system handles all those chunks in sequential order (FIFO - first in, first out).

For now, DI can not import some specific chunks from Kafka related to a selected job or a user. The feature UXPROD-3471: OCLC single record import takes extended time to complete when large data import jobs are running is not implemented yet.

This means that we don't need to execute performance tests with the parallel load. We can add some parallel load to mod-inventory module, but this module is never loaded in real life in such a way as to impact import.

Based on the above, to automate DI performance testing we need:

  1. Set up Perf environment. This environment will be working all time and shared between a few teams, but only devops team should have permission to update and reconfigure this by request, but it is important to do it very quickly because performance testing is very time consuming and downtime during the next changes (configuring/updating the system, changing different parameters, changing the number of the Kafka topics, etc.) should be as little as possible. Some configuration examples: LCP performance testing, Folijet - Lotus Snapshot Performance testing
  2. Automatically create job profiles to DI (as usual we use PTF - Create 2 and Updates Success - 1 profiles). For this action, we can use Karate test and Jenkins job to start this test.
  3. Start one or more DIs in automatic mode. We should not start a new DI without checking the status of the previous DI: because the DI takes a lot of time and when we met some problems, we should analyze them before starting a new DI, otherwise, we might lose time and catch the same error. For automatic mode, we also can use Karate test and Jenkins job to start import and another Jenkins job (or the same) for analyzing the status of Job (Completed, not Completed, Completed with Errors).
  4. Would be good to have:
    1. assess to some graphical analytics tools: we need to check how much memory our modules use(s). This is also related to CPU resources and open DB connections.
    2. all logs should be collected in Kibana
    3. some tool for analyzing application metrics and traces (telemetry).


I propose to check the next approach:

  1. Create 1st Karate task to login and create 2 (create/update) Job Profiles;
  2. Create 2nd Karate task to:
    1. login;
    2. check is not any active task:
      1. is true → this Karate task should start the DI and wait for it to finish:
        1. finished with "Complete" status → next DI should be started.
        2. finished with "Completed with Errors" → the Karate task should be stopped.


!!! One of the problems I see is where to store files for 5K, 10K, 25K, 50K, 100K and 500K records. We need storage for 1.5GB.

  • No labels