Skip to content

Load testing template for Direct Transfer Imports

This cats as a template when load testing for Direct transfer was tested, so this is being documented here.

Load Testing Template: User Mapping for Direct Transfer

Objective

To assess the performance and resource impact of the user mapping feature in Direct Transfer, focusing on the creation of placeholder users and the reassignment of contributions.

Test Environment

  • Use a test server (staging or 3k instance)
  • Ensure the feature flags importer_user_mapping and bulk_import_importer_user_mapping are enabled

Test Scenarios

1. Massive Simultaneous Direct Transfer Imports

Setup

  • Prepare multiple large projects for import (e.g., VueJS, NodeJS, Rspec Rails)
  • Each project should have:
    • 1000s of unique users (aim for at least 10,000 users)
    • Large number of issues, merge requests, and comments

Execution

  • Initiate simultaneous imports of these projects
  • Monitor the creation of placeholder users and saving of contribution references

Metrics to Collect

  • Total import duration
  • Number of placeholder users created
  • Number of contribution references saved
  • Database query count and duration
  • CPU usage
  • Memory usage (RSS) of Sidekiq processes
  • Redis usage

2. Large-Scale Contribution Reassignment

Setup

  • Use projects with placeholder users already created
  • Ensure each placeholder user has 10,000+ contributions

Execution

  • Trigger simultaneous reassignments of placeholder contributions

Metrics to Collect

  • Reassignment duration per user
  • Total reassignment duration
  • Number of contributions reassigned
  • Database query count and duration
  • CPU usage
  • Memory usage (RSS) of Sidekiq processes
  • Redis usage

Performance Targets

  1. All data should be created and reassigned successfully
  2. Server load should remain within acceptable limits:
    • CPU usage should not exceed 80% for extended periods
    • Memory usage should not trigger Sidekiq restarts (stay below 2GB per process)
  3. Minimal resource contention errors (less than 1% of operations)

Areas to Assess

  1. Scalability of placeholder user creation and lookup
  2. Efficiency of saving placeholder user references
  3. Performance of the contribution reassignment process
  4. Impact on database performance (query times, locks)
  5. Redis usage and potential bottlenecks
  6. Sidekiq job execution times and queue lengths

Monitoring and Data Collection

  1. Use GitLab's built-in monitoring tools
  2. Collect logs from Sidekiq, PostgreSQL, and Redis
  3. Use external monitoring tools if necessary (e.g., Prometheus, Grafana)

Analysis

  1. Compare performance metrics with and without user mapping enabled
  2. Identify any bottlenecks or performance degradation
  3. Assess the impact on overall system resources
  4. Evaluate the scalability of the solution

Potential Optimizations to Consider

  1. Adjust batch sizes for processing (current recommendation: 100 records per batch)
  2. Fine-tune caching strategies (memory vs. Redis vs. no cache)
  3. Optimize database queries and indexes
  4. Improve job scheduling and concurrency settings

Follow-up Actions

  1. Document findings and performance metrics
  2. Propose optimizations based on test results
  3. Update relevant documentation with performance expectations and limitations
  4. Plan for any necessary improvements before full feature release
Edited by Nivetha Prabakaran