6
Apologies for the downtime
(burggit.moe)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 14 Jun 2023
6 points (100.0% liked)
Announcements
177 readers
2 users here now
Announcements/Changelogs go here.
founded 1 year ago
MODERATORS
This would explain the rare cases of posts having an entirely different comments.
I've used NGINX for load balancing and caching, but none of my projects have ever gotten this large. Dynamic content like Lemmy responses shouldn't be cached as data is unique for every user. Static content like imgs, vids, ext; would be improved by caching. I suggest caching the
/pictrs/image/route, should make large images load faster.For caching Lemmy data, I'd suggest Redis, but idk if Lemmy currently supports it.
Yeah, for some reason I thought haproxy had its own way of dealing with dynamic content. I didn't seem to have any problems perusing my selfhosted stuff that doesn't get much traffic, so I just assumed that that was the case.
Currently I use Caddy, and its caching module is more designed for distributed caching so I've been having Caddy proxy requests to haproxy within the same docker network and having haproxy proxy all requests to my box here from the VPS that both Caddy and haproxy are on.
The big reason I don't just use nginx is because Caddy has support for http/3 whereas for nginx, it's still being developed. I'm not sure if that makes a huge difference but it sure sounds that way since http/3 uses UDP and not TCP, meaning handshakes aren't a thing.
AFAIK Lemmy doesn't have support for Redis, otherwise I would've jumped on that the second I found out about it.
That being said, I'll look at the docs more and see on how to cache just the /pictrs/image endpoint.
Went with Varnish instead of haproxy since haproxy can only do caching in-memory. And images are only being cached now.