1. The document describes load testing done on an Odoo implementation to determine system limits and size requirements. Tests were run using Locust and varied the number of requests per second, users, and sessions to identify bottlenecks. 2. Testing showed the initial limit was around 500 requests/second. Further tests found that sessions stored in NFS caused issues, so they were changed to store in PostgreSQL. 3. Load balanced and monolithic architectures were compared, finding the load balanced setup using 4 servers performed similarly to a single server with 40 cores for the monolithic setup.

1. S N • R
EXPERIENCE
2019
Odoo limits
 @nseinlet •  @nseinlet •  @nseinlet •  nse@odoo.com

2. Methodology1
Tests2
LB VS Monolythic3
Conclusion4

3. “Which server size do I need for Odoo? --Random customer

4. Is this equivalent?
Real use cases
All is a matter of requests per second in //
50 users filling timesheets 5 minutes/month VS 50 users validating pickings all day long1
validating a picking VS validating a picking which trigger MRP, BOM, ...2
Importing 10 sale order per day. Each one have ~ 100k lines1
Closing 300 PoS sessions with 300 orders each2

5. Methodology
1

6. We would like to load test Odoo
Not the bandwith1
Not our laptop2
Not ...3

7. Choose a tool
Tested locust, apache ab, ...
Use locust with slaves
I like locust1
Locust use threads2
Do I get the same results as with another tool?3
Has locust limits?4

8. Repeatable test
#!/bin/bash
if [ -z "$3" ]
then
echo "No argument supplied"
echo "http_.py nbr_slaves time rounds"
exit 1
fi
declare -a arr=($(seq 10 5 150))
for concurrency in "${arr[@]}"
do
num_test=1
while [ $num_test -le $3 ]
do
x=1
while [ $x -le $1 ]
do
locust -f http_loc.py --slave --only-summary > /dev/null 2>&1 &
x=$(( $x + 1 ))
done
locust -f http_loc.py --no-web -c $concurrency -r $concurrency --run-time $2m --master --expect-slaves=$1 --csv=$1-$concurrency-$2-$
num_test=$(( $num_test + 1 ))
done
done

9. What to test?
Choose a use case1
/web/login ?2
assets ?3
/web/noop ?4
@http.route('/web/noop')
def noop_route(self):
return True
Metrics ?5

10. Metrics
When percentile 50 is twice is nominal value, we agreed the system limit is reached.
We simulate users who frenetically click on the interface, not real users then...
req/s1
percentile 502
percentile 953

11. Our setup
All hosted in the same
big datacenter
1
Physical servers2
1 testing server, 48
cores
3
1 load balancer, 8
cores
4
4 odoo servers, 8
cores each
5
1 PostgreSQL server,
48 cores
6
All tests ran from the testing server
When a monolytic setup is used, we use odoo on the
PostgreSQL server

When a Load balanced setup is used, we contact the load
balancer which dispatch on the 4 nodes


12. Tests
2

13. First test
We're confidend. Odoo is robust. Our infra too. Let's load it.
Ooops, limit seems to be 500 req/s.

14. Is QWeb the culprit?
Or the # of workers?

15. Changing # workers

16. Reaching # workers limit

19. /web/noop
Full cycle (session, connection PostgreSQL, ...)
Same patern with higher figures.

20. Each request creates a new sessions. Sessions are stored in NFS. We measure the ryhtm NFS can create files.
Not really what we wanted to...

21. Sessions in PG
Try to remove the NFS Bias
We create a new session for every request. What if we reuse sessions (like users do...)

22. Reuse sessions
1 session for 10 requests

24. More realistic
Add 150ms delay

25. Load balanced VS Monolythic
3

26. Architecture
Mono LB
Intel® Xeon® Gold 6154 E3-1270 v6
# 1 x 2 4 x 1
Core 18 (36) 4 (16)
Threads 36 (72) 8 (32)
Frequency 3.00 Ghz 3.80 GHz
Turbo Frequency 3.70 Ghz 4.20 GHz

27. req/s
Mono (red) with 40 cores
looks like the 5N (40 cores)...

28. Percentile

30. Conclusions
4

31. What I don't talked about
Changing # of slaves locust1
Changing CPU frequency2
Changing # of CPU in the machine3

32. Our tests
Test /web/login and assets1
Test /web/noop increased performance2
Use sessions in PostgreSQL improved performance (But who create 3k sessions / s)3
Our tests simulates non realistic customer4
Adding a delay is more realistic5
Do not test business code6
Methodology is the same to test business code7
Load testing for sizing
E
M , ,
V /
yse 

33. 
L
oad
An
a S
ize
G
o
Live

34. N S • R
EXPERIENCE
2019
Thank you!
 @nseinlet •  @nseinlet •  @nseinlet •  nse@odoo.com
#odooexperience