DEV Community: Sergei Solod

AVA Hosting Said “No Sharing.” Linux Reported 32.73% CPU Steal

Sergei Solod — Tue, 01 Sep 2026 22:05:27 +0000

I expected to find a bug in my application.

Maybe Node.js was overloaded. Maybe Nginx was queuing requests. Maybe memory was running out. Maybe the disk was stalling.

Instead, mpstat showed this:

Average CPU steal: 32.73%
Average CPU idle:   0.00%

That changed the investigation completely.

This is not a negative review of AVA Hosting, and I am not claiming that every VPS they operate behaves like mine did.

This is simply what happened to one KVM VPS I used under a real production workload, how I diagnosed it, and why I eventually cancelled it.

The VPS

The configuration was small:

1 vCPU
2 GB RAM
25 GB NVMe
KVM

The workload was not synthetic.

Nginx was running.

The backend was running.

The server still had available RAM.

The filesystem was not full.

But requests were accumulating and the backend was not keeping up.

Instead of immediately upgrading the server, I wanted to know what resource was actually exhausted.

So I monitored it for 60 seconds.

No stress-ng.

No benchmark.

No artificial HTTP flood.

Just the real workload.

The 60-second CPU profile

The summary was:

vCPU count:             1

Average CPU user:       52.52%
Average CPU system:      8.07%
Average CPU softirq:     6.69%
Average CPU steal:      32.73%
Average CPU iowait:      0.00%
Average CPU idle:        0.00%

Maximum runnable queue: 11

The important part is how those percentages fit together.

About 52% was normal userspace work.

About 8% was kernel work.

Almost 7% was softirq.

And then:

steal: 32.73%
idle:   0.00%

The VM had no spare CPU.

But roughly one third of CPU accounting was also being reported as steal.

What `%steal` means

On a virtual machine, high CPU utilization and high CPU steal are not the same problem.

Suppose I had measured:

user + system: ~100%
steal:            0%
idle:             0%

That would be straightforward.

The workload consumed the CPU it was given.

I would either optimize the workload or buy more CPU.

steal means something different.

Conceptually:

guest has runnable work
        ↓
vCPU wants to run
        ↓
vCPU is not being executed
        ↓
Linux accounts the time as steal

KVM provides steal-time accounting specifically so a guest can observe time in which its virtual CPU was not running.

That does not tell me why the hypervisor did not schedule the vCPU.

From inside the VM I cannot see:

physical host utilization
number of neighbouring VMs
CPU overcommit ratio
scheduler policy
vCPU pinning
host-side quotas

But I can observe the effect from the guest.

And in this case the effect was large.

It wasn't one bad sample

A momentary 30% steal value would not have been enough for me.

Scheduler noise happens.

So I looked at the per-second samples.

They repeatedly looked like this:

%usr    %sys   %soft   %steal   %idle

53.54   10.10   5.05    31.31     0.00
56.44    6.93   5.94    30.69     0.00
51.52    7.07   6.06    35.35     0.00
55.45    6.93   5.94    31.68     0.00
51.49    8.91   5.94    33.66     0.00
52.53    7.07   7.07    33.33     0.00
52.48    6.93   7.92    32.67     0.00

Near the end:

50.98   10.78   6.86    31.37     0.00
48.48    8.08   9.09    34.34     0.00
55.00    5.00   7.00    33.00     0.00

The pattern persisted throughout the observation.

This was the average:

steal: 32.73%
idle:   0.00%

For intuition:

60 × 0.3273 = 19.64 seconds

That does not mean the VPS froze continuously for 19.64 seconds.

It means the smaller periods accounted as steal added up to roughly 19.6 seconds during that minute.

For a busy one-vCPU server, that is a huge amount of unavailable execution time.

Linux PSI showed the CPU was under constant pressure

I also checked Linux Pressure Stall Information:

some avg10=99.00
some avg60=99.12
some avg300=98.92

Later:

some avg10=99.19
some avg60=99.16
some avg300=98.98

So for almost the entire observation window, at least some runnable work was stalled waiting for CPU.

The load average was also around:

3.5 – 4.0

on a machine with:

1 vCPU

And the runnable queue reached:

None of those measurements alone proves a hypervisor problem.

Together with 32.73% steal, though, they described a machine with persistent CPU contention.

The application queue confirmed that this wasn't just an ugly metric

The backend process was alive.

That is an important distinction.

This was not:

backend crashed

It was:

backend running
but unable to keep up

Before the 60-second observation, its listening queue showed:

Recv-Q: 168
Send-Q: 511

After one minute:

Recv-Q: 166
Send-Q: 511

The interesting part is not 168 versus 166.

It is that the queue essentially did not drain.

The server spent a full minute processing traffic and remained just as far behind.

That connected the CPU metrics with an actual application symptom.

I checked memory

Before blaming the virtualization layer, I wanted to eliminate the boring explanations.

Memory looked like this:

RAM total:      ~1.9 GiB
RAM available:  ~959 MiB

Swap total:     2 GiB
Swap used:      ~33 MiB

Nearly a gigabyte was still available.

There was no obvious OOM event explaining the behavior.

So this did not look like memory exhaustion.

I checked the disk

The filesystem looked like this:

24 GB total
14 GB used
9.4 GB available
60% used

And, more importantly:

Average CPU iowait: 0.00%

The server was not sitting around waiting for storage.

The useful combination was:

iowait:  0.00%
idle:    0.00%
steal:  32.73%

At this point, adding RAM or cleaning the disk would have been solving a different problem.

Then I looked at AVA Hosting's CPU claims

This is where the incident became particularly interesting.

AVA currently describes its VPS resources as:

“Guaranteed resources — no sharing”

and says each VPS receives guaranteed vCPU resources whose performance is not affected by other customers.

Its Linux VPS page is more specific: AVA says that a CPU-intensive workload from another tenant cannot introduce steal time into another instance and describes its vCPU allocation as dedicated.

Its unmanaged VPS page goes further again, saying:

“CPU steal time is eliminated at the hypervisor level”

and describing CPU resources as isolated rather than a shared or burstable pool.

That is a much stronger claim than simply advertising:

1 vCPU

A vCPU does not automatically mean one private physical CPU core.

Virtualization does not work that way by default.

But AVA's own wording specifically addresses resource sharing and CPU steal.

My VM reported:

Average CPU steal: 32.73%

That is the contradiction that mattered to me.

What this does and does not prove

I want to keep this technically narrow.

My measurements establish what happened inside my VM.

I observed:

1 vCPU
32.73% average CPU steal
0% CPU idle
~99% CPU pressure
runnable queue up to 11
backend queue that would not drain
0% average CPU iowait
substantial RAM still available

I cannot use those measurements to prove:

intentional overselling
exact host occupancy
number of neighbouring VMs
specific neighbour activity
AVA's physical CPU topology
exact hypervisor configuration

I also tested one VPS, not AVA Hosting's entire infrastructure.

So my conclusion is deliberately narrower:

The VPS I received exhibited severe CPU steal under a real workload, and that behavior was difficult to reconcile with AVA's explicit claims about dedicated CPU allocation and the absence of neighbour-induced steal time.

That's enough.

Why I didn't upgrade to more vCPUs

At this point I could have bought a larger plan.

But I wanted to answer a basic question first:

Was my application simply consuming the CPU I purchased?

If the answer had been yes:

steal ≈ 0%
CPU saturated

then buying another vCPU would have been reasonable.

Instead:

steal = 32.73%

Buying additional vCPUs might still have improved throughput.

But I did not want to pay more before understanding why so much of the first vCPU's requested execution time was already being recorded as steal.

So I cancelled the VPS.

AVA refunded me in full

This part deserves to be included because it was handled well.

I requested a full refund.

AVA Hosting returned the entire amount quickly.

They did not spend days arguing with me about the measurements or trying to turn the issue into a long support exchange.

I explained the problem, requested the refund, and received it.

So my experience has two separate parts:

The VPS I received had a serious CPU-availability problem.

AVA handled the refund well.

Both are true.

The VPS check I use now

The practical lesson was not “never use one vCPU.”

It was not “KVM is bad.”

And it was not “every AVA VPS must behave like this.”

The lesson was that I should validate CPU behavior under the actual workload instead of trusting the specification alone.

These are now some of my first checks on a new Linux VPS:

mpstat 1 60
vmstat 1 60

cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io

ss -ltnp

free -h
df -h

iostat -xz 1 60

I am looking for relationships between metrics.

High CPU, almost no steal

steal ≈ 0%
idle ≈ 0%

The workload probably needs more CPU.

High iowait

Investigate storage.

Memory pressure and swap activity

Investigate RAM.

High steal + zero idle + high CPU PSI + growing queues

Now I start looking beyond the application.

That combination is much more useful than simply saying:

“The VPS feels slow.”

A running service is not a healthy service

This incident also reinforced something easy to forget during production debugging.

These checks:

systemctl status nginx
systemctl status my-backend

can both say:

active (running)

while the system is already failing operationally.

A process can exist.

A TCP socket can listen.

Nginx can accept requests.

And the machine can still be unable to process incoming work fast enough.

That is why I now care much more about:

CPU scheduling
pressure
queues
latency

than whether a process merely exists.

The three numbers I remember from this incident

If I had to reduce the whole debugging session to three lines, they would be:

CPU steal:    32.73%
CPU idle:      0.00%
CPU pressure: ~99%

AVA Hosting says its VPS CPU resources are guaranteed without sharing and explicitly describes protection from neighbour-induced CPU steal.

My VPS reported otherwise.

I cancelled it.

AVA refunded everything quickly and without an argument.

And I added %steal to the list of metrics I check before trusting a new VPS with production traffic.

My REGXA VPS Had 94% CPU Steal With Zero Traffic

Sergei Solod — Mon, 31 Aug 2026 21:45:15 +0000

I am not writing this as a negative review of REGXA.

I am not trying to tell anyone whether they should or should not use the provider.

This is simply one of my days as a developer.

I moved a normal workload to a KVM VPS with:

2 vCPU
2 GB RAM
60 GB NVMe

Nginx was running.

The backend was running.

The machine was reachable.

But it behaved as if it were completely overloaded.

