Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenFreeMap survived 100k requests per second

blog.hyperknot.com

Post reply on HN
Print view View original

41–50 of 140 posts

Re: OpenFreeMap survived 100k requests per second

#41

Post by RandomBacon »

jwilk wrote: post #27
do_anh_tu wrote: post #4

Earlier quoted context omitted.

Do you even read the article?

From the HN Guidelines https://news.ycombinator.com/newsguidelines.html >: > Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that".

That guideline is decent I guess.

I am disappointed that they edited another guideline for the worse:

> Please don't comment about the voting on comments. It never does any good, and it makes boring reading.

It used to just say, don't complain about voting.

If the number of votes are so taboo, why do they even show us the number or user karma (and have a top list)?

Re: OpenFreeMap survived 100k requests per second

#42

Post by hyperknot »

sour-taste wrote: post #36

Since the limit you ran into was number of open files could you just raise that limit? I get blocking the spammy traffic but theoretically could you have handled more if that limit was upped?

I've just written my question to the nginx community forum, after a lengthy debugging session with multiple LLMs. Right now, I believe it was the combination of multi_accept + open_file_cache > worker_rlimit_nofile.

https://community.nginx.org/t/too-many-open-files-at-1000-re...

Also, the servers were doing 200 Mbps, so I couldn't have kept up _much_ longer, no matter the limits.

Re: OpenFreeMap survived 100k requests per second

#43

Post by toast0 »

rtaylorgarlock wrote: post #25

Is it always/only 'laziness' (derogatory, i know) when caching isn't implemented by a site like wplace.live ? Why wouldn't they save openfreemap all the traffic when a caching server on their side presumably could serve tiles almost as fast or faster than openfreemap?

Why should they when openfreemap is behind a CDN and their home page says things like:

> Using our public instance is completely free: there are no limits on the number of map views or requests. There’s no registration, no user database, no API keys, and no cookies. We aim to cover the running costs of our public instance through donations.

> Is commercial usage allowed?

> Yes.

IMHO, reading this and then just using it, makes a lot of sense. Yeah, you could put a cache infront of their CDN, but why, when they said it's all good, no limits, for free?

I might wonder a bit, if I knew the bandwidth it was using, but I might be busy with other stuff if my site went unexpectedly viral.

Re: OpenFreeMap survived 100k requests per second

#44

Post by eszed »

LorenDB wrote: post #16
keketi wrote: post #8

Earlier quoted context omitted.

Are you new? Nobody actually reads the articles.

False. I almost never upvote an article without reading it, and half of those upvotes are because I already read something similar recently that gave me the same information.

I'll submit in the second case (already read something similar) that, properly speaking, we should read both, and upvote (or submit, if not already here) the better of the articles.

Not that, you know, I often take the time to do that, either - but it would improve the site and the discussions if we all did.

Re: OpenFreeMap survived 100k requests per second

#45

Post by eszed »

charcircuit wrote: post #20
columb wrote: post #15

Earlier quoted context omitted.

You are so entitled... Because of you most nice things have "no limits but...". Not cool stress testing someone's infrastructure. Not cool. The author of this post is more than understanding, tried to fix it and offered a solution even after blocking them. On a free service. Show us what you have done.

>You are so entitled That's how agreements work. If someone says they will sell a hamburger for $5, and another person pays $5 for a hamburger, then they are entitled to a hamburger. >On a free service. It's up to the owner to price the service. Being overwhelmed by traffic when there are no limits is not a problem limited only to free services.

Sure, and if you bulk-order 5k hamburgers the restaurant will honor the price, but they'll also tell you "we're going to need some notice to handle that much product". Perfect analogy, really. This guy handled the situation perfectly, imo.

Re: OpenFreeMap survived 100k requests per second

#46

Post by ndriscoll »

hyperknot wrote: post #42
sour-taste wrote: post #36

Since the limit you ran into was number of open files could you just raise that limit? I get blocking the spammy traffic but theoretically could you have handled more if that limit was upped?

I've just written my question to the nginx community forum, after a lengthy debugging session with multiple LLMs. Right now, I believe it was the combination of multi_accept + open_file_cache > worker_rlimit_nofile. https://community.nginx.org/t/too-many-open-files-at-1000-re... Also, the servers were doing 200 Mbps, so I couldn't have kept up _much_ longer, no matter the limits.

