> For the complete documentation index, see [llms.txt](https://docs.sonarsource.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sonarsource.com/sonarqube-server/2026.4/server-update-and-maintenance/troubleshooting/background-task-performance.md).

# Background task processing reference values

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](/sonarqube-server/2026.4/server-update-and-maintenance/troubleshooting/server-logs.md) 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](/sonarqube-server/2026.4/server-update-and-maintenance/troubleshooting/performance-issues.md).

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 <a href="#related-pages" id="related-pages"></a>

* [Performance issues](/sonarqube-server/2026.4/server-update-and-maintenance/troubleshooting/performance-issues.md)
* [Server logs](/sonarqube-server/2026.4/server-update-and-maintenance/troubleshooting/server-logs.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.sonarsource.com/sonarqube-server/2026.4/server-update-and-maintenance/troubleshooting/background-task-performance.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.