I host a few sites and I haven’t had a problem yet. Sure, logs suggest a majority of traffic is bots, but the cheap VPS I’m hosting on hasn’t melted so I haven’t been motivated to do anything about it.
Lemmy is particularly susceptible. Hosting a static site with a limited number of pages is fine. Lemmy needs to check all posts, find the votes, sort them, and compile the page. It does that for practically every page load, and so loading a page once is quite “expensive”.
Then add on to that the almost unlimited pages of content for bots to crawl through, bots just get caught endlessly scraping pages. Even powerful servers struggle, which is why most Lemmy instances have implemented some sort of protection against bots.
4chan has been ‘static’ forever, the backend builds each page every ~15s, pages served to users are always static. It’s ‘justwerked’ for 20 years now on a shoestring.
Lemmy is built as a separate web app and back end that communicate via APIs. It makes it easy to support apps and alternate web interfaces, unlike Piefed which only started adding an API reasonably recently and doesn’t have a fraction of the eco system that Lemmy has.
But I think an important part is that Lemmy is explicitly customised for users. While bots are getting the same logged out version, the intent of Lemmy is not to be scraped by bots but it’s to be custom for each user. You’re supposed to log in, subscribe to communities you like, block people you don’t like, and have posts you’ve already seen hidden (if you set this in your settings).
Serving a custom page to each user based on their settings, blocks, and subscriptions isn’t really suited to static pages.
Sounds like 4chan rolled their own server-side page cache. It probably made more sense for 4chan to do that then, back when the internet was still pretty new.
Nowadays there are a few packages that perform a similar function, like Varnish. Varnish picks up requests from the internet and where possible, it returns the response as static HTML from its own cache.
There are other types of caching at different stages of the request lifecycle that can reduce the gap between dynamic and static website performance.
There were attempts to rewrite imageboard software with modern dynamic frameworks and caching infrastructure, but it scaled worse than oldschool index and thread html regeneration on post event, and was cancelled. The effort was called something like Infinity, by 8chan.
I think this is the photography site he’s talking about.
He mentioned “so many scrapers hit my site that it saturated my upload with generated content feeding the them.” which seemed unusual to me. I’m not sure why such a site would have a public upload. It doesn’t feel like a site that would have a technical challenge with the scrapers, but I also get the impression the main issue is the thought of hosting all his photos just for AI scrapers to train their image generation models.
Parts will be cached but it’s per instance. For a 100 user instance, what are the chances that a recent cache of All page 74 is available? Bots are crawling every page, and most pages are content from last month, last year, or 3 years ago.
I would expect Lemmy instances to have some limiters set for guest connections, especially for ones coming from datacenters. Like, it should be easy and senseful to only link and cache up to All page 10, or Hot page 5, and refuse guest loads of anything beyond that.
I host a few sites and I haven’t had a problem yet. Sure, logs suggest a majority of traffic is bots, but the cheap VPS I’m hosting on hasn’t melted so I haven’t been motivated to do anything about it.
Lemmy is particularly susceptible. Hosting a static site with a limited number of pages is fine. Lemmy needs to check all posts, find the votes, sort them, and compile the page. It does that for practically every page load, and so loading a page once is quite “expensive”.
Then add on to that the almost unlimited pages of content for bots to crawl through, bots just get caught endlessly scraping pages. Even powerful servers struggle, which is why most Lemmy instances have implemented some sort of protection against bots.
Why not just use more static pages?
4chan has been ‘static’ forever, the backend builds each page every ~15s, pages served to users are always static. It’s ‘justwerked’ for 20 years now on a shoestring.
Lemmy is built as a separate web app and back end that communicate via APIs. It makes it easy to support apps and alternate web interfaces, unlike Piefed which only started adding an API reasonably recently and doesn’t have a fraction of the eco system that Lemmy has.
But I think an important part is that Lemmy is explicitly customised for users. While bots are getting the same logged out version, the intent of Lemmy is not to be scraped by bots but it’s to be custom for each user. You’re supposed to log in, subscribe to communities you like, block people you don’t like, and have posts you’ve already seen hidden (if you set this in your settings).
Serving a custom page to each user based on their settings, blocks, and subscriptions isn’t really suited to static pages.
Sounds like 4chan rolled their own server-side page cache. It probably made more sense for 4chan to do that then, back when the internet was still pretty new.
Nowadays there are a few packages that perform a similar function, like Varnish. Varnish picks up requests from the internet and where possible, it returns the response as static HTML from its own cache.
There are other types of caching at different stages of the request lifecycle that can reduce the gap between dynamic and static website performance.
There were attempts to rewrite imageboard software with modern dynamic frameworks and caching infrastructure, but it scaled worse than oldschool index and thread html regeneration on post event, and was cancelled. The effort was called something like Infinity, by 8chan.
Back in the day people used Squid for that if they needed it.
I believe you, but the linked article is not about hosting Lemmy.
No it’s not, it was more of a tangential comment.
I think this is the photography site he’s talking about.
He mentioned “so many scrapers hit my site that it saturated my upload with generated content feeding the them.” which seemed unusual to me. I’m not sure why such a site would have a public upload. It doesn’t feel like a site that would have a technical challenge with the scrapers, but I also get the impression the main issue is the thought of hosting all his photos just for AI scrapers to train their image generation models.
I interpreted that as LP having the site running in their basement, and responding to scrapers saturates their outgoing bandwidth.
It doesn’t need to. Like any similar site, it can cache a lot of that in databases like redis, or cache the rendered page in part or in whole.
Parts will be cached but it’s per instance. For a 100 user instance, what are the chances that a recent cache of All page 74 is available? Bots are crawling every page, and most pages are content from last month, last year, or 3 years ago.
I would expect Lemmy instances to have some limiters set for guest connections, especially for ones coming from datacenters. Like, it should be easy and senseful to only link and cache up to All page 10, or Hot page 5, and refuse guest loads of anything beyond that.