Merge branch 'jv-doc-questions' into 'master'

Document answers to some questions

See merge request gitlab-org/gitaly!1376

1 files changed, 2 insertions, 1 deletions

diff --git a/doc/DESIGN.md b/doc/DESIGN.md
index 0813c3952..45be72476 100644
--- a/doc/DESIGN.md
+++ b/doc/DESIGN.md
@@ -67,7 +67,6 @@ All design decision should be added here.
 1. How will the networking work? A unix socket for git operations and TCP for monitoring. This prevents having to build out authentication at this early stage. https://gitlab.com/gitlab-org/gitaly/issues/16
 1. We'll include the `/vendor` directory in source control https://gitlab.com/gitlab-org/gitaly/issues/18
 1. We will use [E3 from BitBucket to measure performance closely in isolation](https://gitlab.com/gitlab-org/gitaly/issues/34).
-1. Use environment variables for setting configurations (see #20).
 1. GitLab already has [logic so that the application servers know which file/git server contains what repository](https://docs.gitlab.com/ee/administration/repository_storages.html), this eliminates the need for a router.
 1. Use [gRPC](http://www.grpc.io/) instead of HTTP+JSON. Not so much for performance reasons (Protobuf is faster than JSON) but because gRPC is an RPC framework. With HTTP+JSON we have to invent our own framework; with gRPC we get a set of conventions to work with. This will allow us to move faster once we have learned how to use gRPC.
 1. All protocol definitions and auto-generated gRPC client code will be in the gitaly repo. We can include the client code from the rest of the application as a Ruby gem / Go package / client executable as needed. This will make cross-repo versioning easier.
@@ -75,3 +74,5 @@ All design decision should be added here.
 1. By default all Go packages in the Gitaly repository use the `/internal` directory, unless we explicitly want to export something. The only exception is the `/cmd` directory for executables.
 1. GitLab requests should use as few Gitaly gRPC calls as possible. This means it is OK to move GitLab application logic into Gitaly when it saves us gRPC round trips.
 1. Defining new gRPC calls is cheap. It is better to define a new 'high level' gRPC call and save gRPC round trips than to chain / combine 'low level' gRPC calls.
+1. Why doesn't Gitaly use a Git library like [git2go](https://github.com/libgit2/git2go) or [go-git](https://github.com/src-d/go-git)? We intentionally isolate Git queries in indvidual processes. We could (and may) use Git libraries to make custom query executables but we seem to get by well enough with regular `git`.
+1. Why is Gitaly written in Go? At the time the project started the only practical options were Ruby and Go. We expected to be able to handle more traffic with fewer resources if we used Go. Today (Q3 2019), part of Gitaly is written in Ruby. On the particular Gitaly server that hosts gitlab-org/gitlab-ce, we have a pool of gitaly-ruby processes using a total 20GB of RSS and handling 5 requests per second. The single Gitaly Go process on that machine uses less than 3GB of memory and handles 90 requests per second.