DEV Community: Hermógenes Ferreira

When Benchmarks Lie: Saturation, Queues, and the Cost of Assuming Linearity

Hermógenes Ferreira — Mon, 05 Jan 2026 10:31:14 +0000

If you didn't run your system at 1M requests per second, it doesn't support 1M requests per second.

Running it at 100k and extrapolating the rest assumes linearity, and linearity is the most dangerous assumption in performance engineering.

Most performance benchmarks don't fail because the numbers are wrong.
They fail because we ask them the wrong question.

Low latency at low load doesn't predict high throughput at high load.
It predicts only one thing: the system wasn't busy yet.

This post explains why that assumption breaks, why queues quietly dominate system behavior, and why throughput and latency are inseparable once you leave the comfort of idle benchmarks.

The intuition trap: "fast = scalable"

You run a benchmark and see:

p99 latency: 1 microsecond
test duration: a few minutes
CPU looks idle
no errors

The natural conclusion: "At 1 microsecond per request, this system can do ~1M requests per second."

This assumes linearity: double the load, double the work, latency stays flat, resources scale smoothly.

Real systems don't work like that.

A real-life analogy: the coffee shop

A coffee machine makes a coffee in 1 second. Does that mean the shop can serve 60 people per minute?

Only if customers arrive one at a time, nobody queues, and nobody orders at the same moment.

The moment two people arrive together, one waits. The coffee machine is still "fast", but latency increases because of waiting.

Your server works the same way.

The one rule you actually need

There's a fundamental relationship that applies to coffee shops, highways, and servers:

Average concurrency = throughput × latency

This is Little's Law.
The implication: if you want more throughput, either latency must increase or concurrency must increase.

You don't get infinite throughput just because one request is fast.

Applying this to the "1M RPS" claim

Simple math:

Average latency: 1 microsecond
Target throughput: 1,000,000 requests/second

Little's Law says: on average, the system has exactly 1 request in flight.

One. No overlap. No waiting. No queue.

That's physically impossible for a real server.
Requests arrive simultaneously, the OS schedules work, network packets queue, memory is shared.

So what really happens?
Requests wait. Queues form. Latency grows.

Why linear extrapolation fails

The core mistake: "It works at 100k RPS, so it should work at 1M RPS."

This ignores:

Queue growth
Contention
OS limits
Network saturation
Scheduling delays

These effects are non-linear. They appear near the limit, not at half load. Systems often look fine right up until they collapse.

What short benchmarks actually measure

Short benchmarks typically run for a few minutes with light traffic, no queues, and warm caches.

What they really measure: "How fast is my code when nothing is waiting?"

That's useful, but it's not capacity. It's like timing how fast a cashier scans one item and assuming the store can handle Black Friday.

The invisible enemy: queues

As load increases, requests start waiting, queues grow, latency increases, and throughput stops scaling.

Nothing crashes. No error appears. No bug is introduced. The system just gets slower.

Another analogy: highways

A highway at night is empty, fast, and smooth. The same highway at rush hour (same road, same speed limit) develops traffic jams.

Why? Once the road is almost full, small increases in traffic cause huge delays. Servers behave exactly like this.

Network limits show up before your code

At high request rates with realistic payloads (roughly 1 KB per request):

Network cards queue packets
Kernel buffers fill
Interrupts pile up

Latency increases before your application code even runs. A microbenchmark won't show this. A real load test will.

Ports and connections also saturate

High request rates hit limits:

TCP port exhaustion
Accept queue overflows
File descriptor limits
Sockets stuck in TIME_WAIT

These are operating system constraints, not application bugs. Short tests rarely reach them. Production traffic does.

Why nanosecond benchmarks are misleading

Nanosecond benchmarks usually prove one thing: the data was already in cache.

They measure best-case conditions: hot CPU caches, no contention, no waiting. They don't measure queue buildup, cache eviction, real concurrency, or sustained pressure.

They're useful for understanding code-level performance, but dangerous if treated as capacity numbers.

How to test honestly

If you want to know whether your system handles 1M requests per second:

Run it at 1M RPS
Run it long enough for queues to form (minutes, not seconds)
Watch latency as load increases
Expect non-linear behavior
Stop assuming linearity

Anything less is guessing.