One thing that might work for you is to actually make the empty tile file, and hard link it everywhere it needs to be. Then you don't need to special case it at runtime, but instead at generation time.

NVMe disks are incredibly fast and 1k rps is not a lot (IIRC my n100 seems to be capable of ~40k if not for the 1 Gbit NIC bottlenecking). I'd try benchmarking without the tuning options you've got. Like do you actually get 40k concurrent connections from cloudflare? If you have connections to your upstream kept alive (so no constant slow starts), ideally you have numCores workers and they each do one thing at a time, and that's enough to max out your NIC. You only add concurrency if latency prevents you from maxing bandwidth.

Re: OpenFreeMap survived 100k requests per second

#47

Post by hyperknot »

ndriscoll wrote: post #46
hyperknot wrote: post #42

Earlier quoted context omitted.

I've just written my question to the nginx community forum, after a lengthy debugging session with multiple LLMs. Right now, I believe it was the combination of multi_accept + open_file_cache > worker_rlimit_nofile. https://community.nginx.org/t/too-many-open-files-at-1000-re... Also, the servers were doing 200 Mbps, so I couldn't have kept up _much_ longer, no matter the limits.

One thing that might work for you is to actually make the empty tile file, and hard link it everywhere it needs to be. Then you don't need to special case it at runtime, but instead at generation time. NVMe disks are incredibly fast and 1k rps is not a lot (IIRC my n100 seems to be capable of ~40k if not for the 1 Gbit NIC bottlenecking). I'd try benchmarking without the tuning options you've got. Like do you actuall…

Yes, that's a good idea. But we are talking about 90+% of the titles being empty (I might be wrong on that), that's a lot of hard links. I think the nginx config just need to be fixed, I hope I'll receive some help on their forum.

Re: OpenFreeMap survived 100k requests per second

#48

Post by toast0 »

010101010101 wrote: post #18
charcircuit wrote: post #9

>Nice idea, interesting project, next time please contact me before. It's impossible to predict that one's project may go viral. >As a single user, you broke the service for everyone. Or you did by not having a high enough fd limit. Blaming sites when using it too much when you advertise there is no limit is not cool. It's not like wplace themselves were maliciously hammering the API.

Do you expect him just to let the service remain broken or to scale up to infinite cost to himself on this volunteer project? He worked with the project author to find a solution that works for both and does not degrade service for every other user, under literally no obligation to do anything at all. This isn’t Anthropic deciding to throttle users paying hundreds of dollars a month for a subscription. Constructive c…

The project page kind of suggests he might scale up to infinite cost...

> Financially, the plan is to keep renting servers until they cover the bandwidth. I believe it can be self-sustainable if enough people subscribe to the support plans.

Especially since he said Cloudflare is providing the CDN for free... Yes, running the origins costs money, but in most cases, default fd limits are low, and you can push them a lot higher. At some point you'll run into i/o limits, but I think the I/O at the origin seems pretty managable if my napkin math was right.

If the files are all tiny, and the fd limit is the actual bottleneck, there's ways to make that work better too. IMHO, it doesn't make sense to accept a inbound connection if you can't get a fd to read a file for it, so better to limit the concurrent connections and let connections sit in the listen queue and have a short keepalive time out to make sure you're not wasting your fds on idle connections. With no other knowledge, I'd put the connection limit at half the FD limit, assuming the origin server is dedicated for this and serves static files exclusively. But, to be honest, if I set up something like this, I probably wouldn't have thought about FD limits until they got hit, so no big deal ... hopefully whatever I used to monitor would include available fds by default and I'd have noticed, but it's not a default output everywhere.

Re: OpenFreeMap survived 100k requests per second

#50

Post by internetter »

perching_aix wrote: post #49

Haven't worked with Cloudflare yet first hand, and I'm not familiar with web map tech. But if the site really is pretty much just serving lots of static files, why is Hetzner in the loop? Wouldn't fully migrating to Cloudflare Pages be possible?

The tiles need to be rendered. Yes frequent tiles can be cached but you already have a cache… it’s Cloudflare. Theoretically you could port the tileserver to Cloudflare pages but then you’d need to… port it… and it probably wouldn’t be cheaper
Post reply on HN