Requests accumulated. TLS operations became slow. Connections stayed open for far too long. Some requests eventually returned HTTP 504 after more than two minutes.

My first assumption was simple:

something inside my VPS was consuming all the CPU.

Then I ran mpstat.

Average CPU steal:   92.58%

CPU 0 steal:         90.62%
CPU 1 steal:         94.57%

CPU user:             4.02%
CPU system:           1.47%
CPU iowait:           0.41%
CPU idle:             0.53%

That changed the investigation completely.

My application was not consuming 90% of the processor.

It was barely getting CPU time at all.

CPU usage and CPU steal are very different things

If an application is genuinely CPU-bound, I expect something like this:

user:    80%
system:  10%
steal:    0%
idle:    10%

The VM is receiving CPU time and spending it on application or kernel work.

My VPS looked roughly like this:

user:     4%
system:   1%
steal:   93%
idle:     1%

%steal is time during which a virtual CPU is ready to run but the hypervisor does not schedule it.

So when I say that CPU time was being taken away from the VPS, I mean it in that specific virtualization sense.

I cannot prove that REGXA deliberately took physical cores assigned exclusively to me and gave them to another customer.

Guest metrics cannot prove that.

They also cannot prove intent.

What they can show is much simpler:

the VM had runnable work, but its vCPUs were repeatedly not being scheduled.

Individual samples kept landing in the same range:

89.85% steal
92.16% steal
96.48% steal
94.87% steal
95.69% steal
95.95% steal
94.57% steal
93.75% steal

CPU pressure pointed in the same direction:

CPU PSI some avg10:   79.47
CPU PSI some avg60:   75.32
CPU PSI some avg300:  76.31

Load average:
5.85 / 5.75 / 5.73

This was a two-vCPU machine.

There was clearly runnable work waiting for processor time.

But I still wanted to rule out the most obvious explanation:

my own workload.

I removed all production traffic

I moved the active workload to another server.

Then I stopped all production traffic to the affected VPS.

The request queues cleared.

I repeated the CPU test.

The result:

Average CPU steal:   94.17%

CPU 0 steal:         95.56%
CPU 1 steal:         92.83%

CPU user:             1.95%
CPU system:           0.59%
CPU iowait:           0.59%
CPU idle:             2.18%

CPU steal actually became worse.

The important combination was:

user:    1.95%
system:  0.59%
steal:  94.17%

My applications were almost idle.

Yet the VPS was still spending roughly 94% of measured CPU time waiting for the hypervisor.

vmstat samples were still showing:

91% steal
98% steal
98% steal
97% steal
97% steal
95% steal
96% steal
95% steal

At some points, as many as 15 runnable processes were waiting for CPU.

That was the strongest experiment in the entire incident.

Once the workload was gone, application CPU consumption could no longer explain what I was seeing.

localhost was taking seconds

Next I wanted to remove the external network from the equation.

So I tested HTTPS through:

127.0.0.1

That removes:

public DNS;
my ISP;
geographic distance;
internet routing;
upstream transit;
the public network path to the server.

The client and server were inside the same VM.

Under production traffic, I ran ten localhost HTTPS requests.

Four failed during the TLS handshake.

The successful ones took:

29.30 s
22.77 s
12.25 s
11.87 s
11.12 s
 9.40 s

Some TLS handshakes alone took around nine seconds.

For localhost.

After removing production traffic, localhost improved, but remained extremely inconsistent:

0.061 s
0.745 s
0.830 s
0.873 s
1.010 s
1.117 s
1.121 s
2.188 s
3.355 s

The same local operation could take:

61 ms

and then more than:

3.3 seconds

on another attempt.

That is not the kind of result I would explain with public networking.

The rest of the stack started backing up

The application-level symptoms were also visible in socket state.

At one point I had approximately:

450 established connections
122 orphaned connections
110 FIN-WAIT-1
33 CLOSE-WAIT

The backend listen queue on localhost reached around:

14–15

The HTTPS listen queue reached around:

Nginx logged requests like:

142.857 s  -> HTTP 504
138.902 s  -> HTTP 504
135.064 s  -> HTTP 504
129.819 s  -> HTTP 504
128.657 s  -> HTTP 504

Other requests remained open for roughly 67–130 seconds.

I also saw:

secure-connect timeout: ~35 s
secure-connect timeout: ~41 s
database network timeouts
delayed TLS operations

Looking at these individually could have sent me in completely different directions.

A 504?

Maybe Nginx.

Database timeout?

Maybe MongoDB.

Slow TLS?

Maybe networking.

Growing queues?

Maybe backend concurrency.

But all of those systems depend on the process being scheduled.

Increasing a timeout does not create CPU time.

It only allows the request to wait longer.

RAM and disk were not the bottleneck

Memory looked fine:

Total RAM:       ~1.9 GiB
Available RAM:   ~1.0–1.1 GiB
Swap used:       ~1–2 MiB

OOM events:      none
OOM killer:      none

Storage looked fine too:

Filesystem:      ~58 GB
Used:            ~11 GB
Available:       ~44 GB
Usage:           ~20%

During the important CPU measurements, I/O wait remained below 1%.

So I did not have:

exhausted memory;
heavy swapping;
OOM activity;
a full filesystem;
enough disk wait to explain the behavior.

The number that kept dominating the system was still:

%steal

I compared it with another KVM VPS

A useful diagnostic needs a control.

So I ran the same style of test on another KVM VPS that was actively handling normal traffic.

It reported:

Average CPU steal:   0.02%
CPU idle:           87.86%

CPU PSI avg10:       0.29
CPU PSI avg60:       0.63
CPU PSI avg300:      0.49

Load average:
0.47 / 0.33 / 0.14

Ten localhost HTTPS requests completed between roughly:

37 ms
and
69 ms

Later, I tested another production VPS that genuinely was CPU-busy:

CPU user:     61.71%
CPU system:    5.08%
CPU idle:     24.09%
CPU steal:     0.13%

That comparison made the difference very clear.

Busy because my application is running

user:   high
system: some
steal:  low

Busy because the guest is not getting scheduled

user:   low
system: low
steal:  extremely high

Both can result in a slow website.

But they require completely different debugging.

REGXA later confirmed resource contention

Until this point, I only had guest-side evidence.

I could see what Linux was reporting.

I could not see:

the physical host;
total host CPU load;
CPU quotas;
scheduler weights;
neighbouring VMs;
the provider's oversubscription level.

REGXA could.

Support eventually told me the VPS was running on:

shared CPU infrastructure

They explained that CPU resources were shared across multiple virtual machines and that performance could vary with physical-node load.

More importantly, they explicitly said that the elevated CPU steal I was observing resulted from:

resource contention on the underlying infrastructure

They also said the Frankfurt infrastructure was experiencing particularly high demand.

According to support, they could not change the CPU quotas or scheduling policy or provide additional dedicated CPU resources for that shared VPS.

The proposed solution was to move the VPS to a less-loaded location.

At that point, resource contention was no longer only my interpretation of mpstat.

It was also the provider's explanation.

The CPU wording was difficult to reconcile

This part bothered me.

The REGXA VPS material I had seen used wording around:

Dedicated CPU Cores

and guaranteed resources.

But support described my VPS as using shared CPU infrastructure whose performance depended on physical-node load.

I do not know the exact host configuration.

I cannot tell whether the immediate mechanism was:

CPU overcommitment;
CPU quotas;
scheduler weighting;
throttling;
another hypervisor configuration;
or some combination.

And again, I cannot prove intent.

What I can say is:

Under workload:
CPU steal = 92.58%

With production traffic removed:
CPU steal = 94.17%

And REGXA itself later attributed the elevated steal to resource contention on its shared infrastructure.

That is enough evidence for me to document what happened without pretending I know more than I do.

The refund became another part of the incident

Once the infrastructure issue was clear, I did not want to keep moving the VPS around and testing different nodes.

I wanted to cancel it.

Initially, I was offered only a partial refund.

And the proposed refund was not back to the card I had used.

It was REGXA account credit.

For me, provider credit is not the same thing as a refund if I am trying to stop using the provider.

So I kept replying.

I asked for:

100% of the payment

to be returned to:

the original payment method

It took additional back-and-forth.

Eventually, REGXA agreed and refunded the full amount to the original payment method, describing the full refund as an exception.

I appreciate that they eventually returned everything.

But having to keep pushing for the financial resolution after the infrastructure problem had already been acknowledged is also part of the experience.

The debugging lesson was more useful than the hosting story

The easiest mistake here would have been to keep optimizing my application.

I could have:

increased Nginx timeouts;
changed keepalive settings;
reduced concurrency;
added retries;
tuned connection pools;
investigated MongoDB;
rewritten backend code.

Some of those changes might have altered individual symptoms.

None would have answered the real question:

Why is the guest spending more than 90% of its CPU time waiting for the hypervisor?

That problem lives below the application layer.

My VPS smoke test now includes `%steal`

I no longer consider a new VPS healthy just because:

SSH works
Nginx starts
/health returns 200

I also check:

mpstat -P ALL 1 20

vmstat 1 20

cat /proc/pressure/cpu

And for a web server, I test localhost latency.

The metrics I care about are:

%user
%system
%iowait
%idle
%steal
CPU PSI
run queue
localhost latency

And when the result looks suspicious, I do one more test:

remove the workload and measure again.

That was the most useful step in this incident.

The final numbers were hard to misread:

CPU user:     1.95%
CPU system:   0.59%
CPU steal:   94.17%

I am not claiming that every REGXA VPS behaves like this.

I tested one VPS and documented what happened on that machine.

But in this case, the evidence was unusually clear:

my applications were barely using CPU;
Linux reported 92–94% steal;
localhost HTTPS became multi-second and sometimes failed;
the condition remained after production traffic was removed;
another KVM VPS behaved normally under comparable testing;
REGXA later attributed the elevated steal to resource contention on its shared infrastructure.

That is why I am writing this.

Not as a rating.

Not as a recommendation.

Just as one of my days as a developer — and one Linux metric I will never ignore on a VPS again.

I Used Bunny Storage Behind Nginx for Two Months. The Cache Was Fast, the Cold Path Wasn't

Sergei Solod — Fri, 28 Aug 2026 19:12:42 +0000

For almost two months, my media delivery path looked like this:

Browser
   ↓
