git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Strategy to deal with slow cloners

From
EWEric Wong <e@80x24.org>
Date
Apr 21, 2021, 20:08 UTC
Message-ID
<20210421200816.GA13772@dcvr>
In-Reply-To
<20210419180803.GA10171@dcvr>
Eric Wong <e@80x24.org> wrote:
Show 10 quoted lines
> Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
> > Hello:
> > 
> > I try to keep repositories routinely repacked and optimized for clones, in
> > hopes that most operations needing lots of objects would be sending packs
> > straight from disk. However, every now and again a client from a slow
> > connection requests a large clone and then takes half a day downloading it,
> > resulting in gigabytes of RAM being occupied by a temporary pack.
> 
> Yeah, I'm familiar with the problem.

Also, AFAIK nginx has "proxy_buffering on" by default. However, I seem to recall that prevents clients from seeing a single byte until the pack is completely generated. It's been many years since I've used nginx myself, so my knowledge about it could be out-of-date.

Previous: Eric WongNext: Thomas Braun
Message 3 of 6 in “Strategy to deal with slow cloners”
  1. Konstantin RyabitsevApr 19, 2021
  2. Eric WongApr 19, 2021
  3. Eric WongApr 21, 2021
  4. Thomas BraunApr 20, 2021
  5. Ævar Arnfjörð BjarmasonApr 22, 2021
  6. Jeff KingApr 23, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.