The takeaway

Latency isn't a property of a request. It's a property of a system under load.

If you push more traffic, latency must increase, or concurrency must increase, or the system saturates. There is no fourth option.

Once you internalize this, benchmarks stop lying — because you stop asking them the wrong questions.

Como um Regex pode derrubar o seu servidor

Hermógenes Ferreira — Tue, 11 Feb 2025 15:16:02 +0000

Há uns dias eu fiz o seguinte post no X.

// Detect dark theme var iframe = document.getElementById('tweet-1887545470857191474-322'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1887545470857191474&theme=dark" }

Sim, parece exagero, mas é verdade. Um regex mal feito pode derrubar um servidor inteiro.

Além de ser um problema que pode causar grandes prejuízos, é bem complicado de ser identificado.

Esse tipo de problema é conhecido como Catastrophic Backtracking.

Pessoas mal intencionadas podem explorar essa vulnerabilidade para derrubar um servidor no ataque conhecido como ReDoS.

O que é Catastrophic Backtracking?

Catastrophic Backtracking é um problema que ocorre quando um regex é mal feito e tenta encontrar todas as possíveis combinações de uma string.

Por exemplo, considere o regex ^(a+)+$ e a string aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!.

O regex acima tenta encontrar todas as combinações de a na string, o que é um problema, pois o regex não é eficiente.

Você pode estar se perguntando: "Mas como isso pode derrubar um servidor?"

Bem, quando um regex é mal feito, ele pode tentar encontrar todas as combinações possíveis de uma string, o que pode consumir muitos recursos do servidor se a string for grande.

Como algoritmos de regex são CPU-bound, se não houver mecanismos de proteção, um ataque ReDoS pode derrubar um servidor.

Simulação de um ReDoS

Para exemplificar um ReDoS, eu criei uma aplicação em Node.js que valida uma URL slug.

A validação é feita com o regex ^([a-zA-Z-_0-9]+\/?)*$.

Explicando o regex acima:

^: Início da string
([a-zA-Z-_0-9]+\/?)*: Grupo que aceita letras, números, hífens e underscores, seguido de uma barra opcional. Esse grupo pode se repetir zero ou mais vezes.
$: Fim da string

Isso significa que a URL slug pode conter letras, números, hífens e underscores, seguidos de uma barra opcional. Essa sequência pode se repetir zero ou mais vezes.

A aplicação é bem simples. Ela recebe um URL slug via query string e valida se o slug é válido.

O código do app está disponível aqui.

Agora, vamos simular um ReDoS.

Primeiro, vamos testar a aplicação com um URL slug válido:

curl "http://localhost:3000/slugs?url=hello-world"

Esse request deve retornar {"valid":true} sem maiores problemas.

Agora, vamos testar a aplicação com um URL slug inválido:

curl "http://localhost:3000/slugs?url=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa%21"

Bem, o request acima provavelmente não vai terminar.

Se você observar o consumo de CPU do processo do Node.js, você verá que ele estará consumindo 100% da CPU.

Verificando os resultados da simulação

Para simplificar a simulação, eu criei um docker compose que executa duas instâncias do app, uma com o regex seguro e outra com o regex vulnerável.

Além disso, eu criei um script que executa um teste de carga nas duas instâncias.

Para executar a simulação, você precisa ter o Docker e o Docker Compose instalados.

Primeiro, clone o repositório.

Depois, execute o seguinte comando:

docker compose up

O comando acima vai criar as duas instâncias do app e executar o script de teste de carga.

Depois de alguns segundos, você verá que a instância com o regex vulnerável vai consumir 100% da CPU, enquanto a instância com o regex seguro vai continuar funcionando normalmente.

Ao final da execução do script, nenhuma request para a instância com o regex vulnerável vai ter sido completada enquanto a instância com o regex seguro vai ter completado todas as requests.

Como se proteger de ReDoS

Para se proteger de ReDoS, você pode seguir algumas práticas:

Evite regex complexos
Use ferramentas de análise estática que identificam regex que podem causar ReDoS
Verifique se a engine de regex que você está usando tem proteção contra ReDoS e explore alternativas

Conclusão

Regex é uma ferramenta poderosa, mas pode ser perigosa se não for usada corretamente.