Application / working server
   ↓
Nginx
   ↓
local proxy_cache
   ↓ cache MISS
Bunny Storage

Images, videos, and audio files lived in Bunny Storage.

Users did not access Bunny directly.

My Nginx server requested objects from Bunny Storage, authenticated to Storage on the server side, cached the response on local SSD, and then served the public URL itself.

On paper, this was a perfectly reasonable architecture.

And when the requested file was already in the Nginx cache, it was extremely fast.

The problem was everything that happened when it wasn't.

After two months of production logs, connection measurements, Nginx configuration changes, MP4 Range experiments, and some very specific ETag errors, I eventually replaced Bunny Storage as the runtime origin with a private media server connected over WireGuard.

The biggest lesson was not that self-hosting is universally better.

It was this:

A fast cache can hide a slow or unpredictable cold path for a surprisingly long time.

And for a media-heavy site, the cold path matters much more than I originally thought.

First, an important distinction: this was not Bunny CDN

I want to make this explicit because otherwise the comparison would be misleading.

I was not using Bunny CDN for this experiment.

I was using Bunny Storage directly as the storage origin behind my own Nginx proxy cache.

So my architecture was essentially:

My Nginx
   ↓
Bunny Storage API / storage endpoint

not:

User
   ↓
Bunny CDN
   ↓
Bunny Storage

Those are different architectures.

Bunny's normal Storage + Pull Zone/CDN setup adds a globally distributed delivery layer designed specifically for serving content to users.

That was not what I was testing.

I still think Bunny CDN is a very good product, and this article should not be read as "Bunny is bad."

This is about a much narrower question:

What happens when Bunny Storage itself becomes the runtime origin behind your own Nginx cache?

For my workload, the answer became increasingly complicated.

Why I built it this way in the first place

My workload is mostly immutable media:

AVIF
JPEG
PNG
MP4
WebM
audio
other static files

There are a lot of files, with very different sizes.

Some images are tiny.

Some videos are much larger.

I wanted storage separated from the working server, but I also wanted my own Nginx to control:

public URLs
cache headers
cache eviction
missing-file behavior
redirects
media fallbacks
byte ranges
video seeking
HTTP status codes

So I built a classic reverse-proxy cache:

                    ┌── HIT ── local SSD
                    │
Browser → Nginx cache
                    │
                    └── MISS ── Bunny Storage

The design had an obvious advantage.

A popular file only had to come from Bunny once.

After that:

Browser
   ↓
Nginx
   ↓
local SSD

No external storage connection.

No remote object transfer.

Very fast.

And that worked exactly as expected.

The mistake was judging the architecture mostly by what happened on a HIT.

A cache HIT tells you almost nothing about your origin

This sounds obvious now.

It did not feel obvious while the system was running.

A popular image gets requested frequently:

request
↓
cache HIT
↓
local SSD
↓
fast

A rarely visited image behaves differently:

old page
↓
file was evicted
↓
cache MISS
↓
connect to Bunny Storage
↓
retrieve object
↓
populate cache
↓
respond

This made older and less popular pages an accidental stress test of the real origin path.

And that is exactly where I started noticing something strange.

The popular pages felt fine.

Older pages could feel dramatically worse.

Sometimes one image would take much longer than everything around it.

Sometimes an image would appear to hang.

That pattern eventually made sense once I looked closely at the Nginx error logs.

The production logs showed that some requests were stalling before the file even started downloading

The most important errors looked like this:

upstream timed out
while connecting to upstream

and, even more interestingly:

upstream timed out ... while SSL handshaking to upstream

That distinction matters.

This wasn't:

large file
↓
slow download

It was sometimes:

cache MISS
↓
try to establish upstream connection
↓
TCP / TLS
↓
timeout

The actual media body had barely entered the picture yet.

Nginx was having trouble completing the connection to the remote storage endpoint.

That matched what I was seeing in the browser.

An image wasn't necessarily loading slowly.

Sometimes the useful transfer had not really started.

This was not a one-request anomaly

One diagnostic snapshot from July 30 contained:

upstream-timeout matches in the last:

5,000

lines of the media error log.

A snapshot from the previous day contained:

matches.

Those numbers are log matches, not unique users or unique failed objects.

I don't want to turn them into a metric they aren't.

But they do establish something useful:

This wasn't one unlucky request that happened to fail during debugging.

The failure pattern was occurring repeatedly in production.

It also wasn't one permanently bad Bunny Storage IP

During that period, the storage hostname resolved to addresses including:

109.61.89.53
109.61.89.54
109.61.89.55
109.61.89.57
79.127.226.193

I saw connection or TLS-related failures across different addresses in that set.

That does not tell me what the underlying root cause inside the network was.

From my logs alone, I cannot honestly say whether it was:

a storage backend
routing
peering
my hosting provider's path to Bunny
balancing behavior
another network component

I didn't isolate those variables.

What I can say is much narrower:

From my server, the external path to Bunny Storage occasionally failed to establish an upstream connection within the expected time.

That distinction matters.

I don't need to know which router or backend caused the delay to know that it existed in my application's critical path.

One measurement showed exactly why averages were misleading

I tested individual resolved Bunny Storage addresses.

Several paths looked completely reasonable:

109.61.89.53     total ≈ 29.8 ms
109.61.89.54     total ≈ 28.5 ms
109.61.89.57     total ≈ 42.7 ms
79.127.226.193   total ≈ 43.6 ms

Nothing alarming there.

But one measured path looked like this:

109.61.89.55

TCP    1.017782 s
TLS    1.048306 s
TOTAL  1.054474 s

That doesn't mean:

Bunny Storage has 1-second latency.

It clearly didn't.

Most of my measured paths were tens of milliseconds.

The interesting part was the variance.

I could get something like:

30 ms
29 ms
43 ms
1,054 ms

from paths behind the same storage hostname.

That one-second measurement happened before considering normal object-transfer time.

And production logs also showed cases that went beyond "slow" and reached actual connection or TLS timeouts.

This is where average latency becomes a dangerous metric.

For a gallery, p99 matters more than the average image

Imagine a page loading 80 images.

Suppose 79 of them load in:

30–50 ms

and one takes:

1,000 ms

The average can still look respectable.

The page does not.

The user experiences:

████ image
████ image
████ image
████ image

     [empty]

████ image
████ image
████ image

If another object hits a multi-second timeout, the experience becomes even worse.

The browser doesn't render "average latency."

It renders individual objects.

That's why media-heavy pages are especially sensitive to long-tail latency.

What matters is often not:

mean request time

but:

p95
p99
slowest cold object on the page

This became one of the most useful performance lessons from the entire migration.

Why older content exposed the problem more often

My old local Nginx media cache became large.

One July snapshot showed roughly:

cache size: ~36 GB
cache files: >355,000
configured limit: ~35 GB
root filesystem: ~93% used

Nearby snapshots approached:

~400,000 cache entries

The exact numbers changed as the cache evolved, but the important part was structural:

The cache could not hold everything forever.

So:

popular media
↓
frequent access
↓
likely still cached
↓
fast HIT

while:

old / rare media
↓
less frequently accessed
↓
more likely evicted
↓
MISS
↓
remote origin exposed

That explains something I found confusing at first.

Why could a site with a huge local cache still feel bad on random old pages?

Because the cache was making the good cases very good while doing nothing to eliminate the cost of the remaining cold misses.

Then video made the architecture much more complicated

Images were only half the story.

Video introduced a completely different problem.

Browsers don't necessarily download an MP4 from byte zero to the end.

They can request byte ranges.

For example:

Range: bytes=0-1048575

Then the user seeks somewhere else:

Range: bytes=50000000-51048575

The server can reply:

206 Partial Content

and return only the requested bytes.

This is essential for normal video seeking.

It also makes caching much more interesting.

My first approach: include the browser Range in the cache key

One early configuration effectively worked like this:

proxy_set_header Range $http_range;
proxy_set_header If-Range $http_if_range;

proxy_cache_key "$scheme|$host|$request_uri|range=$http_range";

proxy_cache_valid 200 206 301 302 30d;

This prevented two different byte ranges from incorrectly sharing one cache entry.

But there was an obvious downside.

Browser ranges are arbitrary.

One client may request:

bytes=0-1048575

another:

bytes=0-999999

another may seek and request:

bytes=58321473-59370048

So one physical MP4 could become:

video.mp4 + Range A → cache object A
video.mp4 + Range B → cache object B
video.mp4 + Range C → cache object C
video.mp4 + Range D → cache object D
...

I didn't measure how many gigabytes this fragmentation consumed, so I'm not going to invent a number.

But the fragmentation mechanism was directly visible in the cache key.

This made me look for something more deterministic.

Nginx Slice looked like the right solution

Nginx has a Slice module specifically for caching large resources in fixed-size segments.

Instead of arbitrary browser ranges:

0–734129
917283–1500000
2000000–2768129

I could normalize the cache into predictable pieces:

0–1 MB
1–2 MB
2–3 MB
3–4 MB
...

The relevant configuration looked roughly like this:

slice 1m;

proxy_set_header Range $slice_range;

proxy_cache_key "$scheme|$host|$uri|$slice_range";

proxy_cache_valid 200 206 30d;

This architecture is much cleaner for reuse.

A user asks for bytes somewhere inside:

1–2 MB

Nginx fetches and caches that normalized slice.

Another user later requests a different sub-range inside the same chunk.

The same cached slice can potentially satisfy it.

Great.

Except production started showing this:

etag mismatch in slice response while reading response header from upstream

That error became one of the most interesting parts of the whole investigation.

The video problem was ETag consistency, not "different signatures"

When I first tried to describe the issue informally, I thought of the pieces as having different "signatures."

That's not the correct technical description.

The relevant HTTP value was:

ETag

Not:

AccessKey

Not a signed URL.

Not a cryptographic signature.

An ETag is a validator for a particular representation of a resource.

Conceptually, Nginx wants something like:

slice 1
bytes 0–1 MB
ETag: A

slice 2
bytes 1–2 MB
ETag: A

Both pieces appear to belong to the same representation.

Now imagine this:

slice 1
ETag: A

slice 2
ETag: B

Nginx has a very good reason not to blindly combine those pieces.

They may represent different versions of the underlying file.

