We’re experiencing significant performance degradation with our OutSystems RPA bots when processing large invoice batches (500+ invoices). The bots handle AP automation and typically process 50-100 invoices smoothly, but when we queue larger batches, processing time increases exponentially rather than linearly.
I’ve noticed the batch queue size seems to impact overall throughput - larger queues appear to cause more overhead. We haven’t done detailed bot activity profiling yet, but the slowdown is visible in the orchestrator dashboard. Resource usage monitoring shows CPU spikes but memory remains stable.
The finance team is frustrated because month-end processing now takes 6-8 hours instead of the expected 2-3 hours. We’re running OutSystems RPA on dedicated VMs with 8GB RAM and 4 cores. Has anyone experienced similar bottlenecks with batch processing? What profiling approaches worked for you?
Good points both. We’re currently running sequential processing - didn’t realize parallel execution was an option for RPA bots in OutSystems. The database angle is interesting too, we do update a central tracking table after each invoice. Could that be creating a bottleneck? How would I configure parallel bot instances?
Adding to Raj’s point - I’d also recommend implementing a two-tier queue strategy. Have a master queue that distributes work to smaller sub-queues (50-100 items each). This reduces orchestrator overhead significantly. Each bot instance works off a sub-queue, and you can scale horizontally by adding more bot runners. Monitor resource usage per bot instance, not just aggregate metrics, to identify if individual bots are maxing out resources.
Has anyone mentioned profiling the actual invoice processing logic itself? Sometimes the bottleneck isn’t in the RPA framework but in the business logic. Use the OutSystems RPA Studio profiler to capture execution traces for a sample batch. Look for repeated operations, unnecessary screen captures, or inefficient selectors. I’ve seen cases where bots were taking screenshots after every field entry “for logging” which killed performance at scale.
Let me provide a comprehensive optimization approach that addresses all the factors we’ve discussed:
Batch Queue Size Optimization:
Implement a tiered queue architecture where your master queue (500+ invoices) automatically splits into sub-queues of 75-100 invoices each. This reduces orchestrator memory overhead and enables better work distribution. Configure queue priorities so urgent invoices can bypass the batch processing flow.
Bot Activity Profiling Strategy:
Use OutSystems RPA Studio’s built-in profiler to capture detailed execution traces. Focus on these metrics:
- Time per invoice (should be consistent regardless of batch size)
- Queue wait time (should remain low even in large batches)
- Database operation duration (identify if updates are blocking)
- Screen interaction delays (may indicate UI responsiveness issues)
Run profiling sessions with 50, 150, and 300 invoice batches to identify where performance degrades. Export the profiling data and analyze trends - you’re looking for operations whose duration increases non-linearly with batch size.
Resource Usage Monitoring:
Set up granular monitoring at the bot instance level:
- CPU usage per bot runner (target <70% average utilization)
- Memory allocation patterns (watch for memory leaks in long-running sessions)
- Network I/O if invoices are fetched from external systems
- Database connection pool utilization
Implement parallel execution with 3 bot runners initially (leaving one core for OS overhead). Each runner should process from separate sub-queues. Monitor for resource contention - if CPU usage stays below 60% with parallel execution, you have headroom to optimize further.
Database Optimization:
Refactor your tracking table updates to use batch commits every 25 invoices instead of individual updates. Implement optimistic locking to handle concurrent updates gracefully. Consider using a message queue for status updates that a separate service processes asynchronously - this completely decouples bot performance from database write latency.
Expected Results:
With these optimizations, you should see:
- Linear scaling up to 500 invoices (2x invoices = ~2x time)
- Month-end processing reduced to 2.5-3 hours
- Consistent per-invoice processing time regardless of batch size
- Better resource utilization across all bot runners
Start with the queue architecture changes and profiling - these will give you the data needed to prioritize the other optimizations. The parallel execution setup should be your second step, followed by database optimization if profiling shows that’s a significant factor.
I’ve seen this pattern before with invoice processing bots. The exponential slowdown usually points to queue management issues rather than pure processing capacity. When batch sizes exceed certain thresholds, the orchestrator overhead becomes significant. Start by checking your bot activity logs - look for wait times between invoice picks from the queue versus actual processing time per invoice. If wait times are increasing disproportionately, that’s your smoking gun.
Database contention is definitely a factor here. If every bot instance is hitting the same tracking table with updates, you’re creating serialization points. Consider batching your database updates - instead of updating after each invoice, accumulate results in memory and update every 10-20 invoices. For parallel execution, you need to configure multiple bot runners in the orchestrator settings and ensure your queue distribution logic can handle concurrent consumers. Also, implement proper retry logic because parallel processing increases the chance of transient conflicts.
Quick thought - are you processing invoices sequentially or have you configured parallel execution? With 4 cores available, you should be able to run multiple bot instances concurrently. Also check if there are any database locks happening when bots update invoice status simultaneously. That could explain the CPU spikes you’re seeing.