.column {
  float: left;
  width: 50%;
}
</style>

# P99, et au-delà

-v-

## Présentation

Julien Lenormand

---

# Le problème : un pipeline lent

![](./pipeline_vue_macro.excalidraw.png)

-v-

![](./pipeline_vue_micro.excalidraw.png)

-v-

![](./latence_moyenne_vs_temps_slow.excalidraw.png)

-v-

![](./duration_vs_time.png)

-v-

![](./nb_reqs_vs_latence_slow.excalidraw.png)

---

# Définir le problème

> On ne peut pas résoudre un problème si on ne le décrit pas correctement.
> - Jean-Marc Jancovici

-v-

Besoin :
> Quand un utilisateur soumet une requête, il a le résultat "rapidement".

Traduction :
> le délai entre l'entrée de la requête dans le système, et la mise à disposition du résultat, ne doit pas être supérieur à X secondes.

Choisir X.

-v-

## Les méchantes mathématiques : Poisson

```python
import numpy as np

rng = np.random.default_rng(42)
t = np.sort(rng.uniform(0, 100, 1000))
```

![](./poisson_1000_100.png)

-v-

## Le méchant monde réel

![](nb_requests_vs_time.png)

avg: 37.4  |  median: 33.0  |  p90: 62  |  p95: 73  |  p99: 109

-v-

![](./percentiles.gif)

-v-

## L'objectif

* p95 latency ≤ 20s
* réaliste ?   
* atteignable ?

---

# C'est parti !

Par quoi on commence ?

-v-

# Mesurer, mesurer, mesurer

*  Mesurer
*  Mesurer
*  Mesurer, encore
*  **ME**
*  **SU**
*  **RER !!!!**
*  MESURER

-v-

## Quoi/comment mesurer ?

![](./pipeline_slice_details.excalidraw.png)

*  framework, monitoring, observability (OTel)
*  timestamps en DB

-v-

![](./pipeline_slice_time.png)

---

# Solutions

*  traiter plusieurs requêtes en même temps :
  *  multithreading
  *  multiprocessing
  *  async
  *  CPU-bound versus IO-bound
  *  scaling horizontal (+ de nodes)
*  traiter une requête plus vite :
  *  scaling vertical (CPU freq, CPU cores, RAM, GPU, ...)
*  traiter plus efficacement une requête :
  *  optimisation locale/globale
  *  cache (LRU, FIFO, TTL, DB index, ...)
  *  trade-off RAM versus CPU
*  ne pas traiter certaines requêtes :
  *  HTTP 429 Too Many Requests / Retry-After
  *  Quality of Service (QoS), priority, ...
  *  backpropagation
*  ...

-v-

# Solutions vaines

*  Loi d'Amdahl : rendre 1000x plus rapide 5% du pipeline ne l'accélère que de 4,9999%
*  queuing theory : plus les queues sont saturées, plus la latence explose
*  low-hanging fruits / quick wins
*  rendements décroissants, coûts exponentiels
*  résoudre un bottleneck ne fait que révéler le prochain

-v-

Mise en contexte : availability
* p50 = ~182 jours de downtime par an
* p90 = ~36 jours
* p99 = 3,6 jours
* p999 = 8,7 heures
* p9999 = 53 minutes

-v-

Mise en contexte : GitHub

![](./github_missing_status_page.png)

---

# Conclusion

---

# Questions ?

* repo : https://github.com/Lenormju/talk-p99
  ![](./qr-code-github.png)  
* slides : https://lenormju.github.io/talk-p99/index.html

</div>
<div class="column">

* n'oubliez pas le ROTI après les talks :
  * est-ce que vous avez appris quelque chose ?
  * est-ce que vous avez été intéressé.e ?

* cadeau 🕺 :

![](./qr-code-rickroll-mobile.png)

</div>
</div>

---

# Extra

* fat tail latency : https://www.linkedin.com/feed/update/urn:li:activity:7511782095661428737/
* SLI / SLO / SLA
* Rust
* Sojourn
* les requêtes arrivent proportionnellement + durant les moments busy
* P99 Conf : 21 et 22 octobre 2026
* Loi de Little pour le lien capacité / throughput
* Test de charge avec k6 : https://www.lenormand-julien.fr/talks.html#k6
* avoir des workloads / benchmarks réalistes
* load balancer

![](./fat_tail_percentage.png)

---

# Abstract

> Cas d'étude : un système complexe, une douzaine de micro-services, plein d'interactions avec des systèmes externes, ... qui n'est pas assez performant.

> Mais c'est quoi "assez performant" ? Et comment ça se mesure ? Et comment on optimise ?

> Plongez avec moi dans un monde de statistiques, de graphiques, d'optimisations et d'optimisme.