summaryrefslogtreecommitdiff
path: root/doc/development/performance.md
diff options
context:
space:
mode:
authorAchilleas Pipinellis <axil@gitlab.com>2019-08-20 20:22:43 +0200
committerAchilleas Pipinellis <axil@gitlab.com>2019-08-20 20:22:43 +0200
commite61308ce1d82e12e5087371469baea4a452875d1 (patch)
tree62551a3ae4eab75e5af7e3b35358c07a51b2132f /doc/development/performance.md
parent4f323bb62fbe71a4352de25cab141f361a3fe1a6 (diff)
parent2989ed078c1d45b0959dcecb1bc3c8f4740a3c0d (diff)
downloadgitlab-ce-docs-patch-71.tar.gz
Merge branch 'master' into docs-patch-71docs-patch-71
Diffstat (limited to 'doc/development/performance.md')
-rw-r--r--doc/development/performance.md11
1 files changed, 6 insertions, 5 deletions
diff --git a/doc/development/performance.md b/doc/development/performance.md
index 0e21d45f57c..14b3f8204d2 100644
--- a/doc/development/performance.md
+++ b/doc/development/performance.md
@@ -246,6 +246,7 @@ irb(main):002:0> results.last.attributes.keys
irb(main):003:0> results.where(status: "passed").average(:time).to_s
=> "0.211340155844156"
```
+
These results can also be placed into a PostgreSQL database by setting the
`RSPEC_PROFILING_POSTGRES_URL` variable. This is used to profile the test suite
when running in the CI environment.
@@ -266,7 +267,7 @@ piece of code is worth optimizing. The only two things you can do are:
1. Think about what the code does, how it's used, how many times it's called and
how much time is spent in it relative to the total execution time (e.g., the
total time spent in a web request).
-2. Ask others (preferably in the form of an issue).
+1. Ask others (preferably in the form of an issue).
Some examples of changes that aren't really important/worth the effort:
@@ -284,10 +285,10 @@ directly in a web request as much as possible. This has numerous benefits such
as:
1. An error won't prevent the request from completing.
-2. The process being slow won't affect the loading time of a page.
-3. In case of a failure it's easy to re-try the process (Sidekiq takes care of
+1. The process being slow won't affect the loading time of a page.
+1. In case of a failure it's easy to re-try the process (Sidekiq takes care of
this automatically).
-4. By isolating the code from a web request it will hopefully be easier to test
+1. By isolating the code from a web request it will hopefully be easier to test
and maintain.
It's especially important to use Sidekiq as much as possible when dealing with
@@ -424,7 +425,7 @@ might find using these gems more convenient:
### Examples
You may find some useful examples in this snippet:
-https://gitlab.com/gitlab-org/gitlab-ce/snippets/33946
+<https://gitlab.com/gitlab-org/gitlab-ce/snippets/33946>
[#15607]: https://gitlab.com/gitlab-org/gitlab-ce/issues/15607
[yorickpeterse]: https://gitlab.com/yorickpeterse