git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: 程洋 <chengyang@xiaomi.com>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>,
	何浩 <hehao@xiaomi.com>, "Xin7 Ma 马鑫" <maxin7@xiaomi.com>,
	石奉兵 <shifengbing@xiaomi.com>, 凡军辉 <fanjunhui@xiaomi.com>,
	王汉基 <wanghanji@xiaomi.com>
Subject: Re: [External Mail]Re: Partial-clone cause big performance impact on server
Date: Thu, 1 Sep 2022 12:19:09 -0400	[thread overview]
Message-ID: <YxDbfXyWzgokb1Bq@coredump.intra.peff.net> (raw)
In-Reply-To: <b0101e7e0e61496a92c2299454c2696a@xiaomi.com>

On Thu, Sep 01, 2022 at 06:53:01AM +0000, 程洋 wrote:

> At first I also think it's some implementation bugs by jgit. However I
> can also reproduce it on cgit. Here is the steps, I'm not sure if you
> can reproduce too.
> 
> 1. Clone a repository from AOSP to local machine:  `git clone
>    "https://android.googlesource.com/platform/prebuilts/gradle-plugin"`
> 2. try to clone from localhost using cgit server.
>    `GIT_TRACE_PACKET=1 git clone --filter=blob:none -b master
>    user@localhost:/home/user/repositories/gradle-plugin `
> 3. During checkout phase, it also takes 15 seconds before actual downloading.

I don't see that at all. A few things on your reproduction:

  - you have to tell the local server repo that filters are OK:

      git -C gradle-plugin config uploadpack.allowfilter true

  - your example goes over localhost ssh. Is your server configured to
    allow passing the GIT_PROTOCOL environment variable? If not, you're
    using the v0 protocol. In which case you'll have to set a config
    option to allow clients to fetch objects that the server didn't
    advertise.

    If you do it with allowReachableSHA1InWant, like this:

      git -C gradle-plugin config uploadpack.allowReachableSHA1InWant true

    then there will be a short delay while it checks their
    reachability. That check happens via an external rev-list. I think
    it's not clever enough to use bitmaps, though it could. However, in
    this example, the delay only seems to be around 800ms for me (and of
    course we didn't generate bitmaps anyway, so that wouldn't matter).

    If you instead do:

      git -C gradle-plugin config uploadpack.allowAnySHA1InWant true

    then that reachability check goes away.

    But on modern servers, most of this should be moot anyway. A
    well-configured server should support protocol v2, which defaults to
    allowAnySHA1InWant.

    If you use --no-local to disable local-clone optimizations, then you
    can use --filter without having to go through ssh. That should use
    protocol version 2, as a "real" server would.

So all told, I think a more realistic reproduction is:

  $ git clone https://android.googlesource.com/platform/prebuilts/gradle-plugin
  $ git -C gradle-plugin config uploadpack.allowfilter true
  $ git clone --filter=blob:none --no-local -b master grade-plugin foo

which takes ~3s for me.

I do think upload-pack spends more time than it needs in this case, as
it's keen to call parse_object() on oids that the client asks for. Which
means we'll open up those blobs and check their sha1s before sending
them out, which isn't strictly necessary.

All of this seems orthogonal to the original claim that "Counting
objects" was taking a while, though. The delays here are all inside
upload-pack, before it spawns pack-objects. And it's pack-objects that
says "Counting objects".

-Peff

  reply	other threads:[~2022-09-01 16:19 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-11  8:09 Partial-clone cause big performance impact on server 程洋
2022-08-11 17:22 ` Jonathan Tan
2022-08-13  7:55   ` 回复: [External Mail]Re: " 程洋
2022-08-13 11:41     ` 程洋
2022-08-15  5:16     ` ZheNing Hu
2022-08-15 13:15       ` 程洋
2022-08-12 12:21 ` Derrick Stolee
2022-08-14  6:48 ` Jeff King
2022-08-15 13:18   ` Derrick Stolee
2022-08-15 14:50     ` [External Mail]Re: " 程洋
2022-08-17 10:22     ` 程洋
2022-08-17 13:41       ` Derrick Stolee
2022-08-18  5:49         ` Jeff King
2022-09-01  6:53   ` 程洋
2022-09-01 16:19     ` Jeff King [this message]
2022-09-05 11:17       ` 程洋
2022-09-06 18:38         ` Jeff King
2022-09-06 22:58           ` [PATCH 0/3] speeding up on-demand fetch for blobs in partial clone Jeff King
2022-09-06 23:01             ` [PATCH 1/3] parse_object(): allow skipping hash check Jeff King
2022-09-07 14:15               ` Derrick Stolee
2022-09-07 20:44                 ` Jeff King
2022-09-06 23:05             ` [PATCH 2/3] upload-pack: skip parse-object re-hashing of "want" objects Jeff King
2022-09-07 14:36               ` Derrick Stolee
2022-09-07 14:45                 ` Derrick Stolee
2022-09-07 20:50                   ` Jeff King
2022-09-07 19:26               ` Junio C Hamano
2022-09-07 20:36                 ` Jeff King
2022-09-07 20:48                   ` [BUG] t1800: Fails for error text comparison rsbecker
2022-09-07 21:55                     ` Junio C Hamano
2022-09-07 22:23                       ` rsbecker
2022-09-07 21:02                   ` [PATCH 2/3] upload-pack: skip parse-object re-hashing of "want" objects Jeff King
2022-09-07 22:07                     ` Junio C Hamano
2022-09-08  5:04                       ` Jeff King
2022-09-08 16:41                         ` Junio C Hamano
2022-09-06 23:06             ` [PATCH 3/3] parse_object(): check commit-graph when skip_hash set Jeff King
2022-09-07 14:46               ` Derrick Stolee
2022-09-07 19:31               ` Junio C Hamano
2022-09-08 10:39                 ` [External Mail]Re: " 程洋
2022-09-08 18:42                   ` Jeff King
2022-09-07 14:48             ` [PATCH 0/3] speeding up on-demand fetch for blobs in partial clone Derrick Stolee

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YxDbfXyWzgokb1Bq@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=chengyang@xiaomi.com \
    --cc=fanjunhui@xiaomi.com \
    --cc=git@vger.kernel.org \
    --cc=hehao@xiaomi.com \
    --cc=maxin7@xiaomi.com \
    --cc=shifengbing@xiaomi.com \
    --cc=wanghanji@xiaomi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).