If it continued anyway, the final response could theoretically become:

first part of version A
+
second part of version B

That's corrupt data.

So Nginx aborting the sliced transaction is protective behavior.

And this wasn't theoretical — I had the exact error in production

On July 30, repeated slice subrequests for one MP4 generated:

etag mismatch in slice response

while requests were reaching storage addresses including:

109.61.89.53
109.61.89.57
79.127.226.193
109.61.89.55

On July 31, the same class of error appeared again for another MP4 while slice requests moved among addresses from the same storage pool.

What does that prove?

It proves:

Nginx received slice responses for the same MP4 whose validators were not consistent enough for Nginx to safely assemble them.

What does it not prove?

It does not prove exactly why the ETags differed.

At the time I did not log the literal ETag returned by every individual subrequest.

So I cannot honestly reconstruct the exact internal mechanism.

The movement between different upstream addresses makes backend-response inconsistency a plausible explanation.

But that's an inference.

The production fact is the Nginx error itself.

This does NOT mean Bunny Storage cannot serve Range requests

This distinction is important.

Range requests themselves worked.

I was receiving and caching:

206 Partial Content

So the lesson is not:

Bunny Storage does not support byte ranges.

The narrower issue was the combination of:

Nginx Slice
+
multiple upstream responses
+
ETag consistency required by Nginx

And video could simultaneously suffer from the other problem:

upstream timed out while connecting to upstream

So video had two independent failure modes:

Origin connection / long-tail latency
Slice / ETag consistency

That made the overall system much harder to reason about.

I eventually stopped using Slice for MP4

I later moved MP4 back toward ordinary browser Range behavior.

Conceptually:

proxy_set_header Range $http_range;
proxy_set_header If-Range $http_if_range;

proxy_cache_key "$scheme|$host|$uri";

proxy_no_cache $http_range;

proxy_cache_valid 200 30d;

Partial responses would no longer be allowed to masquerade as complete cached files.

That removed the problematic sliced MP4 assembly.

But it exposed a trade-off.

A cold video Range might now require:

Browser
↓
Nginx
↓
MISS
↓
external storage origin

again.

I had fixed one layer of complexity by becoming more dependent on another.

At some point I had to ask a more fundamental question.

I realized I was building part of a CDN in front of a storage service

Look at the mechanisms I had accumulated:

proxy_cache
cache locking
stale responses
background updates
custom cache keys
Range handling
206 Partial Content
Nginx Slice
normalized 1 MB chunks
upstream keepalive
TLS session reuse
connection retries
timeout tuning

None of these are bad features.

They are useful tools.

But together they made me ask:

What do I actually need from my origin?

My answer was surprisingly boring.

I needed something that could:

store immutable files
+
return their bytes

That's it.

I wasn't trying to build a globally distributed public edge network between my two servers.

I had one working server that needed media from one storage server.

So I tried the simplest possible version of that architecture.

The replacement: a boring private media origin

The new design is:

Browser
   ↓
Working server
   ↓
Nginx + local media cache
   │
   ├── HIT
   │
   └── MISS
          ↓
      WireGuard
          ↓
     Media server
          ↓
        Nginx
          ↓
         SSD

The media server does almost nothing.

It stores files.

Nginx serves them.

The origin listener is private.

The working server connects to a fixed private address over WireGuard.

Public HTTPS still terminates on the working server.

Inside the encrypted WireGuard tunnel, the origin connection can be plain HTTP:

http://private-ip:port

I don't need a second TLS negotiation inside a tunnel that is already encrypted.

Why a tiny server is enough for this kind of job

For a pure static-file origin, the application logic is basically nonexistent.

There is no:

SSR
database
application runtime
authentication system
template rendering
expensive API logic

The critical resources are much more boring:

enough SSD capacity
enough sequential/random disk performance
enough network throughput
enough file descriptors
sensible Nginx connection limits

For this kind of role, I'd consider a machine in the class of:

~1 vCPU
~1 GB RAM
hundreds of GB of SSD

as a reasonable starting point for a small static origin, assuming the expected bandwidth, concurrency, and disk behavior fit.

That's not a universal sizing rule.

My current validation host has more headroom, so the latency numbers below should not be interpreted as a scientific benchmark of exactly a 1-vCPU / 1-GB machine.

The point is architectural:

Static file origins are cheap workloads compared with many application workloads.

The new cold path has far fewer moving parts

The old MISS path looked approximately like this:

Working server
↓
public DNS
↓
one of several storage addresses
↓
public network path
↓
TCP connection
↓
TLS handshake
↓
Storage request
↓
object

The new path looks like:

Working server
↓
WireGuard
↓
fixed private IP
↓
Nginx
↓
SSD

The network still exists.

Encryption still exists.

Failure is still possible.

But I removed variables that did not add much value to this specific one-to-one origin relationship.

Most importantly, the cold path became predictable.

The difference was immediately visible in the measurements

After the migration, small real-file Range requests from the working server to the media origin were generally around:

CONNECT ≈ 9.5–12.5 ms
TTFB    ≈ 19–23 ms
TOTAL   ≈ 19–23 ms

I ran sequential and parallel checks.

Results included:

10/10 successful
20/20 sequential successful
20/20 parallel successful

On the media origin itself, the same small local request typically took roughly:

0.5–0.9 ms

That tells me something useful about where the ~20 ms comes from.

The origin isn't spending 20 ms finding the file.

Most of that time is the network path between the two machines.

Which is exactly what I want from a boring static origin.

Important: this does not mean a full video downloads in 20 ms

This distinction is easy to lose when discussing latency numbers.

My:

~20 ms

measurements were small Range/TTFB-style tests.

They measure the cost of reaching the origin and starting to receive useful data.

500 MB

video obviously does not transfer completely in 20 ms.

Full transfer time depends on:

file size
÷
available throughput

The win here was not infinite bandwidth.

The win was making the cold connection path cheap and stable.

Comparing one observed old outlier with the new path

Remember the old measurement:

1.054474 seconds

And the new cold request:

~20 ms

Mathematically:

1054 ms / 20 ms ≈ 52×

That comparison is striking.

But it needs to be stated correctly.

I am not claiming:

My media server is 52× faster than Bunny Storage.

That would be a terrible benchmark.

I am saying:

One real old origin path I measured took about 1.054 seconds, while my current cold origin requests are around 20 ms.

Those are two observed network paths.

The normal old Bunny measurements were much better:

~29–44 ms

The important difference was not merely the best case.

It was the tail.

I cared about eliminating this:

30 ms
31 ms
43 ms
1,054 ms
timeout

and getting something much closer to:

20 ms
20 ms
21 ms
19 ms
22 ms

For perceived web performance, reducing variance can matter more than improving an already-good average.

Something surprising happened: I no longer needed a huge cache to make old pages feel fast

My old media cache had grown to roughly:

35–36 GB

and hundreds of thousands of cache entries.

The new cache did not need to immediately grow anywhere near that size.

At my latest check it was only around:

3.9 GB

with:

max_size = 25 GB
min_free = 8 GB

Yet old pages felt dramatically faster.

That initially sounds backwards.

The old cache was much larger.

Shouldn't it have been better?

The answer is that the two systems optimize different things.

Old system:

HIT  = very fast
MISS = unpredictable

New system:

HIT  = very fast
MISS = also fast

A larger cache reduces how frequently you miss.

A good origin reduces the cost of every miss.

I had spent a lot of time optimizing the first variable.

The second one turned out to matter more.

MP4 became simpler after the origin moved too

With a private, predictable origin, I can use a much simpler MP4 strategy.

For some MP4 files, I can let a cold request trigger a full-object cache fill:

cold MISS
↓
request full MP4 from private origin
↓
store one complete local cache object
↓
serve browser byte ranges locally

Once the complete MP4 exists locally, Nginx can satisfy normal browser Range requests from that cached file.

Conceptually:

Browser
   ↓ Range
Working Nginx
   ↓
complete MP4 in local cache
   ↓
206 Partial Content

No remote slice assembly.

No arbitrary remote Range fragments becoming separate cache objects.

No need to combine pieces fetched from different storage responses.

One file.

One cache entry.

Normal local byte-range serving.

But full-object caching is not free either

There is a trade-off here.

Suppose the MP4 is:

500 MB

The first viewer watches:

10 seconds

If my cache strategy fills the entire object, the origin may still send all:

500 MB

to the working server.

A pure Range request could have transferred far less.

For my file sizes and access patterns, I accept that trade-off because subsequent seeking and subsequent viewers can reuse one simple local object.

But I would not blindly use this design for every video workload.

For a library of mostly cold, multi-gigabyte videos, I would evaluate things such as:

stable cache slicing
HLS
DASH
a real video CDN
Bunny Stream
another dedicated video platform

Architecture follows workload.

The important change is that I now get to make that decision based on video behavior, instead of also fighting an unpredictable origin path underneath it.

Nginx Slice is not the villain either

I want to be equally careful here.

Nginx Slice is a useful feature.

It exists specifically because caching huge files as fixed byte ranges can be much more efficient than waiting for complete cache fills.

For an immutable file and stable origin:

0–1 MB
1–2 MB
2–3 MB
...

can be an excellent model.

My problem wasn't:

Slice is broken.

My problem was:

My production slice requests encountered ETag inconsistencies across upstream responses.

Now, if I use slicing between my two servers, every slice comes from:

one origin
one Nginx
one filesystem
one file representation

That is a much simpler system to debug.

One URL benchmark is not enough

Another lesson from this migration is how easily origin testing can become unrealistic.

Consider:

curl same-file.avif
curl same-file.avif
curl same-file.avif
curl same-file.avif

After the first request, you're often benchmarking:

cache

not:

origin

Even proxy_cache_lock only helps requests competing for the same cache key.

If a page loads:

image-1.avif
image-2.avif
image-3.avif
...
image-50.avif

and all 50 are cold, those are still 50 different objects.

A realistic media-origin test should therefore include:

different files
cold objects
parallel requests
small and large objects
Range requests
seeking patterns

One cold URL and twenty distinct cold URLs are very different tests.

What I would monitor now

If I were building a similar system again, my Nginx access log would include at least:

$upstream_addr
$upstream_connect_time
$upstream_header_time
$upstream_response_time
$upstream_cache_status
$request_time
$status

