DEV Community: Jonathan Duberville

3 Days to Save the Release: From 3.15s to 233ms

Jonathan Duberville — Thu, 11 Dec 2025 10:48:16 +0000

Lessons from a successful optimization mission — by a non-expert

Some Context

The API is central to a migration program. Problem: critical latencies are blocking its release to production.

The symptoms: MongoDB CPU at 150%, connections jumping from 400 to 1500, high error rate, requests exceeding 30 seconds.

Here's the approach I followed and what I learned from it.

How to Tackle This Kind of Problem?

Before diving in, I gathered as much information as possible: existing audits, interviews, monitoring dashboards, bug history. I complemented this with a code review to assess complexity, spot anti-patterns and identify quick wins.

🤖 AI Accelerator: The agent scanned the codebase, identified anti-patterns and documented the structure. It helped me build a macro view of the system.

Using the Cynefin framework, I identified that we were in the Complex domain: multiple interconnected factors, impossible to predict the impact of an optimization without trying it.

Hence the approach: Probe → Sense → Respond — experiment, observe, adjust.

An Iterative Strategy: Probe → Sense → Respond

No tooling, no data. No data, no strategy. I used a load testing tool and several monitoring solutions to collect as much information as possible.

Smoke Test

Probe: Each test uses a simple and identical profile: gradual ramp-up to 500 virtual users, 15-minute plateau, then ramp-down.

Sense: Too many 504 errors, unstable MongoDB — unusable results. Root causes: the scenario reused the same identifiers (write conflicts) and the code contained queries without indexes.

Result: Unusable (too many errors to measure)

Respond:

Created indexes on critical fields
Improved test scenario (randomization, realistic distribution)
Created a dedicated test environment

🤖 AI Accelerator: The agent identified the fields to index and generated the test scripts.

Establishing a Baseline

Probe: Load test with the corrected scenario on the dedicated environment.

Sense: First usable results. High latency, but reliable measurements.

Result (baseline): 101 req/s, 2.56% errors, P99 9.9s, average 3.15s

Respond:

Adjusted Kubernetes autoscaling (HPA)
Increased replica count

Testing Horizontal Scaling ⚠️

Probe: New load test.

Sense: Pods saturate before autoscaling kicks in.

Result: 82 req/s, 4.17% errors, P99 12.3s, average 4.09s ⚠️

⚠️ Regression! More replicas = more concurrent MongoDB connections = more contention. We're just moving the problem around.

Respond:

Increased CPU and RAM resources per pod

Testing Vertical Scaling

Probe: New load test.

Sense: Observability reveals Out Of Memory errors and frequent restarts.

Result: 162 req/s, 0.68% errors, P99 5.86s, average 1.58s

✅ Throughput +60%, errors -73%. But latency remains high — the problem is now in the code.

Respond:

Optimized MongoDB queries (removed expensive aggregations)
Refactored critical algorithms
Optimized write parameters

🤖 AI Accelerator: The agent generated regression tests and assisted with code refactoring.

Testing Application Optimizations

Probe: New load test.

Sense: The optimizations are paying off.

Final result ✅: 200 req/s, ~0% errors, P99 0.67s, average 233ms

✅ Throughput doubled compared to baseline, P99 dropped from 9.9s to 0.67s.

Exit — Knowing When to Stop

200 req/s, P99 under one second, near-zero errors: release constraints are met.

In Cynefin terms, this is the transition from the Complex domain to the Complicated domain: we've learned enough, future optimizations become predictable. Without production data, going further would be premature optimization.

Conclusion

This mission shows that a Probe → Sense → Respond approach delivers fast gains on a complex system. AI agents didn't replace expertise — it's still humans who observe and decide — but they accelerated each cycle. The faster you iterate, the faster you learn.

Key Takeaways