O grande problema do ReDoS é que ele é difícil de ser identificado e não necessita de muitas requisições para derrubar um servidor.

Por isso, é importante ter cuidado ao usar regex e sempre verificar se o regex que você está usando é seguro.

You should try .NET + libSQL, and here’s why

Hermógenes Ferreira — Mon, 15 Jul 2024 11:27:34 +0000

TL;DR: libSQL is a SQLite fork that is a game changer for global distributed databases. .NET 8 Native AOT performance is incredible. But together, they're unbelievably fast.

What is libSQL?

First, let me introduce you to libSQL.

libSQL is a fork of SQLite made by Turso. The goal is to optimize SQLite for low latency and replication, making it a perfect fit for global distributed databases.

From now on, when I mention libSQL, I’m referring to Turso's offering.

SQLite? Really?

Yeah, I thought the same when I first heard about it.

SQLite is mostly used for embedded systems and mobile apps, but I never thought it could be used for server-side applications. But libSQL changes everything.

What makes libSQL so Special?

First, it's fast. Really fast. But I’ll delve into that later.

One of the biggest challenges of global systems is latency. It doesn't matter how fast your system is if you have to wait for the data to travel around the world. If you have a microservice that can process a request in 1ms, it still has to travel from your server to the client and back. This is not negligible. In the best case, it takes more than 200ms for a round trip between Sao Paulo and Europe, for example.

We’ve seen a surge in Edge Computing offerings in recent years, but they all suffer from the same problem: the data is still far from the code.

Turso solves this problem by replicating data to multiple read-only servers around the world. This way, the data is always close to the code that needs it.

Another advantage of libSQL is that it offers a simple HTTP API to access the data. This is very useful for serverless applications, as you can access the data without the need for a database driver, completely stateless.

What About .NET?

.NET is a great platform. It's fast, secure, cross-platform, and open-source.

However, it’s not known for its performance, especially in startup time. This is a big problem for serverless applications, as the cold start can take seconds.

But since .NET 6, things are changing. With the new Native AOT and trimming, the startup time is reduced to milliseconds.

And with .NET 8, the performance is even better.

With the official support of AWS Lambda, creating a serverless application with .NET is easier than ever, and the performance is great.

OK! But How Fast is .NET + libSQL?

I’m glad you asked.

And instead of telling you, I’ll show you.

I made a simple benchmark inspired by AWS .NET samples.

You can find the code of this benchmark on GitHub.

It’s a simple function that performs CRUD operations on a table.

The function is configured to 1GB of memory (but it uses way less than that and could be fine-tuned later).

The test is split into two parts: Write and Read-only.

For the write test, I made around 65 requests per second for 3 minutes.

For the read-only test, I made around 100 requests per second for 2 minutes.

The results are impressive, if I may say so.

Phase 1: Write and Read Test

Cold Start	Count	Billed	Min	Avg	P50	P75	P90	P95	P99
0	11622	164773	7.586	13.6814	11.0058	12.1101	17.4715	20.006	29.798
1	10	515	345.349	405.552	385.861	441.672	445.478	477	477

In total, 11,632 requests and a total of 165,288 of billed duration.

What’s interesting is that, even though cold start latency is high, given we are using AWS managed runtime, we don’t pay for it.

If we have a similar request rate in a month, this Lambda function would cost around $72. Not bad at all. 65 requests per second is a lot of requests. Almost 170 million requests per month.

Phase 2: Read-only Test

Cold Start	Count	Billed	Min	Avg	P50	P75	P90	P95	P99
0	11889	147747	7.581	11.9277	10.5759	11.4531	13.1145	15.2582	24.1165

In total, 11,889 requests and a total of 147,747 of billed duration in 2 minutes.

P99 is 24ms. That’s crazy.

Results Combined

Cold Start	Count	Billed	Min	Avg	P50	P75	P90	P95	P99
0	23,511	312,520	7.581	12.7946	10.7458	11.824	14.4304	18.7705	27.9578
1	10	515	345.349	405.552	385.861	441.672	445.478	477	477

Conclusion

.NET + libSQL is a great combination for serverless applications.

The performance is great, the cost is low, and the development experience is awesome if you are already familiar with .NET.

If you are looking for a global distributed database, libSQL is a great option.