Then I would analyze:

HIT latency
MISS latency
MISS p95
MISS p99
upstream connect p95
upstream connect p99

separately.

Do not average HIT and MISS together.

They are different execution paths.

A site can have:

95% extremely fast HITs
+
5% terrible MISSes

and still feel broken whenever a user happens to open the wrong page.

For video, I would test actual seeking behavior

A successful request for:

Range: bytes=0-1048575

does not prove that video delivery is healthy.

I would test at least:

Beginning of the file

Range: bytes=0-1048575

Somewhere in the middle

Range: bytes=50000000-51048575

End of the file

A suffix or final-byte range.

Random seeking

Several non-sequential ranges.

And for each, inspect:

HTTP status
206 Partial Content
Content-Range
Content-Length
Accept-Ranges
ETag

If using Slice, I would explicitly compare validators between multiple slices.

That test would have exposed my MP4 problem much earlier.

Production traffic also showed what a warm cache should look like

One useful sanity check was comparing public traffic from the working server with traffic arriving from the media origin.

In one 60-second production snapshot:

public traffic to users: ~96.84 Mbit/s
traffic from media origin: ~7.07 Mbit/s

During that measurement window there were no new:

502
503
504
upstream timeout

errors.

In another 30-second snapshot:

public TX:      61.36 Mbit/s
origin RX:       1.40 Mbit/s

The byte ratio in that window was approximately:

2.28%

origin traffic relative to public TX.

I would not call the inverse of that number a cache-hit ratio.

That would be incorrect.

Public traffic contains more than media, and a byte ratio is not a request ratio.

But it does demonstrate the architectural behavior I wanted:

users consume a lot of media
↓
working server serves mostly cached bytes
↓
origin only supplies a much smaller cold-fill stream

The media server is acting like an origin, not like a second copy of all public traffic.

Self-hosting did not magically remove infrastructure problems

Moving the media origin to my own server gives me control.

It also gives me responsibility.

Now I have to care about:

disk health
backups
restore procedures
free space
filesystem health
Nginx updates
firewall rules
connection limits
monitoring
redundancy

A single private media origin is also a single point of failure for uncached objects.

If it disappears:

cached media → may continue working
new MISS     → cannot fill

If I need high availability, I need another origin, replication, failover, or another layer entirely.

So this is not:

VPS good, managed storage bad.

It's a trade-off.

For my workload, I preferred operational responsibility over origin unpredictability.

Another team may reasonably make the opposite choice.

When I would still choose Bunny

There are several situations where I would absolutely consider Bunny again.

For example:

globally distributed users
managed edge delivery
managed redundancy
rapidly increasing storage
minimal infrastructure administration
large geographic distance between users and my servers

And in that case, I would evaluate Bunny the way its platform is intended to be used for delivery:

Storage
+
Pull Zone / CDN

rather than assuming my:

Nginx
↓
Storage API

architecture represents Bunny's best delivery model.

It doesn't.

That's why I don't think "Bunny vs VPS" is the right framing.

The more accurate comparison is:

Bunny Storage as my private Nginx origin vs a private server as my Nginx origin.

For that very specific role, my private origin fits my workload better.

The real lesson wasn't about Bunny

Over those two months I tuned:

cache size
cache keys
Range behavior
206 handling
Nginx Slice
1 MB chunks
keepalive
TLS reuse
retry behavior
stale responses
connection timeouts

All of those were legitimate engineering changes.

But the change that improved the system the most was much simpler:

I changed the origin.

That changed the question I now ask whenever I design a cache.

I used to start with:

How do I maximize my cache-hit ratio?

Now I start with:

What happens when the object is not in cache?

If the answer is:

stable origin
predictable TTFB
correct Range behavior
consistent validators
understandable failure modes

then cache is an optimization.

Great.

But if the architecture only feels fast because users usually avoid the cold path, the cache may be hiding the real problem.

A cache should make a good origin cheaper, not make a bad cold path invisible

That is the mental model I kept from this migration.

A good architecture can look like:

HIT
↓
very fast

MISS
↓
still fast enough

Instead of:

HIT
↓
excellent

MISS
↓
please don't happen

Today, I can open old pages containing media that almost certainly wasn't requested recently, and the experience is still fast.

Sometimes the object is cached.

Sometimes it isn't.

From the browser, the difference is often difficult to notice.

That is exactly what I wanted.

The private origin isn't a CDN.

It isn't magic.

It doesn't eliminate operational responsibility.

It's just:

WireGuard
↓
Nginx
↓
SSD

And after two months of tracing connection timeouts, inspecting cold cache misses, experimenting with MP4 byte ranges, and staring at:

etag mismatch in slice response

making the cold path boring turned out to be the biggest performance improvement of all.

I Raised My WebP AVIF SSIMULACRA2 Target to 65. The Encoder Still Passed at 60

Sergei Solod — Thu, 27 Aug 2026 08:49:29 +0000

I thought I was changing one threshold.

Instead, I found two different problems:

I was measuring a second-generation encode against a reference that had already been compressed.
My code could report the stricter threshold correctly while the adaptive encoder still made its decision using the old global one.

The first problem changed how I think about perceptual metrics.

The second changed how I design validation logic.

My original AVIF policy was simple:

target = 60
single allowed worst sample = 58

For small image sets, every representative sample had to reach 60.

For larger sets, I allowed one sample to fall as low as 58 while requiring every other sample to remain at 60 or above.

That worked well enough when I was encoding from the source I actually cared about.

Then the input started looking like this:

higher-quality original: ~2 MB
          ↓
      lossy WebP: ~100 KB
          ↓
          AVIF

The original was gone.

The WebP was all I had.

The obvious question was:

If SSIMULACRA2 60 is acceptable for source → AVIF, why shouldn't the same 60 be acceptable for lossy WebP → AVIF?

The answer depends on what SSIMULACRA2 can actually see.

SSIMULACRA2 measures the reference you give it

SSIMULACRA2 is a full-reference perceptual image metric.

Conceptually, it receives:

reference
candidate

and estimates the perceptual difference between those two images.

Its published quality scale includes approximate anchors around:

50  ≈ medium / fair
70  ≈ high / good
80  ≈ very high
85  ≈ excellent
90  ≈ visually lossless
100 = mathematically lossless

These are useful orientation points, not universal encoding thresholds.

The critical word is reference.

Suppose I still have the real source:

original
   ↓
AVIF

The comparison is:

original ↔ AVIF

If the AVIF scores 60, the metric is describing the perceptual change between the source I care about and the output I am about to ship.

That is exactly the question I want answered.

Now consider this:

original
   ↓ lossy encode
WebP
   ↓ lossy encode
AVIF

If the original no longer exists, the metric sees only:

WebP ↔ AVIF

The first lossy conversion is no longer part of the comparison.

That loss has not disappeared from the pixels.

It has disappeared from the measurement history.

That distinction is the foundation of the whole problem.

Once the derivative becomes the reference, its defects become reference content

Imagine the original contains a perfectly smooth gradient.

The first lossy encoder introduces a little banding.

The WebP still looks acceptable.

Now that WebP becomes the reference for the second conversion.

From SSIMULACRA2's perspective, the existing banding is no longer an error.

It is part of the reference.

If the AVIF introduces more banding, more blur, ringing, edge damage, or other distortion, the metric can react to that additional change.

But it cannot say:

This region already lost information one generation ago.

The earlier image is not available.

So a high score has different meanings depending on the reference.

For a direct encode:

high score
≈
close to the real source

For a second-generation encode:

high score
≈
close to the already-compressed derivative

Those statements are not equivalent.

This does not mean WebP→AVIF transcoding is inherently bad.

It does not mean AVIF automatically amplifies existing artifacts.

It means the second encoder is operating on pixels that may already contain irreversible decisions made by the first encoder.

Source provenance matters more than the extension

This led me away from rules based purely on .webp, .jpg, or .png.

The property I really care about is:

What happened to these pixels before they reached me?

A simplistic implementation would be:

if (extension === ".webp") {
  target = 65;
}

I no longer like that rule.

A better model is closer to:

if (sample.isKnownLossyDerivative) {
  target = 65;
} else {
  target = 60;
}

Why?

Because WebP itself can be lossless.

And there is an important subtlety here:

lossless WebP does not automatically mean clean provenance.

Lossless WebP means that the WebP encoding itself can reproduce its input pixels exactly.

But imagine this chain:

original
   ↓
lossy JPEG
   ↓
lossless WebP

The WebP step did not introduce new loss.

But the pixels inside the WebP already came from a lossy derivative.

So the strongest rule is not:

lossless WebP = clean source

It is:

judge the image by the best provenance information available

For my operational policy, that means roughly:

canonical / trusted source
→ 60 / 58

known already-lossy derivative
→ 65 / 63

A lossless WebP created directly from trusted source pixels can stay on the normal policy.

A lossless WebP wrapping pixels that are already known to be a downstream lossy derivative should not magically erase that history.

The container is not the provenance.

Why I use 65 instead of 60

This part needs a disclaimer.

There is no official SSIMULACRA2 rule saying:

second lossy generation
=
add exactly 5 points

There is no formula where:

60 + previous compression = 65

SSIMULACRA2 scores are not a linear distortion budget that can be added across generations.

So 65 is not a scientific constant.

It is an engineering policy.

My reasoning is simpler.

A target of 60 is already more aggressive than the published high/good anchor around 70.

For a first encode from a trusted source, I am willing to spend that quality budget because reducing bytes is part of the objective.

For a source that I know has already gone through lossy compression, I want the next encoder to have less room to introduce additional distortion.

I could use 70.

That would be more conservative.

But it would also push more outputs toward higher AVIF qualities and larger files.

Without controlled evidence that 70 produces enough additional visual benefit for my workload to justify those bytes, I do not want to force it globally.

So I currently use:

trusted source
target = 60

known lossy derivative
target = 65

I think of 65 as a guardrail.

Not a law.

Why 65/63 instead of 65/62

The original rule was:

target = 60
floor  = 58

The one permitted outlier therefore had a two-point allowance:

60 - 58 = 2

If I raise the normal target to 65 while preserving the same semantics:

65 - 63 = 2

So the corresponding policy becomes:

