OpenTreeMap / otm-core / 1419
83%
develop: 84%

LAST BUILD BRANCH: dependabot/npm_and_yarn/sockjs-0.3.21
DEFAULT BRANCH: develop
Ran
Jobs 1
Files 184
Run time 7s
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
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

Jobs
ID Job ID Ran Files Coverage
1 1419.1 0
83.02
 Travis Job 1419.1
Source Files on build 1419
Detailed source file information is not available for this build.