When cloning a repository, it takes about 18minutes.
push takes 10 minutes, pull takes 18minutes.
The repository's size was 8G. Now it's under 1G after git gc and
prune.
But the time required has been implemented a little bit.
The time for cloning is 10 minutes. (push : 4minutes, )
I think that's already a big problem.
The gerrit version is 2.1.7
The git repository has 45 branches and many groups for managing
permissions.
THE IMPORTANT THING :
The only users that get the permission to each branch are experiencing
the problem.
ex) the user(having speed problem) : Read Access : refs/heads/gb-dev-
branch
ex) the user(no problem) : Read Access : refs/*
Those have read permissions to all branches are good to work.
Has anybody experienced the same problem ?
Thank you in advance.
On Wednesday, May 23, 2012 at 00:55 EDT,
"hs20.c...@gmail.com" <hs20.c...@gmail.com> wrote:
> When cloning a repository, it takes about 18minutes.
> push takes 10 minutes, pull takes 18minutes.
> The repository's size was 8G. Now it's under 1G after git gc and
> prune.
> But the time required has been implemented a little bit.
> The time for cloning is 10 minutes. (push : 4minutes, )
The long fetch time isn't surprising, but I don't understand the
excessive push time.
> I think that's already a big problem.
> The gerrit version is 2.1.7
> The git repository has 45 branches and many groups for managing
> permissions.
> THE IMPORTANT THING :
> The only users that get the permission to each branch are experiencing
> the problem.
> ex) the user(having speed problem) : Read Access : refs/heads/gb-dev-
> branch
> ex) the user(no problem) : Read Access : refs/*
> Those have read permissions to all branches are good to work.
For users having access to all refs, Gerrit can just serve the git
as-is. When a user doesn't have read access to all refs, Gerrit must
repack the git on the fly for each request. For a 1 GB git I'm not
surprised this takes a few minutes.
I assume you have ample RAM and CPU and that the git is stored on a
local drive rather than accessed via NFS or something equally slow.
To get around this type of problem one can set up replication slaves to
which only a subset of the refs are replicated. That way Gerrit won't
have to repack the gits when a client connects. Of course, this means
that users have to choose which server to connect to and it doesn't
scale if the number of read access combinations is too big.
> On Wednesday, May 23, 2012 at 00:55 EDT,
> "hs20.c...@gmail.com" <hs20.c...@gmail.com> wrote:
>> When cloning a repository, it takes about 18minutes.
>> push takes 10 minutes, pull takes 18minutes.
>> The repository's size was 8G. Now it's under 1G after git gc and
>> prune.
>> But the time required has been implemented a little bit.
>> The time for cloning is 10 minutes. (push : 4minutes, )
> The long fetch time isn't surprising, but I don't understand the
> excessive push time.
>> I think that's already a big problem.
>> The gerrit version is 2.1.7
>> The git repository has 45 branches and many groups for managing
>> permissions.
>> THE IMPORTANT THING :
>> The only users that get the permission to each branch are experiencing
>> the problem.
>> ex) the user(having speed problem) : Read Access : refs/heads/gb-dev-
>> branch
>> ex) the user(no problem) : Read Access : refs/*
>> Those have read permissions to all branches are good to work.
> For users having access to all refs, Gerrit can just serve the git
> as-is. When a user doesn't have read access to all refs, Gerrit must
> repack the git on the fly for each request. For a 1 GB git I'm not
> surprised this takes a few minutes.
> I assume you have ample RAM and CPU and that the git is stored on a
> local drive rather than accessed via NFS or something equally slow.
> To get around this type of problem one can set up replication slaves to
> which only a subset of the refs are replicated. That way Gerrit won't
> have to repack the gits when a client connects. Of course, this means
> that users have to choose which server to connect to and it doesn't
> scale if the number of read access combinations is too big.
> When cloning a repository, it takes about 18minutes.
> push takes 10 minutes, pull takes 18minutes.
> The repository's size was 8G. Now it's under 1G after git gc and
> prune.
> But the time required has been implemented a little bit.
> The time for cloning is 10 minutes. (push : 4minutes, )
> I think that's already a big problem.
> The gerrit version is 2.1.7
> The git repository has 45 branches and many groups for managing
> permissions.
> THE IMPORTANT THING :
> The only users that get the permission to each branch are experiencing
> the problem.
> ex) the user(having speed problem) : Read Access : refs/heads/gb-dev-
> branch
Try upgrading Gerrit to the latest release. We have had a lot of
performance improvements for per-branch permissions in the 2.2 series
that is not in the 2.1.7 release.
On Wed, May 23, 2012 at 6:00 AM, Magnus Bäck <ba...@google.com> wrote:
> On Wednesday, May 23, 2012 at 00:55 EDT,
> "hs20.c...@gmail.com" <hs20.c...@gmail.com> wrote:
>> When cloning a repository, it takes about 18minutes.
>> push takes 10 minutes, pull takes 18minutes.
>> The repository's size was 8G. Now it's under 1G after git gc and
>> prune.
>> But the time required has been implemented a little bit.
>> The time for cloning is 10 minutes. (push : 4minutes, )
> The long fetch time isn't surprising, but I don't understand the
> excessive push time.
Its actually the same problem, Gerrit is trying to figure out what
refs are available for the user, and trying to confirm the user hasn't
done something evil during the push by trying to get access to an
object they aren't supposed to have access to. This extra security
checking takes more time.
> For users having access to all refs, Gerrit can just serve the git
> as-is. When a user doesn't have read access to all refs, Gerrit must
> repack the git on the fly for each request. For a 1 GB git I'm not
> surprised this takes a few minutes.
This isn't true. Gerrit always repacks a repo to serve a client. What
is expensive is filtering the set of branches the user can see, to
make sure they are only shown branches they have read access for.
On Wednesday, May 23, 2012 at 12:19 EDT,
Shawn Pearce <s...@google.com> wrote:
> On Wed, May 23, 2012 at 6:00 AM, Magnus Bäck <ba...@google.com> wrote:
[...]
> > For users having access to all refs, Gerrit can just serve the git
> > as-is. When a user doesn't have read access to all refs, Gerrit must
> > repack the git on the fly for each request. For a 1 GB git I'm not
> > surprised this takes a few minutes.
> This isn't true. Gerrit always repacks a repo to serve a client. What
> is expensive is filtering the set of branches the user can see, to
> make sure they are only shown branches they have read access for.
Oh, so a repack always takes place but for a recently repacked git the
operation is fairly quick (but non-zero) since not that much needs to be
expunged and not many deltas need to be recalculated?
On Thu, May 24, 2012 at 6:58 AM, Magnus Bäck <ba...@google.com> wrote:
> On Wednesday, May 23, 2012 at 12:19 EDT,
> Shawn Pearce <s...@google.com> wrote:
>> On Wed, May 23, 2012 at 6:00 AM, Magnus Bäck <ba...@google.com> wrote:
> [...]
>> > For users having access to all refs, Gerrit can just serve the git
>> > as-is. When a user doesn't have read access to all refs, Gerrit must
>> > repack the git on the fly for each request. For a 1 GB git I'm not
>> > surprised this takes a few minutes.
>> This isn't true. Gerrit always repacks a repo to serve a client. What
>> is expensive is filtering the set of branches the user can see, to
>> make sure they are only shown branches they have read access for.
> Oh, so a repack always takes place but for a recently repacked git the
> operation is fairly quick (but non-zero) since not that much needs to be
> expunged and not many deltas need to be recalculated?
> On Thu, May 24, 2012 at 6:58 AM, Magnus Bäck <ba...@google.com> wrote: > > On Wednesday, May 23, 2012 at 12:19 EDT, > > Shawn Pearce <s...@google.com> wrote:
> >> On Wed, May 23, 2012 at 6:00 AM, Magnus Bäck <ba...@google.com> wrote:
> > [...]
> >> > For users having access to all refs, Gerrit can just serve the git > >> > as-is. When a user doesn't have read access to all refs, Gerrit must > >> > repack the git on the fly for each request. For a 1 GB git I'm not > >> > surprised this takes a few minutes.
> >> This isn't true. Gerrit always repacks a repo to serve a client. What > >> is expensive is filtering the set of branches the user can see, to > >> make sure they are only shown branches they have read access for.
> > Oh, so a repack always takes place but for a recently repacked git the > > operation is fairly quick (but non-zero) since not that much needs to be > > expunged and not many deltas need to be recalculated?