target = 65
floor  = 63

Using 62 would change the exception to three points:

65 - 62 = 3

That would be odd.

I would be saying:

This source is already lossy, so I want to be stricter.

while also saying:

The worst sample is now allowed to miss its target by more than before.

I could not justify that.

Neither 65 nor 63 is magical.

The useful property is preserving the meaning of the existing policy.

File size cannot tell me how much perceptual damage already exists

A transformation like this looks dramatic:

2 MB → 100 KB

That is roughly a 20× reduction.

It is tempting to turn that number into a quality judgment.

For example:

if (compressionRatio >= 20) {
  target = 70;
}

I do not think that is defensible.

Compression efficiency depends on the content.

A clean illustration with flat regions can sometimes compress extremely well.

A noisy photograph may behave very differently.

Gradients, line art, texture, resolution, chroma, entropy, encoder settings, and source format all matter.

So:

compression ratio
!=
perceptual quality

The question I care about is not:

How impressive was the byte reduction?

It is:

Do I know that this image has already passed through a lossy generation?

Then I found the bug that mattered more than 60 vs. 65

Once I decided on the stricter policy, I expected the implementation change to be trivial.

The code already had the concept of source-specific targets.

Conceptually:

const SOURCE_TARGET = 60;
const LOSSY_DERIVATIVE_TARGET = 65;

There was also logic capable of reporting the correct target for an individual sample.

At first glance, everything looked fine.

But the adaptive search that actually chose the AVIF quality still used a global acceptance condition equivalent to:

const GLOBAL_TARGET = 60;
const GLOBAL_FLOOR = 58;

passed =
  worstScore >= GLOBAL_FLOOR &&
  secondWorstScore >= GLOBAL_TARGET;

The stricter target appeared later in the reporting layer.

So the system could effectively produce this:

sample:
known lossy derivative

required target:
65

actual score:
61.2

log:
BELOW TARGET

while the adaptive search itself still concluded:

61.2 >= 60

PASS

The logs knew about 65.

The encoder was still optimizing against 60.

That was the real bug.

Nothing crashed.

There was no exception.

The build remained green.

The output image looked plausible.

The system could even print the correct stricter threshold.

But the code responsible for selecting the output was solving a different problem.

A threshold that only exists in reporting is not a threshold

That bug gave me a rule I now use beyond image compression:

A configuration value only matters if it reaches the decision that chooses the output.

Defining this:

const LOSSY_TARGET = 65;

does not enforce anything.

Logging this:

required target: 65

does not enforce anything either.

The value has to participate in the actual PASS/FAIL predicate used by the adaptive search.

So instead of keeping the quality policy far away from the measurement, I prefer attaching it directly to each sample.

For example:

function policyForSample(sample) {
  if (sample.isKnownLossyDerivative) {
    return {
      target: 65,
      floor: 63,
    };
  }

  return {
    target: 60,
    floor: 58,
  };
}

Then every measured result can be assessed against its own policy:

function assessSample(result) {
  const policy = policyForSample(result.sample);

  return {
    ...result,

    target: policy.target,
    floor: policy.floor,

    targetMargin:
      result.score - policy.target,

    floorMargin:
      result.score - policy.floor,

    meetsTarget:
      result.score >= policy.target,

    meetsFloor:
      result.score >= policy.floor,
  };
}

Now the measurement carries its own context:

score
target
floor
target margin
floor margin

That makes the next step much safer.

The one-outlier rule should be expressed directly

Suppose the policy is:

For smaller collections:

every sample must reach its own target

For larger collections:

at most one sample may miss its target

but

no sample may fall below its own floor

Then I would implement exactly those semantics instead of reconstructing them indirectly from global score ordering.

function evaluateCandidate(
  results,
  allowSingleOutlier,
) {
  const assessed =
    results.map(assessSample);

  const belowFloor =
    assessed.filter(
      (item) => !item.meetsFloor,
    );

  if (belowFloor.length > 0) {
    return {
      passed: false,
      reason: "below-floor",
      assessed,
    };
  }

  const belowTarget =
    assessed.filter(
      (item) => !item.meetsTarget,
    );

  const allowedMisses =
    allowSingleOutlier ? 1 : 0;

  const passed =
    belowTarget.length <= allowedMisses;

  return {
    passed,
    reason: passed
      ? "passed"
      : "too-many-target-misses",
    assessed,
  };
}

The rule is visible in the code.

There is no hidden assumption that every sample shares one target.

Mixed thresholds break raw "worst score" ordering

This was another important consequence.

Imagine:

Sample A

score  = 63
target = 60
margin = +3

and:

Sample B

score  = 64
target = 65
margin = -1

If I sort by raw SSIMULACRA2 score:

63 < 64

Sample A looks worse.

But relative to the actual requirements:

Sample A
PASS

Sample B
FAIL

The meaningful quantity is no longer just:

score

It is closer to:

score - target

A normalized target margin makes heterogeneous policies comparable:

const targetMargin =
  score - target;

Now:

margin >= 0
→ target passed

and:

margin < 0
→ target missed

The floor can be represented the same way:

const floorMargin =
  score - floor;

The one permitted outlier then has a very clear state:

targetMargin < 0
floorMargin >= 0

This is much safer than sorting raw scores and comparing the two lowest values against global constants.

The adaptive search must use the same predicate

Fixing final validation is not enough.

Suppose the encoder searches for the minimum passing AVIF quality:

q=35
q=43
q=39
q=41
q=40

The definition of passing drives the entire search.

The correct flow is:

encode candidate
      ↓
measure samples
      ↓
apply per-sample policies
      ↓
PASS / FAIL
      ↓
choose next quality

The dangerous version is:

encode candidate
      ↓
compare everything to global 60
      ↓
choose next quality
      ↓
later report that some samples wanted 65

If the search predicate is wrong, correct reporting afterward cannot repair the quality that was already selected.

Historical quality predictions need policy versioning too

There is another subtle issue if the encoder learns from previous runs.

Suppose historical data says:

similar images usually pass around q=38

That prediction only makes sense together with the policy under which those images passed.

If the historical runs used:

60 / 58

and the current source now requires:

65 / 63

the old history is solving an easier problem.

A correct final acceptance predicate still protects correctness.

The search may simply start too low and climb.

But efficiency suffers, and debugging becomes harder.

So I prefer making the policy part of the history version.

For example:

sim-v1-60-58

becomes:

sim-v2-source60-58-lossy65-63

It is not glamorous.

It makes optimization results reproducible.

If the real original exists, I skip the second lossy generation

Whenever I still have the true source, the best solution is simpler.

Suppose I have:

original: 2 MB

and:

WebP derivative: 100 KB

I would rather do:

original
   ↓
AVIF

than:

original
   ↓
WebP
   ↓
AVIF

The original becomes the reference again.

A stricter second-generation threshold cannot recover information that disappeared during the first lossy encode.

This distinction matters:

WebP → AVIF at target 65

means:

preserve this WebP more faithfully

It does not mean:

reconstruct the image that existed
before the WebP was created

Once information is gone from the pixels, SSIMULACRA2 cannot bring it back.

Neither can a higher AVIF quality setting.

Passing the quality gate does not mean transcoding is worth it

There is another decision SSIMULACRA2 cannot make for me.

Suppose:

source WebP = 100 KB
AVIF        = 96 KB

and the AVIF passes 65/63.

The quality requirement is satisfied.

But I saved only 4 KB.

For that saving I added another encoding operation, another lossy generation, processing cost, and another transformation path to maintain.

Maybe the correct optimization is to keep the WebP.

Now consider:

source WebP = 100 KB
AVIF        = 65 KB

with the same perceptual policy still passing.

That is a much more interesting trade-off.

So I separate two questions:

Quality gate: Is the additional distortion acceptable?

Size gate: Is the byte saving large enough to justify another encode?

A candidate can pass the first and still fail the second.

What would actually validate the 65 threshold?

The strongest experiment requires preserved originals.

I would build a representative corpus and compare these chains:

A
original → AVIF
target 60

B
original → lossy WebP → AVIF
target 60

C
original → lossy WebP → AVIF
target 63

D
original → lossy WebP → AVIF
target 65

E
original → lossy WebP → AVIF
target 70

For each final image I would record:

final byte size

selected AVIF quality

SSIMULACRA2:
WebP → final AVIF

SSIMULACRA2:
true original → final AVIF

The last comparison is the important one.

It restores the context that disappears when the WebP derivative becomes the only available reference.

I would also manually inspect difficult content: smooth gradients, fine line art, small text, dense texture, dark gradients, saturated transitions, and sources that already contain visible compression artifacts.

I have not run that controlled experiment across a sufficiently representative corpus of preserved originals.

So I cannot honestly claim:

65 is scientifically optimal

What I can defend is:

For a known already-lossy derivative,
I want a stricter additional-loss budget
than I use for a trusted source.

My current policy is 65/63.

That is an engineering policy.

Not a universal SSIMULACRA2 rule.

The rule I use now

My current mental model is:

Trusted / canonical source: 60 / 58
Known already-lossy derivative: 65 / 63
Lossless encoding does not erase earlier provenance: classify the pixels by their known history
Per-sample policy must participate in the real PASS/FAIL predicate
Mixed thresholds should be evaluated by policy margin, not raw score ordering
Adaptive search and historical prediction must understand the same policy
If the true original exists, encode from it
If AVIF barely saves bytes, consider keeping the current format

The exact thresholds may change as better controlled data becomes available.

The architecture should not.

The metric was not the bug

SSIMULACRA2 was doing exactly what it was supposed to do.

It compared the reference I gave it with the candidate I gave it.

My first mistake was expecting that score to describe quality loss that happened before the reference existed.

My second mistake was adding a stricter threshold without tracing whether that value actually reached the acceptance condition used by the adaptive search.

Both mistakes came from the same habit:

looking at a number without tracing the decision path around it.

A perceptual score has context.

A reference has history.

A threshold has semantics.

And a configuration value only matters if the code that chooses the output actually obeys it.

For me, that lesson ended up being more important than whether the threshold was 60, 63, or 65.

DeepSeek V4 Flash Got Expensive. I Kept the Model and Cut the API Cost Anyway

Sergei Solod — Mon, 17 Aug 2026 13:31:20 +0000

