> For the complete documentation index, see [llms.txt](https://documentation.ocsinventory-ng.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://documentation.ocsinventory-ng.org/administrator-docs/scalability-and-performance.md).

# Scalability and Performance

Sizing and performance depend on two main factors:

* The number of agents managed by the server
* The number of inventory submissions over a given time interval

These values impact CPU, memory, and storage needs. Additional adjustments may still be required for traffic peaks or heavy API usage, see [#common-strategies](#common-strategies "mention").

## Baseline assumptions

All sizing guidance below is based on **PostgreSQL**, which is the recommended database system.

Database choice can strongly affect resource usage, especially memory. Treat the values on this page as **PostgreSQL reference values only**.

The examples below also assume:

* Inventory runs every **4 hours**
* A client device is powered on for about **12 hours per day**
* Each device sends about **3 to 4 inventories per day**
* **Inventory checksum is enabled**, which increases backend load and reduces database load

<details>

<summary><strong>Load calculation example</strong></summary>

For an environment managing **3000 agents**, the baseline calculation is:

* **3000 agents**
* **12 000 inventories per day**
* Spread across **12 active hours**, this equals **1000 inventories per hour**
* This is roughly **one inventory every 3 to 4 seconds**

{% hint style="info" %}
This is a simplified average. It assumes traffic is evenly distributed across the day. That is useful for baseline sizing, but it does not reflect real traffic. In practice, inventory peaks often happen in the **morning** and again in the **early afternoon**.
{% endhint %}

</details>

## Architecture models

This page covers three architecture models:

{% columns %}
{% column %}

<p align="center"><strong>Standalone architecture</strong></p>

All OCS components run on one server

This model is suitable for architectures with fewer than 3 000 agents
{% endcolumn %}

{% column %}

<p align="center"><strong>Split architecture</strong></p>

Frontend and backend services run on separate servers
{% endcolumn %}

{% column %}

<p align="center"><strong>Distributed architecture</strong></p>

The load is split across multiple backend instances and/or database servers, with usually one frontend server
{% endcolumn %}
{% endcolumns %}

## Reference sizing examples

### Standalone architecture - baseline

| Requirement             | Spec     | Comment                                      |
| ----------------------- | -------- | -------------------------------------------- |
| CPU                     | 1 vCPU   |                                              |
| Cores                   | 2 vCores |                                              |
| Memory                  | 6 GB     |                                              |
| System disk             | 30 GB    | System, application components, and database |
| Package disk (optional) | XX GB    | Depends on deployment package usage          |

In this model, WSGI workers and PostgreSQL connections are usually the main limiting factors, as they are the largest memory consumers.

### Standalone architecture - 3000 agents

| Requirement             | Spec     | Comment                                      |
| ----------------------- | -------- | -------------------------------------------- |
| CPU                     | 1 vCPU   |                                              |
| Cores                   | 4 vCores |                                              |
| Memory                  | 12-16 GB |                                              |
| System disk             | 40 GB    | System, application components, and database |
| Package disk (optional) | XX GB    | Depends on deployment package usage          |

### Split architecture - baseline

{% tabs %}
{% tab title="Database server" %}

| Requirement   | Spec     | Comment                |
| ------------- | -------- | ---------------------- |
| CPU           | 1 vCPU   |                        |
| Cores         | 2 vCores |                        |
| Memory        | 4 GB     |                        |
| System disk   | 20 GB    | System and application |
| Database disk | 10 GB    | Database storage       |
| {% endtab %}  |          |                        |

{% tab title="Backend server" %}

| Requirement             | Spec     | Comment                             |
| ----------------------- | -------- | ----------------------------------- |
| CPU                     | 1 vCPU   |                                     |
| Cores                   | 2 vCores |                                     |
| Memory                  | 4 GB     |                                     |
| System disk             | 20 GB    | System and application              |
| Package disk (optional) | XX GB    | Depends on deployment package usage |
| {% endtab %}            |          |                                     |

{% tab title="Frontend server" %}

| Requirement   | Spec     | Comment                |
| ------------- | -------- | ---------------------- |
| CPU           | 1 vCPU   |                        |
| Cores         | 2 vCores |                        |
| Memory        | 2 GB     |                        |
| System disk   | 20 GB    | System and application |
| {% endtab %}  |          |                        |
| {% endtabs %} |          |                        |

### Split architecture - 10 000 to 15 000 agents

{% tabs %}
{% tab title="Database server" %}

| Requirement   | Spec     | Comment                |
| ------------- | -------- | ---------------------- |
| CPU           | 1 vCPU   |                        |
| Cores         | 2 vCores |                        |
| Memory        | 12 GB    |                        |
| System disk   | 20 GB    | System and application |
| Database disk | 30 GB    | Database storage       |
| {% endtab %}  |          |                        |

{% tab title="Backend server" %}

| Requirement             | Spec     | Comment                             |
| ----------------------- | -------- | ----------------------------------- |
| CPU                     | 1 vCPU   |                                     |
| Cores                   | 4 vCores |                                     |
| Memory                  | 12 GB    |                                     |
| System disk             | 20 GB    | System and application              |
| Package disk (optional) | XX GB    | Depends on deployment package usage |
| {% endtab %}            |          |                                     |

{% tab title="Frontend server" %}

| Requirement   | Spec     | Comment                |
| ------------- | -------- | ---------------------- |
| CPU           | 1 vCPU   |                        |
| Cores         | 2 vCores |                        |
| Memory        | 6 GB     |                        |
| System disk   | 20 GB    | System and application |
| {% endtab %}  |          |                        |
| {% endtabs %} |          |                        |

## **Scaling strategies**

* If a third-party service makes heavy use of the OCS API, consider:
  * adding a PostgreSQL read-only standby/replica for read traffic
  * dedicating one backend server to third-party read and write operations
* If many users simultaneously use the web console:
  * consider a replicated or pooled database setup, such as **pgpool**
  * add a load balancer to route inventory and frontend requests to dedicated backend servers

## Need help?

[Contact us](https://www.ocsinventory-ng.com/en/contacter-ocsinventory).


---

# 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://documentation.ocsinventory-ng.org/administrator-docs/scalability-and-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.