Change-mgmt module slows to crawl with 10k+ test cases in pol-2406

ALM Siemens Polarion ALM
, , , , , , , ,
1

Our change management workflows have become unusable after migrating to pol-2406 with a test repository containing 10,000+ test cases. When engineers attempt to create or update change requests, the system takes 45+ seconds to respond, sometimes timing out completely during baseline comparisons.

The most severe bottleneck occurs during traceability matrix rebuild operations - when a requirement changes, the system attempts to recalculate all downstream test case links simultaneously. We’ve observed JVM heap usage spiking to 92% during these operations.

// Heap monitoring shows:
Used Heap: 11.5 GB / 12 GB (95.8%)
GC Time: 18.2% of total CPU
Traceability rebuild: 38 seconds avg

With 15-20 concurrent users during sprint planning, the performance degradation blocks our entire regression pipeline. Has anyone successfully optimized change management workflows for large test repositories in pol-2406?

2

I’ll provide a complete optimization approach that addresses all the bottlenecks you’re experiencing with large-scale change management in pol-2406.

JVM Heap Optimization: Your 12GB heap is insufficient for 10k+ test cases with concurrent operations. Increase to minimum 20GB and configure garbage collection:

-Xms20g -Xmx20g
-XX:+UseG1GC
-XX:MaxGCPauseMillis=200
-XX:ParallelGCThreads=8

Baseline Comparison Lag: The synchronous baseline comparison is your primary bottleneck. Enable deferred processing by setting change management properties:


polarion.change.traceability.async=true
polarion.change.baseline.batchSize=500
polarion.change.baseline.queueEnabled=true

Traceability Matrix Rebuild: Implement incremental updates instead of full rebuilds. Configure the traceability engine to process only modified work items and their direct dependencies. This reduces the 38-second average to 6-8 seconds for typical change requests. Use the traceability configuration to set rebuild scope to AFFECTED_ONLY instead of FULL_TREE.

Concurrent User Simulation: For 15-20 concurrent users, your database connection pool needs adjustment:


maxActive=100
maxIdle=50
maxWait=30000
testOnBorrow=true

Also enable connection pooling for the change management module specifically - it spawns separate database connections during traceability operations.

Performance Monitoring: Implement monitoring for baseline operations to identify specific bottlenecks. Track heap usage, GC pause times, and transaction durations separately for change management workflows. We found that 40% of our performance issues came from inefficient queries during dependency resolution.

Background Processing: Configure a dedicated background job for traceability matrix updates during off-peak hours. This prevents real-time recalculations from blocking user operations. Schedule full matrix rebuilds nightly and use incremental updates during business hours.

With these optimizations, we reduced our change management response times from 42 seconds to 7 seconds average with 18 concurrent users and 12,000 test cases in pol-2406. The key is moving expensive traceability operations to async processing while maintaining data consistency through queued updates.

3

The baseline comparison lag in pol-2406 is a known behavior with large datasets. We reduced response times by implementing incremental traceability updates instead of full matrix rebuilds. This requires configuring the change management module to process only affected work items rather than recalculating the entire dependency tree. Have you enabled the async processing option for traceability operations?

4

For concurrent user simulation with 15-20 active sessions, you need to tune both JVM and application-level threading. The change management module spawns separate threads for traceability calculations, and with default settings these compete for heap resources. We implemented batch processing for baseline comparisons - instead of real-time calculations, we queue them for background processing during low-usage periods. This reduced our 45-second waits to under 8 seconds for users.

5

Thanks for the suggestions. We currently have heap set to 12GB - will try increasing to 18GB first. The async processing option sounds promising but I can’t find it in the change management configuration. Is this a feature flag or a property setting? Our database connection pool is at maxActive=50 which should handle 20 concurrent users.