Skip to content
Register

Bandwidth overages: my CDN origin pull got expensive fast

Dedicated Servers Locked by Joy 25 replies 2.4K views
This thread is locked — new replies are not accepted. (Necro-bump on a two-year-old thread)
Joy

Member OP

#1

Bandwidth overages: my CDN origin pull got expensive very pasy xixixi

I am buy yesterday the OVHcloud origin shield plan very cheap lah. But now my bill is 3x because I am not understand the cache header xixixi. My origin is pull very very much data. I am think the shield will reduce but actually is multiply by three lah.

I am set the TTL to 0 because my content is dynamic. Now every request go through shield then edge then back to shield xixixi. Very expensive mistake.

Can someone review my architecture? I am attach diagram. The egress is 12TB this month very scary lah.

Origin → Shield → Edge → User
↑_________|

This loop is bad right xixixi?

kate3

Member

#2

Your shield configuration is acting as a cache miss amplifier, not a cache hit layer. The virtualization tax here is conceptual: you're layering abstraction without understanding the data flow.

With proper kernel page cache tuning and cgroup memory limits on your origin, you'd see better results than this three-hop design. OpenVZ containers would make this worse by sharing kernel memory pressure; thankfully you're on KVM.

Check your Cache-Control headers. If s-maxage is absent and you force no-cache, the shield revalidates per-request. The edge then revalidates against shield. Two origin pulls per user request, minimum.

What's your current hit ratio at each tier?

virsh list --all | wc -l: 47
cpanelliw780

Member

shared hosting survivor

#3

Lol yeah I seen this before the shield isnt a shield its a mirror facing another mirror I had a client do this with Hetzner once and their bill was like whoa no offense carl but carl knows carl knows what you want is either cache it proper or dont cache at all and pipe straight to edge the middle layer only helps if it actually caches your diagram has that arrow going back up thats the killer right there set your ttl to something real or bypass shield entirely also check if your provider charges for shield-to-origin thats the hidden gotcha

Nadia

Member

/dev/null enthusiast

#4
kate3 said:
Two origin pulls per user request

Your bytes are being piped to /dev/null via the long route. Three layers, zero caching, maximum egress. The requests aren't being redirected—they're multiplying like a fork bomb without PID limits.

| shield should absorb origin load
| your shield absorbs nothing
| edge absorbs nothing
| origin absorbs everything, thrice

Pipe your logs to awk. Count unique requests versus origin hits. The ratio will EOF your optimism.

Have you considered the shield itself might be your biggest vulnerability, not your origin EOF

/dev/null: full of good ideas
DH

Member

#5

One moving part beats three
One cache layer with understanding
Beats three with confusion

kasper_quelle

Member

Uptime Junkie

#6

I had the same issue with cache headers once, very painful lah

PU

Member

#7

What's your origin OS and kernel version?

jihoonred86

Member

Seoul

2 #8

Joy, you need to separate your truly dynamic from your pseudo-dynamic. API responses? Cache 5 seconds. User dashboards? Cache 30 seconds with stale-while-revalidate. Your TTL 0 is a nuclear option.

I run similar load in Seoul. My origin is Hetzner Helsinki — https://www.hetzner.com/cloud — edge is Cloudflare. Hit ratio 94%. Egress under 800GB/month for 8TB delivered. The math works if you work the math.

What is your actual cacheable ratio? Not everything needs to be dynamic just because it changes sometimes.

Joy

Member OP

1 #9
jihoonred86 said:
API responses? Cache 5 seconds

I am think API must fresh always xixixi. But you are right maybe 5 second is ok for my use case. I am check the ratio now.

My origin is OVHcloud Gravelines. The shield is also OVHcloud. Edge is... also OVHcloud xixixi. Maybe this is the problem all same provider?

kate3

Member

#10
Joy said:
All same provider

Same provider isn't the issue. Same network path without differentiation is. OVHcloud bills internal transit between their own zones in some configurations. Shield to origin isn't free just because both say OVHcloud.

Your diagram shows the loop. The real question is whether that upward arrow is charged egress or internal. Check your bill line items. If shield→origin is metered at external rates, you've built a very expensive yo-yo.

Also: what is your kernel? You ignored PureEuorg's question.

virsh list --all | wc -l: 47

Thread closed

Replies are closed on this thread. Necro-bump on a two-year-old thread.