Measure before and after each change. Intuition isn't enough, and an optimization can make things worse.
Get your test scenario right. An unrealistic scenario produces misleading results.
Navigate across layers. Infra, code, and database form a system. Being able to read Kubernetes metrics, profile MongoDB, and refactor code in the same day is a decisive advantage.
Get the right tools. Without load testing, observability, and profiling tools, optimization is blind.
Use AI agents to accelerate. They don't replace expertise, but they amplify execution velocity.
Define an exit criterion. SLOs define when it's "good enough". Without them, you risk over-optimizing.

Bonus: a mature Platform Engineering setup remains a prerequisite for these gains to materialize.

On a 3 jours pour sauver la MEP: de 3.15s à 233ms

Jonathan Duberville — Thu, 11 Dec 2025 09:51:44 +0000

Mes conseils de non-expert issus d'une mission d'optimisation réussie

Un peu de contexte

L'API est centrale pour un programme de migration. Problème : des latences critiques bloquent sa mise en production.

Les symptômes : CPU MongoDB à 150%, connexions qui passent de 400 à 1500, taux d'erreurs élevé, requêtes dépassant 30 secondes.

Voici la démarche que j'ai suivie et ce que j'en retiens.

Comment attaquer ce genre de sujet ?

Avant de foncer, j'ai rassemblé un maximum d'informations : audits existants, interviews, dashboards de monitoring, historique de bugs. J'ai complété par une revue de code pour évaluer la complexité, repérer les anti-patterns et identifier des quick wins.

🤖 Accélérateur IA : L'agent a scanné le codebase, identifié les anti-patterns et documenté la structure. Il m'a aidé à construire une vision macro du système.

En m'appuyant sur le framework Cynefin, j'ai identifié qu'on était dans le cadrant Complexe : plusieurs facteurs interconnectés, impossible de prédire l'impact d'une optimisation sans l'essayer.

D'où l'approche : Probe → Sense → Respond — expérimenter, observer, ajuster.

Une stratégie itérative : Probe → Sense → Respond

Sans outillage, pas de données. Sans données, pas de stratégie. J'ai utilisé un outil de test de charge et plusieurs solutions de monitoring pour collecter un maximum d'informations.

Smoke Test

Probe : Chaque tir utilise un profil simple et identique : montée progressive jusqu'à 500 utilisateurs virtuels, plateau de 15 minutes, puis descente.

Sense : Trop d'erreurs 504, MongoDB instable — résultats inexploitables. En cause : le scénario réutilisait les mêmes identifiants (write conflicts) et le code contenait des requêtes sans index.

