Background task processing reference values

Expected Compute Engine task processing times for a healthy SonarQube Server instance.

Assess whether your Compute Engine (CE) processing times are healthy, or whether they point to a resource allocation or infrastructure problem worth investigating.

Finding your baseline takes about two minutes: pull the component count from ce.log, apply the formula, and compare against your actual task time.

Prerequisites

• You have Administer permission at the global level to access Administration > Projects > Background tasks.
• The compute engine log ce.log is accessible on the server.

The estimate

For a standard incremental analysis (not the first analysis of a new project):

expected_time (seconds) ≈ 10 + 0.01 × component_count

component_count is the number of source files and directories in the project. Find the exact value by searching ce.log for the Build tree of components step, which logs the count for every analysis (see Server logs on how to access ce.log). Find the actual time for a task in Administration > Projects > Background tasks in the Duration column, or in the same log.

This formula is a health-check reference, not an exact prediction. If your actual task time is close to the formula result on well-provisioned hardware, your instance is healthy. With a lower-latency database, times can be up to 2x faster than the formula predicts.

A healthy range is within ~1.5x of the formula result. If your actual time is consistently 2x or more above the formula result, investigate further, starting with the database checks in Performance issues.

This formula covers task execution time only, not the time a task spends waiting in the queue.

Example: A project with 5,000 components should process in about 10 + 50 = 60 seconds. If it consistently takes 180s or more, that warrants a database check.

Step time breakdown

The dominant step on a healthy instance should be Execute component visitors, which typically accounts for 50-60% of total task time. Compute new coverage typically takes 15-25%.

Persist sources, Persist issues, and Index analysis are normally fast (under 5 seconds, usually 1-2 seconds), but can take longer when the analyzed commit introduces many new or modified files. The expected time for the whole task will be longer as well.

If any step that's normally fast is taking minutes rather than seconds, database I/O is the likely bottleneck. If Index analysis is taking longer than usual, check Elasticsearch health.

Extract report unpacks the ZIP archive sent by the scanner. Its duration scales with the size of that archive, which is driven primarily by the volume of source code. On fast local SSD storage, large projects in the 1-2 million LOC range typically take 5-10 seconds. On slow storage, this step can take significantly longer.

Reference hardware

The formula is calibrated on:

Component	Specification
Application node	8 vCPU / 16 GB RAM (AWS c5d.2xlarge equivalent)
Database	4 vCPU / 32 GB RAM, PostgreSQL (AWS db.r8g.xlarge equivalent)
Database storage	SSD, 3,000 IOPS / 125 MB/s (AWS gp3 default equivalent)

About the database

• The formula assumes PostgreSQL on SSD.
• Azure SQL and MSSQL can produce task times 2-3x higher than the formula predicts, even on nominally comparable hardware. If you're running a non-PostgreSQL database, treat the formula result as a lower bound rather than an expected value.
• Database storage should provide at least 3,000 IOPS, with less than 10 ms per write transaction.

Related pages

• Performance issues

• Server logs