To be fair, the amount of traffic we are talking about is not really that significant. GMP only allocating one core [1] for these requests and being frustrated that after so long they might have to increase the resource allocation or change something else is a bit unreasonable too.
It's totally reasonable to say that it isn't malicious and they aren't going to stop it, but it's unreasonable and unhelpful to add "seems like your servers just suck". They also missed or failed to mention that there are 700 forks of the project running the same thing at the same time.
> it's unreasonable and unhelpful to add "seems like your servers just suck"
What is the basis for this quote? Ctrl+F-ing on what look like the relevant pages turns up nothing. Maybe I missed it, but Google seems only to know about 1 instance of phrase from the last week (and it's the one in your comment).
I’m a bit confused as to why 700 automated clone requests per day would be an unreasonable amount of traffic for a project like GMP. That doesn’t sound like much traffic to me, especially since they reportedly have a 24 core CPU with 256GB of RAM. Is cloning a mercurial repo highly server intensive?
I dunno. To me it seems like if a web server can't deal with 700 simulatenous requests it should probably call it quits. They're of course within their rights to just block the connections but it certainly doesn't look like a denial of service attack to me. Submitting a link to HN probably causes even bigger traffic spikes.
700 simultaneous static requests certainly. 7,000+ in fact. Even 700 average requests for dynamic content. But each of those request was to clone a repo which is not an average dynamic request: each require a fair amount of CPU time (and possibly IO thought hopefully the server(s) have enough RAM for cache for that but to be the case).
Sure, but even if each clone tied up an entire core of their Epyc 7402P for 5 seconds (which seems pessimistic to me) the entire traffic spike would be over in 2.5 minutes.
I'm confused as well. Seems like a negligible amount of traffic at first glance. The administrator mentioned compression, could it really have such a big impact?
^ So much this. From the assumption of malicious activity (which is a far leap given such a predictable pattern of calls), to bragging about “server-class hardware” and “great connectivity”, this doesn’t seem like a super solid setup.
In before “it’s just one guy”: there are a thousand ways to solve this that are not expensive or complicated.
Should the offending party have been a better consumer? Yes.
Is it fair to entirely blame the user versus implementing additional caches and safeguards to make it an annoyance and not the end of the world emergency GMP is making it out to be? Definitely not.
Hyperbole never ceases to amaze me. On one hand, I know how wasteful "CI" systems are. We offer a docker image from a custom docker registry. Since we started offering it 3 years ago, we've had 1 billion pulls. 990 million pulls were from CI systems. But to claim that the operator of those CI systems is "attacking" us would be pretty bizarre. Though bizarre seems to govern online discourse when it comes to most things
Those 700 clones would all hit at exactly the same time. That's quite a load for a single server, especially since Mercurial can't be cached that easily.
Mercurial clones can be cached quite easily with 'clonebundles', a Mercurial feature that allows redirecting a clone to instead download a single 'bundle' (which could come from a different server or set of servers).
That’s in line with the response I’m used to get from cybersecurity teams at the large company I work for. It is neither reasonable nor appropriate in tone but I have got used to it being apparently the best they can do/can be bothered to write.
[1] https://gmplib.org/list-archives/gmp-devel/2023-June/006169....