Résultat : Non exploitable (trop d'erreurs pour mesurer)

Respond :

Création d'index sur les champs critiques
Amélioration du scénario de test (randomisation, distribution réaliste)
Création d'un environnement dédié aux tests

🤖 Accélérateur IA : L'agent a identifié les champs à indexer et généré les scripts de test.

Définir une référence

Probe : Tir de charge avec le scénario corrigé sur l'environnement dédié.

Sense : Premiers résultats exploitables. Latence élevée, mais mesures fiables.

Résultat (baseline) : 101 req/s, 2.56% erreurs, P99 9.9s, moyenne 3.15s

Respond :

Ajustement de l'autoscaling Kubernetes (HPA)
Augmentation du nombre de replicas

Tester le scaling horizontal ⚠️

Probe : Nouveau tir de charge.

Sense : Les pods saturent avant que l'autoscaling réagisse.

Résultat : 82 req/s, 4.17% erreurs, P99 12.3s, moyenne 4.09s ⚠️

⚠️ Régression ! Plus de replicas = plus de connexions MongoDB concurrentes = plus de contentions. On déplace juste le problème.

Respond :

Augmentation des ressources CPU et RAM par pod

Tester le scaling vertical

Probe : Nouveau tir de charge.

Sense : L'observabilité révèle des erreurs Out Of Memory et des restarts fréquents.

Résultat : 162 req/s, 0.68% erreurs, P99 5.86s, moyenne 1.58s

✅ Débit +60%, erreurs -73%. Mais la latence reste élevée — le problème est maintenant côté code.

Respond :

Optimisation des requêtes MongoDB (suppression des agrégations coûteuses)
Refactoring des algorithmes critiques
Optimisation des paramètres d'écriture

🤖 Accélérateur IA : L'agent a généré des tests de non-régression et assisté le refactoring du code.

Tester les optimisations applicatives

Probe : Nouveau tir de charge.

Sense : Les optimisations portent leurs fruits.

Résultat final ✅ : 200 req/s, ~0% erreurs, P99 0.67s, moyenne 233ms

✅ Débit doublé par rapport à la baseline, P99 passé de 9.9s à 0.67s.

Exit — Savoir quand s'arrêter

200 req/s, P99 sous la seconde, erreurs quasi-nulles : les contraintes de la MEP sont respectées.

Dans Cynefin, c'est le passage du cadrant Complexe au cadrant Compliqué : on a suffisamment appris, les prochaines optimisations deviennent prévisibles. Sans données de production, aller plus loin serait de l'optimisation prématurée.

Conclusion

Cette mission montre qu'une approche Probe → Sense → Respond permet des gains rapides sur un système complexe. Les agents IA n'ont pas remplacé l'expertise — c'est l'humain qui observe et décide — mais ils ont accéléré chaque cycle. Plus on itère vite, plus on apprend vite.

Ce que je retiens

Mesurer avant et après chaque changement. L'intuition ne suffit pas, et une optimisation peut faire pire.
Soigner le scénario de test. Un scénario non représentatif donne des résultats trompeurs.
Naviguer entre les couches. Infra, code, base de données forment un système. Savoir lire des métriques Kubernetes, profiler MongoDB et refactorer du code dans la même journée est un atout décisif.
S'outiller correctement. Sans outils de test de charge, d'observabilité et de profiling, l'optimisation est aveugle.
Utiliser des agents IA pour accélérer. Ils ne remplacent pas l'expertise, mais ils amplifient la vélocité d'exécution.
Définir un critère d'arrêt. Les SLOs définissent quand c'est "assez bien". Sans eux, on risque de sur-optimiser.

Bonus : une Platform Engineering mature reste un prérequis pour que ces gains se concrétisent.

Mutation Testing in NodeJS

Jonathan Duberville — Sat, 01 Jan 2022 12:05:02 +0000

What is mutation testing?

If you are reading this, we assume you are using TDD or that your coverage is nearly of 100%. If you are not complying to this requirement, start by building a strong Unit/Integration Test harness. Without a good coverage you won't get a lot of value out of this practice.

Mutation testing is a way to check if your current tests (unit, integration, etc...) are precise enougth to catch random changes in your code base. The tool navigates through the code and creates mutants by modifying mostly conditions and values (such as constants or conditionals).

For instance:

return {code: this.value};

will generate several mutants:

return null;

return {};

return undefined;

For each mutated version of your code, the tests base will be run.

If the test is still green the mutant will tagged this mutant state as Survived, otherwise it will be tagged as Killed.

The objective is to have as much Killed mutants as possible, meaning the tests is covering most cases and that a change in the code will be catched by a unit test.

We will be using Stryker as an automation tool:

Website: https://stryker-mutator.io/

Now! Let's go kill some mutants!

Install Stryker dependencies

npm i -g stryker-cli
npm i -D stryker-html-reporter stryker-jest-runner stryker-typescript @stryker-mutator/core

Configure

stryker init

Change the stryker.conf.js file to avoid analysing .spec.ts files and add the plugins manually to avoid dependencies errors:

module.exports = function (config) {
  config.set({
    mutator: "typescript",
    packageManager: "npm",
    reporters: ['progress','html'],
    testRunner: "jest",
    transpilers: [],
    coverageAnalysis: "off",
    tsconfigFile: "tsconfig.json",
    mutate: ["src/**/*.ts", '!src/**/*.spec.ts'],
    htmlReporter: {
      baseDir: 'mutation'
    },
    plugins: ['stryker-html-reporter', 'stryker-jest-runner', 'stryker-typescript']
  });
};

Start the test (put your computer in a freezer!)

stryker run

As always if you need help ask a friend 😊