Project

General

Profile

Actions

Backport #39958

closed

mimic: mgr/dashboard: Resolve TestBed performance issue

Added by Anonymous almost 5 years ago. Updated about 3 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Target version:
-
Release:
mimic
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

With this helper function you can easily resolve the TestBed resetting
performance issue. If more tests exists in a test suite, it makes sense
to configure TestBed only once if you are not doing a lot of TestBed
specific stuff (haven't hit the limitation). It will reduce the test
run time by around $tests * 50 . In my case it was a test suite with
47 tests with a run time of over 30s after using the static test bed
method it ran in 1.2s. The run time was reduced to 0.04 %! This is
equivalent to a speed increase of 2500
(100/0.04)!

For our own security the normal way will be taken if you not
set the DEV configuration variable to true. It will be false when
"run-frontend-unittests.sh" is run.


Related issues 1 (0 open1 closed)

Copied from Dashboard - Feature #39957: mgr/dashboard: Resolve TestBed performance issueResolvedStephan Müller

Actions
Actions #1

Updated by Anonymous almost 5 years ago

  • Copied from Feature #39957: mgr/dashboard: Resolve TestBed performance issue added
Actions #2

Updated by Nathan Cutler almost 5 years ago

  • Status changed from New to Need More Info
  • Assignee set to Stephan Müller

The second commit in this patchset touches a huge number of files and there are many, many cherry-pick conflicts to resolve.

Assigning to the developer of the master patchset for a determination whether this backport is really needed - due to the huge number of conflicts that will require manual resolution, the risk of regression is presumed to be high.

Actions #3

Updated by Anonymous almost 5 years ago

Nathan Cutler wrote:

The second commit in this patchset touches a huge number of files and there are many, many cherry-pick conflicts to resolve.

Assigning to the developer of the master patchset for a determination whether this backport is really needed - due to the huge number of conflicts that will require manual resolution, the risk of regression is presumed to be high.

I'm about to backport http://tracker.ceph.com/issues/39939 - That one depends on the changes of http://tracker.ceph.com/issues/39957 and I'd also have to resolve many conflics (around 50) manually. Backporting http://tracker.ceph.com/issues/39957 would at least help to avoid conflicts when backporting other pull request that also depend on 39957.

Actions #4

Updated by Anonymous almost 5 years ago

  • Status changed from Need More Info to Rejected
  • Assignee deleted (Stephan Müller)

We won't backport this pr, because it would not add enough value for the effort.

Actions #5

Updated by Ernesto Puerta about 3 years ago

  • Project changed from mgr to Dashboard
Actions

Also available in: Atom PDF