Polarion test execution module slows down with 50k+ test cas

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

Our Polarion test execution module has become unusable as our test case repository grew past 50,000 test cases. Loading the test execution dashboard now takes 3-5 minutes, and filtering test cases by status or test run causes browser timeouts. We’re running pol-2304 on a dedicated server with 32GB RAM and SSD storage, so hardware shouldn’t be the bottleneck.

The performance degradation is blocking our test execution activities. Test engineers are reluctant to use Polarion for test runs because the UI freezes when they try to select test cases or view execution history. We’ve noticed the slowdown started around 40k test cases and has gotten progressively worse.

Looking at the database, I see test case queries taking 30-45 seconds to return results. Has anyone dealt with database indexing strategies for large test case volumes, or implemented test case archiving to improve query performance?

2

We hit this at 35k test cases. The root cause was Polarion loading all test cases into memory before applying filters. Solution was implementing query pagination in the test execution views. Instead of loading 50k test cases and filtering client-side, configure Polarion to load test cases in batches of 500-1000 and apply filters at the database level. This reduced our dashboard load time from 4 minutes to under 10 seconds. Check your Polarion configuration for the testManagement.maxResultsPerPage setting.

3

Here’s a comprehensive performance optimization strategy addressing all three key areas:

1. Database Indexing Strategy for Test Case Queries

Create composite indexes targeting your most common query patterns:

CREATE INDEX idx_testcase_status_date
  ON WORKITEM(C_STATUS, C_CREATED)
  WHERE C_TYPE = 'testcase';

CREATE INDEX idx_testcase_run_link
  ON WORKITEM_LINKS(C_SOURCE_ID, C_LINK_ROLE)
  WHERE C_LINK_ROLE = 'executes';

These indexes target the two slowest query patterns: filtering test cases by status/date and loading test run relationships. The WHERE clauses create partial indexes that are smaller and faster than full-table indexes.

Additionally, update database statistics weekly during off-hours:

ANALYZE TABLE WORKITEM;
ANALYZE TABLE WORKITEM_LINKS;

Stale statistics cause the query optimizer to choose inefficient execution plans, especially as data volume grows.

2. Test Case Archiving and Baseline Management

Implement a three-tier archiving strategy:

Tier 1 - Active Test Cases (Current + 1 year):

  • Keep in main project for daily test execution
  • Target: <25,000 test cases for optimal performance

Tier 2 - Recent Archive (1-3 years):

  • Move to dedicated Archive project with read-only access
  • Test cases remain searchable but excluded from execution dashboards
  • Maintain traceability links to requirements

Tier 3 - Long-term Archive (3+ years):

  • Export to baseline snapshots for compliance/audit purposes
  • Remove from active Polarion instance
  • Store as signed PDF reports with full traceability

Archiving workflow:

// Pseudocode - Automated archiving:
1. Query test cases with lastModified > 365 days AND status=obsolete
2. Create baseline snapshot of test cases + linked requirements
3. Move test cases to Archive project using Polarion API
4. Update traceability links to reference archived location
5. Generate audit report showing archived items

Run this quarterly to keep your active test case count manageable.

3. Query Optimization and Pagination Implementation

Optimize Polarion’s test execution queries with these configuration changes:

Disable Expensive Operations: In polarion.properties:


testManagement.disableExactCounts=true
testManagement.maxResultsPerPage=500
testManagement.enableQueryCache=true

This switches from exact COUNT(*) queries to estimated counts and enables result caching.

Implement Progressive Loading: Configure test execution views to load data progressively:

  • Initial page load: Show test run summary only (no test case list)
  • User clicks “View Test Cases”: Load first 500 test cases
  • User scrolls/pages: Load additional batches on demand

This reduces initial query complexity from 50k rows to 500 rows.

Custom Field Optimization: Audit your test case custom fields and remove or restructure expensive ones:

  • Move rarely-used fields to a separate “Test Case Details” linked work item
  • Use enum fields instead of multi-select fields (simpler queries)
  • Denormalize frequently-filtered fields (e.g., copy test run status to test case for faster filtering)

Verification and Monitoring:

After implementing these changes:

  1. Enable Polarion’s performance logging (set log4j.logger.com.polarion.platform.persistence=DEBUG)
  2. Monitor slow queries (>5 seconds) and create indexes for common patterns
  3. Track dashboard load times weekly - target <10 seconds for test execution dashboard
  4. Set up alerts for query times exceeding 15 seconds

Expected Results:

  • Dashboard load time: 3-5 minutes → 8-12 seconds
  • Test case filtering: Timeout → 2-4 seconds
  • Test run creation: 45 seconds → 6-8 seconds

Implement in this order: (1) indexing + pagination first for immediate relief, (2) archiving within 2 weeks to reduce data volume, (3) query optimization ongoing as you identify bottlenecks.

4

Another quick win - analyze your test case custom fields. If you have 20+ custom fields on test cases, Polarion’s ORM queries become extremely complex with multiple joins. Consider moving rarely-used custom fields to a separate linked work item type or denormalizing frequently-queried fields. We reduced query time by 60% just by removing 8 custom fields that were only used in annual reports.

5

Check your database query execution plans. Polarion’s default indexes may not be optimized for 50k+ test cases. Run EXPLAIN on the slow queries to see if they’re doing full table scans. You likely need custom indexes on test case status, creation date, and test run relationships. Also check if your database statistics are up to date - stale stats cause the query optimizer to make poor decisions.

6

For the COUNT query issue, you can disable exact counts in Polarion’s search configuration and use estimated counts instead. This switches from COUNT(*) to approximate row counts from database statistics, which is much faster. Also consider implementing test case archiving - move test cases older than 2 years or from retired product versions to an archive project. This keeps your active project lean while preserving historical data for audits.