Process mining import fails with timeout error on large XES files

BPM Creatio
, , , , , , , ,
1

We’re trying to import event logs for process mining analysis but keep hitting timeout errors. Our XES files are around 450MB with approximately 2.3 million events from our order fulfillment process. The import starts fine, progresses to about 35-40%, then throws a timeout exception after roughly 8 minutes.

We’re running Creatio 8.4 on a cloud instance with 16GB RAM allocated. I’ve checked the XES file structure and it validates correctly. The same files import successfully in our test environment (smaller dataset, only 500K events).

I’m wondering if there are specific file size limits for process mining imports, or if this is a server timeout configuration issue. We need to analyze the full dataset to identify bottlenecks in our process. Has anyone successfully imported XES files of this size? What resource allocation should we be looking at?

2

I recommend a two-pronged approach. First, optimize your XES file - remove unnecessary event attributes that aren’t needed for analysis. We reduced our file size by 40% just by stripping out verbose logging attributes. Second, if you’re on cloud deployment, consider temporarily scaling up your instance for the import operation. The process mining import is a one-time heavy operation, but once the data is in, analysis queries are much lighter.

3

450MB is definitely pushing the limits for browser-based imports. We had similar issues and found that chunking the import helps. Can you split your XES file into smaller segments (maybe 100MB each)? Process mining can usually merge event logs later for analysis. Also verify your cloud instance isn’t resource-constrained during import - CPU and memory spikes can cause unexpected timeouts even if base allocation seems sufficient.

4

I’ve seen this before. The 8-minute timeout is usually the default web request timeout. For large XES imports, you need to increase timeout values in your application settings. Check your IIS or web server configuration - look for requestTimeout and executionTimeout parameters. I’d recommend starting with 30 minutes for files that size.

5

The database connection timeout is worth checking, but I think your bottleneck is actually in the process mining engine itself. When importing large XES files, Creatio needs to parse, transform, and index all events. This is memory-intensive work. Your 16GB allocation might not be enough for 2.3M events if you have complex event attributes. Try monitoring the actual process mining service memory usage during import. We upgraded to 32GB for similar workloads and it made a huge difference. The parsing phase alone can consume 8-10GB for files your size.

6

Thanks for the suggestions. I checked our web.config and the executionTimeout is set to 600 seconds (10 minutes), but the failure happens before that. The cloud monitoring shows CPU peaks at 78% during import but memory stays around 60%. Would increasing the database connection timeout help here? I’m also curious if there’s a way to do server-side import rather than through the UI to avoid browser limitations entirely.

7

Let me address all three areas systematically since you’re dealing with a comprehensive import challenge.

XES File Size Limits: Creatio 8.4 doesn’t have a hard file size limit for XES imports, but practical limits exist based on your infrastructure. For production environments, we recommend keeping individual XES files under 300MB. Your 450MB file is workable but requires proper configuration. The 2.3M events should process fine - I’ve seen successful imports of 5M+ events with correct setup.

Server Timeout Configuration: You need to adjust multiple timeout layers:

  1. Web server timeout (IIS/Apache): Set to at least 3600 seconds for large imports
  2. Application pool timeout: Increase idle timeout to 30+ minutes
  3. Database command timeout: Add this to your connection string - “Command Timeout=3600”
  4. Process mining service timeout: In ProcessMiningConfig, set ImportTimeout to 7200 seconds

The failure at 35-40% suggests database command timeout rather than web timeout. Your executionTimeout of 600s would trigger later.

Resource Allocation: Here’s where you’re likely hitting the real bottleneck. For 2.3M events:

  • Minimum RAM: 24GB (32GB recommended for comfort)
  • Database temp space: Ensure at least 10GB free
  • CPU: 4+ cores recommended during import

The process mining import creates temporary indexes and transformation tables that are memory-intensive. With 16GB total and system overhead, you’re probably running into memory pressure around the 35% mark when index building begins.

Immediate Solution: Scale your cloud instance to 32GB RAM temporarily, increase all timeout values as specified above, and ensure your database has adequate temp space. After import completes, you can scale back down. Alternatively, split your XES into two 225MB files, import separately, and merge the process models in the analysis view.

For future imports, consider implementing an automated ETL pipeline that pre-processes XES files to remove non-essential attributes and batches large datasets automatically.