DeepSeek changed its API pricing, and my spending jumped almost overnight. Instead of replacing the model, I tried something simpler: keep the exact same V4 Flash checkpoint and move the inference somewhere else.

On August 17, I checked my API usage and initially assumed something in my application had gone wrong.

The balance was disappearing much faster than usual.

Not a little faster.

Roughly five times faster.

I already knew DeepSeek had announced a pricing change. I had seen the announcement a few days earlier, but I did not expect it to have such a large effect on my actual usage.

A 20% increase would have been annoying.

A 50% increase would have been noticeable.

Even doubling the price would not have surprised me that much.

But this was enough to make me stop and look at the numbers properly.

There was nothing wrong with my billing integration.

The new prices were simply live.

DeepSeek introduced peak and off-peak pricing for V4 Flash and V4 Pro starting at 16:00 UTC on August 16. Reuters had already reported that some DeepSeek prices were increasing anywhere from 50% to 1,100%, depending on the model, token type and time of day.

That was when I remembered an important detail.

DeepSeek V4 Flash is available as an open-weight model.

And that changes the problem completely.

Instead of asking:

Should I replace DeepSeek with another model?

I started asking:

Can I keep exactly the same model and just stop buying the inference from DeepSeek?

That turned out to be the more interesting question.

The old DeepSeek pricing was extremely cheap

Before the change, V4 Flash had pricing that was difficult to complain about.

Token type	Old price per 1M tokens
Input, cache miss	$0.14
Cached input	$0.0028
Output	$0.28

That is the pricing I had become used to.

The current official deepseek-v4-flash, which corresponds to DeepSeek-V4-Flash-0731, now has separate off-peak and peak rates.

Off-peak

Token type	Price per 1M tokens
Input, cache miss	$0.22
Cached input	$0.007
Output	$0.66

Peak

Token type	Price per 1M tokens
Input, cache miss	$0.44
Cached input	$0.014
Output	$1.32

DeepSeek currently lists the peak windows as:

01:00 to 04:00 UTC
06:00 to 10:00 UTC

My own spending being close to five times higher does not mean every possible DeepSeek request is exactly five times more expensive.

The actual increases depend on what kind of tokens you are paying for.

For example:

cache-miss input went from $0.14 to $0.44 at peak, about 3.14x
output went from $0.28 to $1.32 at peak, about 4.71x
cached input went from $0.0028 to $0.014 at peak, exactly 5x

If your application generates a lot of output, a bill that feels close to five times larger is not difficult to explain.

I did not want to keep paying those rates while spending several days slowly evaluating alternatives.

So I started searching immediately.

Changing providers is much easier than changing models

There are plenty of models I could have tested instead.

Qwen.

GLM.

Kimi.

MiniMax.

Mistral.

And many more.

But changing an LLM in a real application is not always a one-line configuration change.

Even when the API format is similar, behavior can move in ways that matter.

Prompts may need adjustment.

Answers may become longer or shorter.

The tone can change.

Sampling settings that worked well before may no longer be ideal.

Long-context behavior can differ.

Edge cases appear.

If the current model already works well, replacing it creates a new testing problem.

I wanted to avoid that problem.

My goal became very specific:

Keep DeepSeek V4 Flash 0731. Change only the infrastructure serving it.

Open weights create a separate inference market

This is the part I think developers sometimes overlook.

DeepSeek published the deepseek-ai/DeepSeek-V4-Flash-0731 checkpoint publicly on Hugging Face under the MIT License.

The weights are available.

Deployment information is available.

DeepSeek even documents a deployment example using vLLM on a single node with four GB300 GPUs.

So an inference company does not necessarily need to purchase API tokens from DeepSeek and resell those tokens to you.

It can operate the model itself.

Conceptually, I used to think about DeepSeek like this:

Application
    |
    v
DeepSeek API
    |
    v
DeepSeek V4 Flash

But with public weights, the picture is closer to this:

                  DeepSeek V4 Flash weights
                           |
          +----------------+----------------+
          |                |                |
          v                v                v
    DeepSeek API        Runware       Other providers
                                            |
                                            v
                                      Self-hosting too

DeepSeek created the model.

That does not mean DeepSeek has to be the only company selling inference for it.

Those are now two separate things.

And once I started looking at the market that way, the pricing became much more interesting.

How I searched for providers

I did not start with a list of famous inference companies.

I wanted to search broadly because smaller providers are often where the interesting prices are.

My process was basically this:

Ask an AI to help me create a very detailed research prompt.
Run that research repeatedly, usually around 15 to 20 separate searches.
Combine the results into one conversation.
Compare the providers.
Remove obviously unsuitable options.
Build a shortlist.
Verify the finalists manually.

I do not treat the AI's final ranking as truth.

That would be a mistake.

The useful part is breadth.

It can surface providers I would probably never discover by manually searching through the same five well-known companies.

Once I get to the shortlist, I check everything myself.

I open the provider's website.

I read the documentation.

I verify the model identifier.

I check the actual pricing.

And if it looks promising, I send real API requests.

That process eventually led me to Runware.

Runware was serving the exact checkpoint

The important part was not merely that Runware supported "DeepSeek."

It offered:

DeepSeek-V4-Flash-0731

That is what I wanted.

I was specifically trying to avoid introducing another model variable into the test.

At the time I checked, Runware's pricing for the checkpoint was:

Token type	Runware per 1M tokens
Input	$0.076
Cached input	$0.014
Output	$0.153

The first time I saw those numbers, I checked them again.

Not because Runware was cheaper than the new DeepSeek pricing.

I expected that.

What surprised me was that it was also substantially cheaper than the old DeepSeek pricing.

It was cheaper than DeepSeek before the increase

Take input first.

Old DeepSeek:

$0.14 / 1M

Runware:

$0.076 / 1M

That makes Runware roughly 45.7% cheaper.

Or viewed from the other direction, the old DeepSeek price was around 1.84x higher.

Now output.

Old DeepSeek:

$0.28 / 1M

Runware:

$0.153 / 1M

That is approximately 45.4% cheaper.

The old DeepSeek rate was about 1.83x higher.

This was the part I did not expect.

Finding a provider cheaper than DeepSeek after a major price increase is not surprising.

Finding the exact same public checkpoint for around 45% less than DeepSeek charged before the increase is much more interesting.

Against the new DeepSeek prices, the gap gets huge

For normal cache-miss input and output, the difference is now much larger.

DeepSeek off-peak vs Runware

Input:

$0.22 / $0.076 = ~2.9x

Output:

$0.66 / $0.153 = ~4.3x

DeepSeek peak vs Runware

Input:

$0.44 / $0.076 = ~5.8x

Output:

$1.32 / $0.153 = ~8.6x

There is one important exception.

DeepSeek's off-peak cached input currently costs:

$0.007 / 1M

Runware's cached input costs:

$0.014 / 1M

So DeepSeek is cheaper for that particular category during off-peak hours.

This is why comparing only one headline number can be misleading.

Your real cost depends on your own traffic.

An application with very high cache-hit rates may reach a different conclusion from an application generating large amounts of output.

Cheap pricing means nothing if the API is unreliable

At this point I still had no reason to trust Runware.

A pricing page is not a benchmark.

And cheap tokens are worthless if requests fail constantly.

So I funded the account, connected the API and started sending actual traffic.

One early dashboard snapshot looked like this:

790 requests
56 success
734 errors

Which looks awful.

Later I checked again:

1,570 requests
836 success
734 errors

The difference between those snapshots was:

+780 requests
+780 successful
+0 new errors

I want to be precise about what I am claiming here.

This does not prove some ridiculous five-nines reliability number.

It also does not tell us why the original 734 requests failed.

What it does tell me is very simple:

During the next batch of 780 requests, the success counter increased by 780 and the error counter did not increase at all.

I continued testing after that.

At the time I am writing this, I have already passed 1,000 successful AI requests through the Runware endpoint.

So far, the experience has been good.

The latency surprised me too

I was mostly looking for price differences.

Latency was secondary.

But the successful requests I checked were generally fast.

Most completed in somewhere between a fraction of a second and roughly 1.5 seconds.

Some of the smaller requests were costing around:

$0.000005

to:

$0.000018

per request.

After hundreds of successful calls, the total displayed spending was still around one cent.

That is when the comparison stopped feeling theoretical.

This was no longer:

Provider A says it costs X and Provider B says it costs Y.

The endpoint was connected to my application.

Requests were completing.

Responses were coming back quickly.

And the cost was tiny.

A necessary disclaimer about Runware

I want to be explicit about this because I am naming one company repeatedly.

This article is not sponsored.

Runware did not contact me.

I did not contact them before writing this.

Nobody asked me to publish anything.

I have no affiliate agreement.

No referral deal.

No discount code.

No free credits.

I found Runware while researching inference providers, created an account, deposited my own money and tested the API.

That is the entire relationship.

There is another important disclaimer.

I have been testing it for one day.

That is nowhere near enough time to declare a provider the best option on the market.

Maybe I discover reliability issues later.

Maybe its pricing changes.

Maybe performance gets worse.

Maybe another provider appears next week with better infrastructure and an even lower price.

If that happens, I will switch again.

I am not loyal to an inference endpoint.

I moved because DeepSeek's new pricing made me reconsider where I was buying compute.

Runware happened to be the provider that looked good enough to test immediately.

So far:

more than 1,000 requests have completed successfully
latency has been good in my testing
pricing is extremely low
the first day has gone well

That is the extent of my claim.

DeepSeek is now competing with companies that run DeepSeek

This is the most interesting part of the whole situation to me.

DeepSeek built the model.

Then it published the weights under a permissive license.

That means infrastructure companies can take the same model and compete on:

GPU utilization
batching
serving software
capacity planning
margins
geographic infrastructure
latency
reliability
pricing

In other words, DeepSeek is not only competing with Qwen, OpenAI, Anthropic, Mistral or other model developers.

For inference revenue, it can also end up competing with companies serving DeepSeek's own model.

When official V4 Flash inference cost $0.14 for input and $0.28 for output, that competition was easy to ignore.

The official API was already extremely cheap.

But when peak pricing becomes $0.44 input and $1.32 output while another provider offers the same checkpoint at $0.076 and $0.153, the infrastructure market starts to matter a lot more.

