Variant management cloud configurator performance issues with complex rule evaluation

PLM Aras Innovator
, , , , , , , ,
1

Our cloud-based variant configurator in Aras 14.0 is becoming unresponsive when users try to configure products with complex rule sets. We have about 250 configuration rules across 15 product families, and when a user makes a selection, the configurator takes 15-30 seconds to evaluate rules and update the UI.

The performance was acceptable when we first deployed to cloud three months ago with maybe 100 rules, but as we’ve added more product variants and rules, it’s gotten progressively worse. We’re seeing UI timeout handling issues where the browser thinks the page has frozen. Our cloud resource scaling seems adequate - we’re on a medium-tier cloud instance with 16GB RAM.

The rule evaluation optimization seems to be the bottleneck. Each rule change triggers a full re-evaluation of all dependent rules, which cascades through the entire rule set. In our on-premise environment, this wasn’t as noticeable, but in the cloud the latency is much more apparent.

Anyone have experience optimizing variant configurator performance in cloud deployments? We need to support up to 500 rules eventually and current performance is unacceptable.

2

Your performance issues stem from how variant rules are evaluated in cloud environments versus on-premise. Let me address the three key optimization areas:

Rule Evaluation Optimization: The full re-evaluation cascade is your main bottleneck. Implement dependency-based evaluation where only affected rules are recalculated. Create a rule dependency map during configuration load that identifies which rules actually depend on each configurable option. When a user makes a selection, evaluate only the dependent subset.

For your 250 rules, analyze the dependency graph. Typically, only 10-15% of rules are actually affected by any single selection. Build a rule evaluation engine that maintains this dependency graph:

Pseudocode for optimized evaluation:

  1. On configurator load, build dependency map of all rules
  2. Cache static rule evaluation results in browser session storage
  3. When user makes selection, identify affected rules from dependency map
  4. Evaluate only dependent rules (typically 20-30 rules instead of 250)
  5. Update UI progressively as rule batches complete
  6. Cache new evaluation results for subsequent selections

This reduces your evaluation set by 85-90%, dramatically improving response time.

UI Timeout Handling: Implement asynchronous rule evaluation with progress indicators. Never block the UI thread waiting for server responses. Use this pattern:

  • User makes selection → immediate UI update showing the selection
  • Dispatch async rule evaluation request to server
  • Show loading spinner on dependent fields
  • As rule batches complete, update fields progressively
  • Total time remains the same, but perceived performance improves dramatically

Set client-side timeouts at 45 seconds to prevent indefinite hanging. If evaluation exceeds this, show an error and allow the user to retry or simplify their configuration.

Cloud Resource Scaling: Your 16GB RAM instance should be adequate for 250 rules, but verify your configurator service has sufficient memory allocation specifically. In cloud deployments, the default memory limits for individual services can be conservative.

Monitor these metrics:

  • Rule evaluation time per request (should be under 2 seconds for 250 rules)
  • Server CPU during evaluation (should stay below 60%)
  • Database query time for rule data (should be under 200ms)

If server CPU is maxing out, you have a computation bottleneck. If database queries are slow, you need better indexing on rule tables or query optimization.

Implement rule pre-loading: when the configurator initializes, load all rule definitions and static data into memory on the server side. This eliminates database queries during actual evaluation. For your scale, this should consume about 50-100MB of memory - well within your capacity.

For scaling to 500 rules, you’ll need to implement rule partitioning by product family. Load only relevant rule sets for the product being configured instead of all 500 rules. This keeps evaluation sets manageable.

Consider implementing server-side rule result caching with Redis or similar. Cache rule evaluation results for common configuration combinations. With 15 product families, you likely see repeated configuration patterns that can benefit from caching.

Finally, profile your rule methods themselves. Complex calculations or external API calls within rules add significant latency in cloud environments. Move computationally intensive operations to background jobs where possible, or pre-compute results during off-peak hours.

3

For rules that depend on real-time data like inventory, you need a hybrid approach. Cache static rules (dependencies, compatibility checks) on the client side, but make targeted server calls only for dynamic data rules. Implement a rule classification system that tags rules as static vs dynamic, then your configurator can handle them differently. This way you’re not making server calls for 90% of your rules that don’t change.

4

The rule caching idea sounds promising. Our rules are mostly server-side methods which explains the latency. How would you implement client-side caching without breaking rule accuracy? Some of our rules depend on real-time inventory data.

5

15-30 seconds for rule evaluation is definitely too slow. Have you looked at the actual rule evaluation logic? Sometimes rules are written inefficiently with unnecessary database queries or complex calculations that could be cached. Also, are your rules using server-side methods or client-side JavaScript? Server-side evaluation in cloud adds network latency for each call.