Public

Document overview
• Usage profiles
• Optimisation hints
• Storage performance
• Test result summaries
• Production / test environments

Odoo performance
Planning the platform for your Odoo installation

Date: 26th October 2020

Version: v1.1

[email protected]
01788 298 450
opusvl.com

Drury House
Drury Lane
Rugby CV21 3DE

Opus Vision Limited t/a OpusVL

Company No. 03905104
Open source business management software.
VAT No. GB 747 8294 82 Customised to fit the way you work.
Public

Contents

1 Executive summary 3

2 Technical overview 4
Application stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Communications & messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Usage profiles 6
Usage profile 1: Evaluation and low usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Usage profile 2: Small organisations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Usage profile 3: High-demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4 Infrastructure profiles 7
Infrastructure profile A: Virtualised . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Infrastructure profile B: Entry server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Infrastructure profile C: Midrange server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

5 Storage performance 9
Scaling options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Performance measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
IOPS data table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Optimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

6 Operating system requirements 15

Application platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Failure mitigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Odoo performance 2 of 18
Public

1 Executive summary

In this document we present the base system requirements to operate an Odoo solution at optimal
performance.

Included is an overview of the technical stack of components, implementation and the environments in
which they reside.

Usage profiles are included which are accompanied by specific infrastructure requirements, required to
meet the stated performance expectations.

Optimisation, fault-tolerance and monitoring are briefly covered as these all have bearing on the
performance of primary operations.

For optimum performance in a demanding environment, Odoo must be operated as a Docker container,
installed on a bare-metal server (not virtualised) and will have locally attached (not network attached)
storage.

Odoo performance 3 of 18
Public

2 Technical overview

This section provides an overview of the Odoo application and supporting structures.

Application stack
The stack includes the following components:

• Odoo - framework
– Odoo - modules
• Postgres - database
• Nginx - proxy

Communications & messaging

The application stack communicates internally and to external systems using the following mechanisms:

• Unix domain sockets for local inter-process communications (IPC) and inter-container
communications
• TCP/IP for internal monitoring and management
• TCP/IP for API interactions with external systems

Environments
Multiple instances of an application are commonly installed in addition to the production service.

Production / Live
Production (also known as ‘Live’) is the primary business-as-usual service. It may include multiple
instances to provide ongoing services in the event of a system failure. These may be of equivalent
specification to provide equal performance or of a reduced specification where costs are sensitive.

Non-production
Other instances outside Production are commonly required to enable various non-production activities
and vary from customer to customer. These include:

Odoo performance 4 of 18
Public

• Staging: for review and testing of updates and changes

• User Acceptance Testing (UAT): user test and sign-off for application changes
• Training: copy of Production that allows users to make changes to the data in order to learn the
application
• Development: to develop new features outside the customer domain (customer or supplier)

Deployment flow

Applications are deployed through the various environments across the Developer and Customer
domain as follows:

__Developer domain__
| __Customer domain__
|
Developer 1 -\ | / -> Live 1
Developer 2 --|-> Dev test -> Staging -|-> UAT -> | -> Live 2
Developer n -/ | | \ -> Live n
| | |
V | V
Support | Training

Sample data or subsets of fully anonymised customer data are used in the Developer domain where the
full customer data exists in the Customer domain.

During operational support investigations, an instance may be made available to the support team.
However when an issue cannot be replicated, access to UAT and sometimes Live may be required.

Odoo performance 5 of 18
Public

3 Usage profiles

The following real-world performance should be experienced by application users within each usage
profile based on the specified infrastructure profiles being provisioned:

• General page load (95th percentile): 1 second

• Processed page load (95th percentile): 5 seconds
• Page load (max): 10 seconds

Usage profile 1: Evaluation and low usage

This usage profile is baaed on the following usage characteristics:

• Users: 10
• Simultaneous users: 5
• API Messages per minute: 6
• Minimum infrastructure profile: A

