This diary is about load testing. I find load testing useful mainly because of
two reasons: 1. it shows multiuser access problems; 2. it shows how good is the
The idea is to simulate mapathon. A mapathon is an event where multiple mappers
map the same (big) area. To manage the work, the area is divided into smaller
squares. Then, each mapper asks the server to map or review a square, works
some time on the square, and finally asks the server to mark the square as
needs mapping, needs review, or is done.
I use locust.io to load test the damn server. The test file is
part of the repository. There is 80 % of mappers, 20 % of reviewers, and 2
testing areas. Each mapper/reviewer works for 30 - 60 seconds, then waits for
30 - 60 seconds, and then works again. All the mappers are spawned within the
first minute. The test is stopped soon after there is 0 % to map for both of
damn-project.org runs on $5/month VPS with 1 GB RAM, single 2.2 GHz vCPU,
and 25 GB SSD disk.
100 mappers handled The first round of load testing gives the idea about
the server after the refactoring. The average response time for 100
mappers is 270 ms. Not bad, I would say.
It’s a bit worse when testing 200 mappers, though. I’ve stopped the test after
Some improvements Two years ago, I decided that there must be some better
solution for the problem of dividing a big area into smaller squares. I found
that there is PostGIS extension to PostgreSQL so I decided to go
with it. Two year later (now,) I’ve discovered database indexes.
Also, I’ve read part of the documentation and set postgres parameters.
Finally, I switched gzip on.
200 mappers handled Pretty small changes, but I had to figure them out. I
noted my journey in this thread. Anyway, with the changes applied, I load
tested again. The average response time of 275 ms for 200 mappers looks good.
Writing good code is green. Don’t waste energy.