This is also why I do not think "Runware is reselling DeepSeek" is necessarily the right way to think about it.

If a provider is running public weights on its own hardware, then what you are purchasing is its inference infrastructure.

The model came from DeepSeek.

The compute came from someone else.

Did DeepSeek make a mistake by releasing the weights?

I do not think the answer is obvious.

It is tempting to look at these price differences and say:

DeepSeek created competitors for its own API business.

That is true in one narrow sense.

But open-weight models also gain advantages that closed models do not.

More developers can experiment with them.

More companies can integrate them.

Cloud providers can support them.

Inference platforms can optimize them.

Researchers can use them.

Businesses can deploy them privately.

The model can spread into places where a single proprietary API never would.

That adoption has value.

So I am not arguing that releasing V4 Flash was a bad business decision.

The claim I am comfortable making is much narrower:

Once a model's weights are publicly available under a permissive license, the company that created the model is no longer the only company capable of selling access to its inference.

When the creator's API is the cheapest and easiest option, nobody cares.

When the creator raises prices significantly, people start looking around.

I certainly did.

Why not just self-host V4 Flash?

I also considered the obvious next step.

If Runware can download the model and run it, why not do the same thing myself?

Because running a model like this is not the same thing as deploying a Node.js service onto a $20 VPS.

The model repository itself is large.

DeepSeek's own deployment example mentions four GB300 GPUs on one node.

And GPUs are only one part of the system.

You also need to think about:

enough VRAM
inference engines
model loading
batching
KV cache management
concurrency
networking
monitoring
capacity planning
failover
power
cooling
maintenance
keeping expensive GPUs utilized

Self-hosting can absolutely make sense at sufficient scale.

But there is a huge difference between:

I can download the weights.

and:

I can serve this model economically in production.

An inference provider can spread the cost of its hardware across many customers.

For my current usage, I cannot.

If somebody is willing to serve the model to me for $0.076 per million input tokens, buying the API can be much more rational than building the infrastructure myself.

If I had enough GPUs and capital, though, I would absolutely be interested in this market.

Running open models efficiently and selling inference is an interesting infrastructure business.

I just do not need to own that infrastructure today.

What I am changing after this

The main lesson for me is not specifically "use Runware."

That could change next week.

The bigger change is how I evaluate open-weight APIs.

Before this, my mental model was basically:

DeepSeek built the model
        ↓
DeepSeek sells the API
        ↓
That is the price of DeepSeek

Now I think about it more like:

Model creator
     ↓
Public weights
     ↓
Many companies compete to serve them
     ↓
Different prices, latency and reliability

And the numbers make the distinction hard to ignore.

Old DeepSeek V4 Flash:

Input:  $0.14 / 1M
Output: $0.28 / 1M

New DeepSeek peak pricing:

Input:  $0.44 / 1M
Output: $1.32 / 1M

Runware when I tested it:

Input:  $0.076 / 1M
Output: $0.153 / 1M

And I have already sent more than 1,000 successful AI requests through that endpoint.

Will I still use it a month from now?

Maybe.

Maybe not.

What I will definitely keep doing is this:

When a model has public weights, I will no longer assume that the model creator automatically has the best inference API.

I will identify the exact checkpoint.

I will find out who else serves it.

I will compare the real token pricing.

And then I will send actual requests before making a decision.

That is how I found a cheaper way to keep using DeepSeek V4 Flash without changing the model at all.

deepseek #ai #llm #api

My Next.js Blog: Global in a Week (21 Languages)

Sergei Solod — Tue, 17 Jun 2025 13:04:35 +0000

A little while ago, I decided to try a simple experiment: build a Next.js blog in 21 languages and see how search engines would handle it.

There was no big business plan behind it. I mostly wanted to test multilingual routing, localization, indexing, and SEO on a real project instead of another demo app.

After the first week, Google Search Console showed 439 impressions and 5 clicks.

Yandex had also started picking up some of the pages.

The numbers are obviously small, but for a brand-new personal blog, I was happy to see that Google was already discovering pages and showing them in search.

Why I used Next.js

The blog is built with Next.js, and every article has a separate version for each of the 21 supported languages.

I chose Next.js because it gave me a convenient setup for:

internationalized routing
server-side rendering
static generation
reusable layouts and metadata
generating a large number of localized pages

For this kind of project, that made the implementation much easier.

Of course, using Next.js does not automatically mean better rankings or faster indexing. It just gives you the tools to build pages that are easy for search engines to crawl and understand.

Google still decides what gets indexed and what gets shown in search.

The first search results

After roughly one week, I had:

439 Google impressions
5 clicks
about 1.1% CTR

Five clicks is not much traffic, but traffic was not really the interesting part yet.

What interested me was that the site had already started getting impressions across a large multilingual structure.

One article on my blog can exist as 21 separate URLs.

That creates a lot more possible search entry points than publishing only in English.

It does not mean 21 languages will give you 21 times more traffic. Each page still has to earn its own visibility.

But it does make the site much more interesting to monitor.

Indexing took longer

The next thing I started watching was indexing.

My sitemap.xml is generated automatically, and I submit it through Google Search Console.

A few weeks later, I had 471 pages in the group I was tracking.

Out of those:

436 pages were indexed
35 pages were still not indexed

So around 93% of those pages had made it into Google's index.

That was a useful reminder that discovery, indexing, impressions, and clicks are all different things.

Submitting a sitemap does not mean Google will immediately index every page.

An indexed page also does not mean it will rank or get traffic.

And if a new page has not been indexed yet, that does not automatically mean there is a serious SEO problem.

Multilingual sites scale very quickly

One thing that became obvious pretty fast is how quickly the number of pages grows.

If I publish one article, I am not really publishing one page.

I am publishing 21 localized pages.

Ten articles can become 210 URLs.

Twenty articles can become 420 URLs.

That means small technical mistakes can also get duplicated very quickly.

A problem with metadata, internal links, canonical tags, hreflang, translations, or URL structure can affect dozens or hundreds of pages instead of just one.

So multilingual publishing gives you more opportunities, but it also gives you more things to check.

What I learned so far

The biggest lesson for me is that multilingual SEO is not simply about creating as many translated pages as possible.

The technical side matters, but there are several separate questions:

Can Google discover the URLs?
Can Google crawl them correctly?
Which pages actually get indexed?
Which languages receive impressions?
Which pages receive clicks?
Which localized versions eventually start getting consistent search traffic?

At first, I mostly looked at the total number of impressions.

Now I think it is much more useful to look at each part separately.

Current result

So far, the experiment looks like this:

First week:

439 Google impressions
5 clicks
Yandex started showing some pages

A few weeks later:

471 pages tracked
436 indexed
35 still not indexed

I would not call that proof that multilingual SEO automatically works, or that Next.js gives some special SEO advantage.

But it does show that a small multilingual project can get discovered across a surprisingly large number of pages fairly quickly.

For me, the more interesting question now is not whether Google can find the site.

It is which languages and articles will eventually turn those impressions into consistent organic traffic.

Blog: https://jsvar.com/en/blog

DEV Community: Sergei Solod

AVA Hosting Said “No Sharing.” Linux Reported 32.73% CPU Steal

The VPS

The 60-second CPU profile

What %steal means

It wasn't one bad sample

Linux PSI showed the CPU was under constant pressure

The application queue confirmed that this wasn't just an ugly metric

I checked memory

I checked the disk

Then I looked at AVA Hosting's CPU claims

What this does and does not prove

Why I didn't upgrade to more vCPUs

AVA refunded me in full

The VPS check I use now

High CPU, almost no steal

High iowait

Memory pressure and swap activity

High steal + zero idle + high CPU PSI + growing queues

A running service is not a healthy service

The three numbers I remember from this incident

My REGXA VPS Had 94% CPU Steal With Zero Traffic

CPU usage and CPU steal are very different things

I removed all production traffic

localhost was taking seconds

The rest of the stack started backing up

RAM and disk were not the bottleneck

I compared it with another KVM VPS

Busy because my application is running

Busy because the guest is not getting scheduled

REGXA later confirmed resource contention

The CPU wording was difficult to reconcile

The refund became another part of the incident

The debugging lesson was more useful than the hosting story

My VPS smoke test now includes %steal

I Used Bunny Storage Behind Nginx for Two Months. The Cache Was Fast, the Cold Path Wasn't

First, an important distinction: this was not Bunny CDN

Why I built it this way in the first place

A cache HIT tells you almost nothing about your origin

The production logs showed that some requests were stalling before the file even started downloading

This was not a one-request anomaly

It also wasn't one permanently bad Bunny Storage IP

One measurement showed exactly why averages were misleading

For a gallery, p99 matters more than the average image

Why older content exposed the problem more often

Then video made the architecture much more complicated

My first approach: include the browser Range in the cache key

Nginx Slice looked like the right solution

The video problem was ETag consistency, not "different signatures"

And this wasn't theoretical — I had the exact error in production

This does NOT mean Bunny Storage cannot serve Range requests

I eventually stopped using Slice for MP4

I realized I was building part of a CDN in front of a storage service

The replacement: a boring private media origin

Why a tiny server is enough for this kind of job

The new cold path has far fewer moving parts

The difference was immediately visible in the measurements

Important: this does not mean a full video downloads in 20 ms

Comparing one observed old outlier with the new path

Something surprising happened: I no longer needed a huge cache to make old pages feel fast

MP4 became simpler after the origin moved too

But full-object caching is not free either

Nginx Slice is not the villain either

One URL benchmark is not enough

What I would monitor now

For video, I would test actual seeking behavior

Beginning of the file

Somewhere in the middle

End of the file

Random seeking

Production traffic also showed what a warm cache should look like

Self-hosting did not magically remove infrastructure problems

When I would still choose Bunny

The real lesson wasn't about Bunny

A cache should make a good origin cheaper, not make a bad cold path invisible

I Raised My WebP AVIF SSIMULACRA2 Target to 65. The Encoder Still Passed at 60

SSIMULACRA2 measures the reference you give it

Once the derivative becomes the reference, its defects become reference content

Source provenance matters more than the extension

Why I use 65 instead of 60

What `%steal` means

My VPS smoke test now includes `%steal`