Usage profile 2: Small organisations

This usage profile is based on the following usage characteristics:

• Users: 100
• Simultaneous users: 25
• API Messages per minute: 30
• Minimum infrastructure profile: B

Usage profile 3: High-demand

This usage profile is baaed on the following usage characteristics:

• Users: 200
• Simultaneous users: 50
• API Messages per minute: 60
• Minimum infrastructure profile: C

Odoo performance 6 of 18
Public

4 Infrastructure profiles

The following infrastructure profiles illustrate common enterprise platforms appropriate for primary
Odoo nodes.

In each case, the application will run in a container layer above the operating system. These assume that
the operating system is configured as described in this document.

IOPS expectations and associated storage requirements can be derived

from the IOPS table.

Infrastructure profile A: Virtualised

• Type: Virtual machine
• Cores: 4 (Physical)
• Frequency: 2.0 GHz
• Memory: 12Gb
• Storage size: 50Gb
• Storage class: A/B or higher
• PGBench measure: TBD
• Geekbench score: TBD

Infrastructure profile B: Entry server

• Type: Physical server
• Cores: 8 (Physical)
• Frequency: 2.5 GHz
• Memory: 24Gb
• Storage size: 100Gb
• Storage class: B/C or higher
• PGBench measure: TBD
• Geekbench score: TBD

Infrastructure profile C: Midrange server

• Type: Physical server

Odoo performance 7 of 18
Public

• Cores: 16 (Physical)
• Frequency: 3.0 GHz
• Memory: 64Gb
• Storage size: 150Gb
• Storage class: C/D or higher
• PGBench measure: TBD
• Geekbench score: TBD

Odoo performance 8 of 18
Public

5 Storage performance

Input / Output Per Second (IOPS) (also known as Transactions Per Second TPS) are used to measure the
real-world performance potential of storage devices.

IOPS must be considered through the full storage stack, not just drive speed or quoted manufacturer
statistics. Every layer of the storage stack can become the bottleneck and in some cases, network and
CPU can limit storage speed and introduce latency or reduce throughput.

Using mixed read / write, the following table provides examples of real-world achievable disk
performances. Note that where Network Attached Storage (NAS) or Storage Area Networks (SAN) are
used, the network bandwidth is the limiting factor and additional latency is introduced.

• programs running in the background

• size of file system blocks
• test block size
• hardware cache controllers
• memory cache
• RAID configuration
• mix of reads vs writes

IOPS are hard to comparatively measure in standard form as diagnostics

require the storage channel to be exercised fully and results can depend
on other concurrent activities for example:

Scaling options
Customised performance improvements can be made to support greater scale if required using the
following techniques:

• separate Odoo containers per ward or per building / physical grouping with shared database
• sharding the application and database across infrastructure

Performance measurement
Performance can be measured on Linux using a variety of tools including:

Odoo performance 9 of 18
Public

• sar (from sysstat)

• iostat (from sysstat)
• ioping
• fio
• iotop
• atop
• iowait
• dd
• bonnie++

IOPS data table

Data in this table is non-exhaustive, indicative and subject to various environmental factors therefore is
provided as a comparative illustration.

The data has been collected using the following fio command:

fio --randrepeat=1 --ioengine=libaio \

--direct=1 --gtod_reduce=1 --name=test \
--filename=IOPS-fio-TEST --bs=4k --iodepth=64 \
--size=4G --readwrite=randrw --rwmixread=75

Results that are estimated or based on supplier information are marked with (E).

Storage classifications used in this document are as follows:

Class A Less than 500 read IOPS

Class B 500 read IOPS -> 999 read IOPS
Class C 1000 read IOPS -> 19999 read IOPS
Class D 20000 read IOPS -> 99999 read IOPS

Storage type Class Connection fio IOPS (read / write)

USB2 7200 A Local 100 / 40

IDE 7200 A Local 100 / 50

P4 32Gb A Local (E) 120

