1. 02 Oct, 2019 1 commit
  2. 19 Sep, 2019 1 commit
    • Zeger-Jan van de Weg's avatar
      Add timeouts for each RPC call · 8f8dea2c
      Zeger-Jan van de Weg authored
      When setting the timeouts the client can give up on the RPC call, which
      allows for a protection for the client and server.
      
      This commit also removes the implicit lack of a timeout when running on
      sidekiq. This is a good thing as if one server is overloaded with work,
      it wouldn't block the whole queue from processing.
      
      Part of: &1737
      8f8dea2c
  3. 28 Aug, 2019 2 commits
    • Andrew Newdigate's avatar
      Rename Labkit::Tracing::GRPCInterceptor to GRPC::ClientInterceptor · e369dee8
      Andrew Newdigate authored
      The original name has been deprecated
      e369dee8
    • Sean McGivern's avatar
      Make performance bar enabled checks consistent · f9c456bd
      Sean McGivern authored
      Previously, we called the `peek_enabled?` method like so:
      
          prepend_before_action :set_peek_request_id, if: :peek_enabled?
      
      Now we don't have a `set_peek_request_id` method, so we don't need that
      line. However, the `peek_enabled?` part had a side-effect: it would also
      populate the request store cache for whether the performance bar was
      enabled for the current request or not.
      
      This commit makes that side-effect explicit, and replaces all uses of
      `peek_enabled?` with the more explicit
      `Gitlab::PerformanceBar.enabled_for_request?`. There is one spec that
      still sets `SafeRequestStore[:peek_enabled]` directly, because it is
      contrasting behaviour with and without a request store enabled.
      
      The upshot is:
      
      1. We still set the value in one place. We make it more explicit that
         that's what we're doing.
      2. Reading that value uses a consistent method so it's easier to find in
         future.
      f9c456bd
  4. 23 Aug, 2019 1 commit
  5. 09 Aug, 2019 1 commit
    • Stan Hu's avatar
      Add Gitaly and Rugged call timing in Sidekiq logs · a74396dc
      Stan Hu authored
      This will help identify Sidekiq jobs that invoke excessive number of
      filesystem access.
      
      The timing data is stored in `RequestStore`, but this is only active
      within the middleware and is not directly accessible to the Sidekiq
      logger. However, it is possible for the middleware to modify the job
      hash to pass this data along to the logger.
      a74396dc
  6. 30 Jul, 2019 1 commit
  7. 19 Jul, 2019 1 commit
  8. 16 Jul, 2019 1 commit
  9. 15 Jul, 2019 1 commit
  10. 10 Jul, 2019 2 commits
  11. 09 Jul, 2019 1 commit
  12. 05 Jul, 2019 2 commits
  13. 18 Jun, 2019 2 commits
  14. 03 Jun, 2019 1 commit
  15. 07 May, 2019 1 commit
  16. 05 May, 2019 2 commits
  17. 29 Apr, 2019 1 commit
  18. 18 Apr, 2019 2 commits
    • Andrew Newdigate's avatar
      Migrate correlation and tracing code to LabKit · ccddf45d
      Andrew Newdigate authored
      This change is a fairly straightforward refactor to extract the tracing
      and correlation-id code from the gitlab rails codebase into the new
      LabKit-Ruby project.
      
      The corresponding import into LabKit-Ruby was in
      labkit-ruby!1
      
      The code itself remains very similar for now.
      
      Extracting it allows us to reuse it in other projects, such as
      Gitaly-Ruby. This will give us the advantages of correlation-ids and
      distributed tracing in that project too.
      ccddf45d
    • Andrew Newdigate's avatar
      Migrate correlation and tracing code to LabKit · 4f4de36c
      Andrew Newdigate authored
      This change is a fairly straightforward refactor to extract the tracing
      and correlation-id code from the gitlab rails codebase into the new
      LabKit-Ruby project.
      
      The corresponding import into LabKit-Ruby was in
      gitlab-org/labkit-ruby!1
      
      The code itself remains very similar for now.
      
      Extracting it allows us to reuse it in other projects, such as
      Gitaly-Ruby. This will give us the advantages of correlation-ids and
      distributed tracing in that project too.
      4f4de36c
  19. 17 Apr, 2019 2 commits
    • Stan Hu's avatar
      Add backtrace to Gitaly performance bar · 0f85fbc7
      Stan Hu authored
      This adds the backtrace to a table to show exactly where the Gitaly call
      was made to make it easier to understand where the call originated.
      
      This change also collapses the details in the same row to improve the
      usability when there is a backtrace.
      0f85fbc7
    • Stan Hu's avatar
      Add backtrace to Gitaly performance bar · fbb3fd13
      Stan Hu authored
      This adds the backtrace to a table to show exactly where the Gitaly call
      was made to make it easier to understand where the call originated.
      
      This change also collapses the details in the same row to improve the
      usability when there is a backtrace.
      fbb3fd13
  20. 28 Mar, 2019 1 commit
  21. 27 Mar, 2019 3 commits
    • Stan Hu's avatar
      Guard against nested allows with ref name caching · 7a2325e4
      Stan Hu authored
      This avoids the case:
      
      ```
      allow_ref_name_caching do
        allow_ref_name_caching do
          # using-feature
        end
      end
      ```
      7a2325e4
    • Stan Hu's avatar
      Allow ref name caching CommitService#find_commit · db759c5d
      Stan Hu authored
      For a given merge request, it's quite common to see duplicate FindCommit
      Gitaly requests because the Gitaly CommitService caches the request by
      the commit SHA, not by the ref name. However, most of the duplicate
      requests use the ref name, so the cache is never actually used in
      practice. This leads to unnecessary requests that slow performance.
      
      This commit allows certain callers to bypass the ref name to
      OID conversion in the cache. We don't do this by default because it's
      possible the tip of the branch changes during the commit, which
      would cause the caller to get stale data.
      
      This commit also forces the Ci::Pipeline to use the full ref name
      so that caching can work for merge requests.
      
      Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/57083
      db759c5d
    • Stan Hu's avatar
      Log Gitaly RPC duration to api_json.log and production_json.log · 74ff33a3
      Stan Hu authored
      This makes it easier to debug Gitaly performance issues in the field.
      
      This commit also makes the tracking of query time thread-safe via
      RequestStore.
      74ff33a3
  22. 13 Mar, 2019 2 commits
  23. 11 Mar, 2019 1 commit
    • Mark Lapierre's avatar
      Add feature flag to enforce gitaly request limits · b3f54b3d
      Mark Lapierre authored
      We typically don't want to enforce request limits in production
      However, we have some production-like test environments, i.e., ones
      where `Rails.env.production?` returns `true`. We do want to be able
      to check if the limit is being exceeded while testing in those
      environments.
      b3f54b3d
  24. 06 Mar, 2019 3 commits
  25. 05 Mar, 2019 1 commit
  26. 28 Feb, 2019 1 commit
  27. 22 Feb, 2019 1 commit
    • Zeger-Jan van de Weg's avatar
      Only allow 30 RPCs per test case to Gitaly · c00a1ec0
      Zeger-Jan van de Weg authored
      Prior to this change, 35 Gitaly RPCs were allowed. But recently there's
      been a renewed interest in performance. By lowering the number of
      calls new N + 1's will pop up.
      
      Later commits will add blocks to ignore the raised errors, followed by
      an issue for each to be fixed.
      c00a1ec0
  28. 25 Jan, 2019 1 commit
    • Valery Sizov's avatar
      Elasticsearch: Indexing via gitaly · e534a119
      Valery Sizov authored
      Repositories can be now indexed via Gitaly. We add support for it. We
      essentially pass configuration parameters here so indexer know what's
      Gitaly address
      e534a119