this post was submitted on 06 Aug 2023
14 points (88.9% liked)

Selfhosted

40330 readers
377 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago
MODERATORS
 

I'd asked about using a VPS to get better routing to my homelab in this post: https://lemmy.world/post/1424540

I've narrowed down my problem- if i use a subdomain in my caddyfile, performance is 1/3 or worse compared to just the root.

example.com {reverse_proxy 192.168.1.57}

will saturate my gigabit lan connection at 980ish. On a 5gUW connection i get my advertised 50 mbit or more

librespeed.example.com {reverse_proxy 192.168.1.57}

I get 220-250 megabits on my internal lan. The same 5gUW connection will only get 7 or 8 mbit.

It's strange to me that everything seems to work just fine, but it's just slow. Anyone got any ideas?

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 2 points 1 year ago (1 children)

I can't remember if it's enabled by default or not, but it's easy enough to enable pprof and get a helpful performance profile from /debug/pprof. See https://caddy.community/t/hangs-on-reload/12010/18 for an example.

I've found that even being unfamiliar with the codebase, it's often pretty easy to identify what part of the call stack is being slow and file a very useful performance but report in GitHub. Check out the profile and see if it leads to any obvious conclusions about why domains are so much slower. There may be some function that's trivial to cache the results of that brings things back to the expected performance.

[–] [email protected] 2 points 1 year ago

The profiles were totally different- because the subdomain uses HTTP/3 via the quic-go library. Disabling it globally has it working at 100%