SATA 7200 B Local 500 / 150

SATA 7200 via NFS B Remote (1Gb) 500 / 150

Azure P10 128Gb B Local (E) 500

SAS 7200 HPE P420i B Local 800 / 300

Odoo performance 10 of 18
Public

Storage type Class Connection fio IOPS (read / write)

Azure P15 256Gb C Local (E) 1,100

SATA SSD via NFS C Remote (1Gb) 5,000 / 1,500

Azure P30 1024Gb C Local (E) 5,000

SATA SSD HPE B120i C Local 5,500 / 2,000

SATA SSD HPE P410i C Local 5,500 / 2,000

Azure P40 2048Gb C Local 8,000 / 3,000

SATA SSD HPE P420i C Local 13,000 / 4,000

NVMe direct D Local 50,000 / 15,000

NVMe via KVM D Local 50,000 / 15,000

SATA SSD D Local 60,000 / 20,000

NVMe (Evo 970 m.2) D Local 230,000 / 75,000

Optimisation
To provide a user experience where the operator does not consider that performance is lacking requires
the application to respond to interaction rapidly. To achieve this with Odoo, storage latency must be
minimal and bandwidth must allow for fast database reads and writes.

Odoo is sensitive to storage latency so benefits from local storage, using replication to manage fault
tolerance. Network connected databases can also cause user delays due to the large volume of database
transactions automatically generated by the application framework.

Virtualised network and storage drives add many layers of latency to local and especially remote storage
devices so can become a significant factor when experiencing substandard performance.

In addition to the bandwidth, storage queues should be monitored as

well as read/write latency.

To address performance issues, the following key areas should be explored:

1. reduction of storage IO latency

2. ensure storage is locally attached

Odoo performance 11 of 18
Public

3. memory usage
4. adequate CPU cores provisioned
5. contention with other applications sharing resources
6. client device performance
7. client device connectivity

Optimisation hints
Every server or application is different, so a change that is beneficial in one environment may be
detrimental in another. It is therefore essential to gather base-line metrics before making any changes.
Comparing the before and after performance metrics allow the effectiveness of changes to be objectively
assessed. Also consider the implications of any changes, for example improving performance by
removing journaling creates risks of data loss in the event of a disorderly shut-down.

Generally, the operating system should reside on it’s own disk, or at least a separate partition so tuning
and optimisation can be enabled and validated for the specific partition or disk dedicated to a task, say
database operations.

By default, most Linux configurations offer a balanced experience for

interactive users and unattended operations. For server workloads,
interactive latency can be sacrificed in exchange for more responsive
background operations.

CPU frequency scaling

Modern CPU’s provide methods of the operating system to adapt the frequency depending on load.
Modern operating systems implement conservative defaults to run CPU’s at lower speeds when idle,
therefore using less power and generating less heat when not exercised. As storage and network
performance relies heavily on the CPU, this can lead to real experiences of poor performance or poor
performance measurements.

Typical scaling governors available include:

performance Run the CPU at the maximum frequency

ondemand Scales the frequency dynamically according to current load. Jumps to the highest frequency
and then possibly back off as the idle time increases

Find out what is available for the current CPU with this command:

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_governors

Check the current settings of your CPU with this command:

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

Note that this will report the capability of all CPU’s and these will be the same assuming identical CPU’s
are installed.

Odoo performance 12 of 18
Public

When using ‘ondemand’, the responsiveness of the CPU to load can be altered by setting the
‘up_threshold’ to a lower value.

Find out the current governor setting with this command:

cat /sys/devices/system/cpu/cpufreq/ondemand/up_threshold

Responsiveness of the ‘ondemand’ governor can be set as follows:

echo "30" > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold

To persist this on a recent Linux distribution (ie Debian Stretch), install the following applications:

cpufrequtils sysfsutils

then edit

/etc/sysfs.conf

and add the following lines:

devices/system/cpu/cpu*/cpufreq/scaling_governor = ondemand
devices/system/cpu/cpufreq/ondemand/up_threshold = 30

IO scheduler

This command effectively removes the Linux kernel IO scheduler and is useful when running inside
a virtual machine, with high-performance disks or enterprise storage controllers as they have built-in
schedulers.

echo noop > /sys/block/sda/queue/scheduler

Mount options

Setting the following options adjust how files on disk are audited. Setting them reduces the resolution
of information relating to file access or modification times and this reduces the administrative disk IO.
These are added to the mount options in fstab or autofs, reboot to apply, or remount in place:

mount -o remount /

Use relative access time on files:

relatime

More aggressively, have no access time on files:

noatime

Odoo performance 13 of 18
Public

File systems

XFS file system may provide better performance than the Linux default ext4. Creating a file system with
block-size the same as the underlying hardware will increase performance. To force creation of 1024
blocks, use:

mkfs.ext4 -b 1024 /dev/sda

Kernel optimisations

Linux kernel settings can be tuned to better serve the workload. These are configured through the sysctl
facility.

Making changes on the fly can be done as follows:

sysctl -w vm.dirty_ratio = 6
sysctl -w vm.dirty_background_ratio=3
sysctl -w vm.vfs_cache_pressure=50

Permanent changes are stored in the /etc/sysctl.conf file

Odoo performance 14 of 18
Public

6 Operating system requirements

Application platform
Debian Linux is recommended for the base operating system. However the application will also operate
on other well-known Linux distributions including Centos, Redhat and Ubuntu based systems (subject to
validation). The containerised application can be run on Windows & Apple operating systems although
this is not advised for demanding environments due to the performance overhead.

Recommended package installation

The base operating system requires a minimal installation with:

• no desktop or ‘X’ applications

• latest stable distribution
• docker (stable between 3 and 12 months from release)
• SSH remote access for implementation & support teams
• ‘sudo’ privilege management
• group membership of ‘sudo’ and ‘docker’ groups

Connectivity
Application -> internet
Internet access is required at installation time to install required applications and during operations to
access application updates.

Proxied connection to the Internet is acceptable.

Users -> application

Access to the application requires a recent web browser. Clients access the application through an
encrypted TCP port (HTTPS) delivered by a proxy server.

The client can restrict access via their own proxy server if required.

Odoo performance 15 of 18
Public

Failure mitigation
Business Continuity (BC) relates to the non-interruption of operations despite major failure of key
systems. It is common for performance reduction or non-availability of peripheral systems to be
acceptable in this situation although it should not prevent operators from functionally carrying out their
operations. Fault tolerant systems are commonly designed in to BC solutions.

Disaster Recovery (DR) is where the BC function was not adequate to provide on-going operations and
a recovery is required. It should be assumed that a BC process could fail to deliver so DR is essential. A
back-up facility is often included as a function of DR.

DR expectations are expressed using the following terms:

• Recovery Time Objective (RTO): Target time to recover operations following a failure
• Recovery Point Objective (RPO): Target data loss acceptable at point of failure

Monitoring
Optional monitoring of purpose, performance and availability can be included within the package and
is commonly installed on a virtual machine.

• SNMP-based integration
• Network-based monitoring and alerting

Security
This document does not include considerations for security of applications and this requires an
assessment specificaly based on client usage.

Odoo performance 16 of 18
Public

Odoo performance 17 of 18
Since 1999, OpusVL has helped organisations
get the business management software they
were looking for (but just couldn’t seem to
find). We combine our ‘off-the-shelf’ products
with the craftsmanship it takes to tailor your
software to your needs.

With over 20 years’ experience, we’re a multi-

disciplined team of developers, people-people
and project management experts. But, above
all else, we’re proud to be a team that our
clients trust to get the software – and results –
that they need.

opusvl.com Drury House

01788 298 450 Drury Lane
[email protected] Rugby CV21 3DE