Exceed the speed limit
Last week I worked successfully on tuning and improving the performance of the reverse geocoding engine. We have used a tool, named K6, to do some load tests. The test consists of doing massive requests to the service using a customized script to generate random geocoding queries all around the world. The first results showed a speed of about 200 queries/second as about 800K in an Hour.
Working on tuning SQLite compile and configuration parameters we are able to surpass 1 Million queries in an Hour, about 300 geocoding queries/seconds.
The decision to use SQLite than other DBs, like PostgreSQL, was deliberately done by design. There is a small presentation that explain this decision. We have also fixed a problem of instability of the service (crash), that emerged during the tests. We apologize to our users or customers (apparently no one 😇) for the abrupt interruption of the service caused by our stress tests.
As I'm writing this text, a big load test of 24 hr is undergone...
A snapshot of the ongoing load test of the Feroeg - reverse geocoding - service.
There are passed about 4hrs and 4.5M queries are done. Apparently no problem regarding memory leaks of the georef_server process. The one 'problem' I noticed is in the testing tool side: the memory grows as time passes. Tomorrow we will update this post reporting the definitive speed results of this test.
After 10 hours of run ... 10.7M queries were done ... same memory pressure ...
Final report of the 24 Hrs stress test.
After one day of running the backend has served 25.1M of reverse geocoding query. That is 1.04 millions of queries/hour. The memory usage by the main process 'georef_server' is about 250 MB. The only memory unresolved issue was 5 GB less of free space on SSD. I had to investigate it (*).
* The issue of less space on the HDD was related to logging files, generated from Nginx. The retention policy was 1 week. After few days, the logging rotation policy automatically freed up the space.
Comments
Post a Comment