Comment on A Project to Poison LLM Crawlers
douglasg14b@lemmy.world 4 days agoI assume that the gitea instance itself was being hit directly, which would make sense. It has a whole rendering stack that has to reach out to a database, get data, render the actual webpage through a template…etc
It’s a massive amount of work compared to serving up static files from say Nginx or Caddy. You can stick one of these in front of your servers, and cache http responses (to some degree anyways, that depends on gitea)
Benchmarks like this show what kind of throughput you can expect on say a 4 core VM just serving up cached files: blog.tjll.net/reverse-proxy-hot-dog-eating-contes…
90-400MB/s derived from the stats here on 4 cores. Enough to saturate a 3Gb/s connection. And caching intentionally polluted sites is crazy easy since you don’t care if it’s stale or not. Put a cloudflair cache on front of it and even easier.
vane@lemmy.world 3 days ago
You won’t get those numbers from internet requests, they do it locally or in cloud vpc, honestly those benchmarks are shit unless you are ISP. It’s because you have ISP and your router involved before you even receive request. If you have traffic from all over the world there is also speed of light delay. Then you have linux tcp/ip stack and number of open files.
I use openresty, I could add lru cache on top but it doesn’t even make sense because each bot just tries one unique request so you would have to generate html files manually instead of hosting gitea instance.
Gitea is on sqlite database on nvme so db doesn’t really matter. I could put the sqlite on ramdisk as server is using UPS so I don’t care about power outage but this would be ridiculous.
Anyways simplest way is just block ip ranges in firewall and move on.