OpenTreeMap / otm-core
83%
develop: 84%

LAST BUILD BRANCH: dependabot/npm_and_yarn/sockjs-0.3.21
DEFAULT BRANCH: develop
Repo Added
Files 235
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

LAST BUILD ON BRANCH revert-2485-revert-2483-feature/tune-rate-limiting
branch: revert-2485-revert-2483-feature/tune-rate-limiting
CHANGE BRANCH
x

1419

push

travis-ci

steventlamb 
Use the best rate limits from staging testing

These rates limits where arrived at by looking for a sweet spot between
keeping the importer fast, addressing verifiable performance issues, and
accounting for uncertainty in performance issues in production.

For these purposes we will assume the following to be fixed:
1) 10k trees per import
2) added to an instance with complex bounds and 300k+ trees.
3) same hardware, mirroring production

* Importer speed
** validation
*** best case, infinite == 1:21
*** worst case, 10/m == 5:44
6:20 = 7:41 (mm:ss).
*** low sweet spot, 30/m == 2:00
below this value and things slow down substantially.
*** high sweet spot, 45/m == 1:20
above this and performance doesn't go up. Implying perhaps that this is
equivalent to the rate at which the system can consume input.
** imports
*** best case, infinite == 6:20
*** worst case, 5/m == 11:30
*** low sweet spot, 7/m == 7:15
*** high sweet spot, 10/m == 6:22
This resembles the unlimited case as well as the case of 30/m. However,
there's something else going on here. __lower rate limits cause jobs to
take longer__. I could find no explanation but was able to reproduce
this consistently. The looser the rate limiting, the longer each task
took. This means that even though 7/m is similar in performance, it
enables the system to do quite a bit more idling with little
consequence. For this reason, I recommend closer to the lowend, with a
target of 8/m.

* Verifiable performance issues
By this I mean that in a controlled environment in which we test imports
in isolation, we can see a small measurable difference in different rate
limit values. The truth is that even without rate limiting the
performance is still pretty similar, but there's some room for
optimization none-the-less.

* Uncertain performance issues
The inconvenient truth is that importer performance is obscured by the
fact that the import detail page is consuming massive resources. For
example, DB CPU load can drop from... (continued)

14153 of 17047 relevant lines covered (83.02%)

0.83 hits per line

Relevant lines Covered
17047 RELEVANT LINES 14153 COVERED LINES
0.83 HITS PER LINE
Source Files on revert-2485-revert-2483-feature/tune-rate-limiting
Coverage ∆ File Lines Relevant Covered Missed Hits/Line

Recent builds

Builds Branch Commit Type Ran Committer Via Coverage
1419 revert-2485-revert-2483-feature/tune-rate-limiting Use the best rate limits from staging testing These rates limits where arrived at by looking for a sweet spot between keeping the importer fast, addressing verifiable performance issues, and accounting for uncertainty in performance issues in pro... push steventlamb travis-ci pending completion  
1417 revert-2485-revert-2483-feature/tune-rate-limiting Revert "Revert "Add coarse values to importer rate limiting"" push steventlamb travis-ci pending completion  
1381 revert-2485-revert-2483-feature/tune-rate-limiting Revert "Revert "Add coarse values to importer rate limiting"" push steventlamb travis-ci pending completion  
See All Builds (2530)