Most Developers live in Wonderland, a place where resources are unlimited, failures don't happen and where we take naps inside giant mushrooms. The reality is different. Bottlenecks, failures, latency... take the red pill and come down the rabbit hole with us. What the common bottlenecks are, how to detect them, the usual optimizations, and a full-scale use-case based on Jawg Maps (part 2)

1. Kill the bottleneck
Servir des maps à haute performance
by Loïc Ortola, CTO
jawgmaps

2. Les incontournables
1. C’est quoi une carte?
2. Nos choix TKs
3. Rétrospective Load-testing
4. è Continuous improvement

3. 1. Qu’entend-on par Carte?
4 métiers principaux dans les maps digitales
Geocoding
Routing (Itinéraire)
Cartes (Fonds de carte) ex : WMTS, WMS, Slippy Map Tiles
Données supplémentaires (Vos POIs) ex : WFS

4. 1. Qu’entend-on par Carte?
Carte de Paris à l’échelle 1:15 000 (zoom 15)
Monde entier: 70 trillion pixels

5. 1. Qu’entend-on par Carte?
Carte de Paris à l’échelle 1:15 000 (zoom 15)
Monde entier: 1 billion tiles 256x256 pixels

6. 1. Qu’entend-on par Carte?
Zoom 0
Scale 1:500 Million
Zoom 1
Scale 1:250 Million

7. 1. Qu’entend-on par Carte?
Rendu jusqu’au Zoom 19:
Somme des tuiles des zooms 0 à 19:
S = ~= 366 billion tiles

8. 1. Qu’entend-on par Carte?

9. Ca sert à quoi un map-server?
A dessiner des données sur des cartes (routes etc…)
A faciliter le stockage / le cache / les flux de données
A gérer la stratégie d’import / réimport

10. Dessine moi une carte
Entrée: Règles de “dessin”
Sortie: Moteur de rendu
Lecture en DB
Clipping / drawing
Prend du temps et des ressources
quelques ms à plusieurs minutes de rendu
utilise le CPU, la mémoire & le disque

11. Dessine moi une carte
Besoin d’optimisations
… sur la DB
… sur le style
… sur les requêtes

12. Optimiser le rendu des tuiles
Concept : La Meta-tile
Rendre plusieurs tuiles côte à côte, et les découper ensuite
Avantages
Empêche de saturer les I/O
Diminue grandement les connections actives BDD
Inconvénients
Génère des tuiles inutiles è plus long

13. Optimiser le rendu des tuiles
Rendement
28/64 = 43%
Ex: Meta8
Rendement
28/256 = 11%

14. Donc…
Impossible de pré-calculer toutes les tuiles du monde à tous les niveaux de zoom.
c’est (infiniment) long
ça prend trop de place, c’est éphémère
Besoin de logiques de “cache” et de “pré-rendu”
Système hautement contraint

15. Stockage des tuiles et cache
Une “map” ó entre 12 et 48 tuiles
è Comment diminuer mes I/O quand je vais chercher des données?

16. Stockage des tuiles et cache
Stocker les tuiles contigues ensemble (Meta-Tile)
Concentrer les requêtes demandant la même information
Garder un cache mémoire (LRU)

17. (Ré-)importer des données
Une archive à importer dans une base
Des traitements sur la donnée pour le rendu
Peut prendre plusieurs heures à quelques jours

18. (Ré-)importer des données
Attention à la stratégie de mise à jour (fréquence, diff)
Besoin d’une stratégie d’invalidation des caches
A dimensionner de façon intelligente

19. Nos choix TKs
Comment bâtir nos services
Robustes, scalables et performants

20. Hosting strategy

21. Hosting Strategy
+ : Ressources dédiées
- : Scalabilité, prix,
defaillance HW
+ : TTM réduit
- : Latence, vendor-lock, $
Serveurs Dédiés Cloud + EBS +
CDN + ALB + ASG
+ : Faible Latence, full-control
- : Long à dev, risque de failure
Cloud + Manuel
- : ressource mutualisée

22. Monolith vs Micro-Service

23. Micro-Service approach
Pros:
• Maintenabilité
• Micro-Scaling
• Technology-independent
Cons:
• + de chaos, + de failles
• Nécessite une infra bien pensée
• Coute (en général) plus cher

24. Orchestrator/Scheduler
vs
Homemade

25. Homemade
Paradigmes:
è Detect-fast, Fail-fast, recover-fast
è No recovery automation
Service-discovery / DNS: Consul
Outils monitoring: Telegraf, Kapacitor
Time series DB: InfluxDB

26. Reactive programming

27. Reactive
Modèle classique:
1 requête = 1 thread
10 requêtes = 10 threads
100 requêtes = 100 threads
… Mais combien d’opérations peuvent réellement être
exécutées en même temps?
Modèle réactif:
Des requêtes, des “workers”
Optimiser l’activité du thread plutôt que le nombre de threads
27

28. Architecture
24 prod servers
6 websites
Lab – Manager – Style –
Demo – WWW – Swagger
9 public APIs
Account – Storage - Static maps – Tile-edge –
Auth – Stats – Style Registry – Geocoding – Routing
11 backend services
Cassandra – InfluxDB – Telegraf – Grafana – Kapacitor –
Consul – Registry – Gitlab – PFSense – YouTrack – PostGreSQL
4 private APIs
Keystore – Tile-edge-diff –
Tile-edge-renderer –Stats – Tile-edge-worker
2 SDKs
Android, iOS

29. Load Testing
Les conditions aux limites

30. Objectifs
• Admettre le plus de trafic possible sur chaque machine
• Avoir un temps de réponse le plus bas possible

31. KPIs
• Performance =
Maximiser le nombre de requêtes par seconde
+
99th percentile <= 800ms
99.9th percentile <= 1200 ms
0 timeout ou requête non satisfaite

33. Test de performance
• Mode Cluster
• Métriques ultra-détaillées
• Live reporting

34. Architecture dans la Réalité
PRISE EN MAIN
RAPIDITE
EXACTITUDE
BANDE PASSANTE
CPU
MEMOIRE
CPU
CPU
MEMOIRE
I/O
UTILISATEURS
APP CACHES
RENDERS
APP LB
APP LB
BANDE PASSANTE
CPU

35. Architecture Test de Charge
EG-30
HG-30
EG-15
HG-120
INJECTEURS
APP CACHES
RENDERS
APP LB
APP LB EG-7
• 8 vCores 2,3Ghz
• 30 Go RAM
• 2 Gbps BP
• 2 vCores 2,3Ghz
• 7 Go RAM
• 300 Mbps BP
• 8 vCores 3,1Ghz
• 30 Go RAM
• 2 Gbps BP
• 4 vCores 2,3Ghz
• 15 Go RAM
• 1 Gbps BP
• 32 vCores 3,1Ghz
• 120 Go RAM
• 4 Gbps BP

36. Rétrospective : les embûches
Setup
Spawn time
OVH Manager vs Horizon + Nova + Neutron
Déploiement
SSHJ + OpenStack
Run
nf_conntrack_max
steal-cpu et network softirq
Bande passante

37. Rétrospective : avec 4 caches
850 000 utilisateurs en 30 min
Entre 1 et 15 map views / user(ó entre 28 et 420 tuiles / user)
Sur les 12 zones les plus peuplées du monde entier

38. Rétrospective : avec 4 caches
108 k req/s en pointe ó ~25k req/s/cache
Moyenne des temps de réponse = 65 ms
99.9th percentile de temps de réponse < 600ms

39. Rétrospective : avec 4 caches
2 Gbps atteints sur EG-30
~10k utilisateurs concurrents

40. Rétrospective : avec 4 caches
90% CPU utilisé
5% IOWait
Steal & softirq négligeables

41. Rétrospective : recommandations
Optimiser la bande passante
Choisir les bonnes instances (Cloud ou Dédié)?
Compression g-zip (tile-edge-cache)?
Affiner le tuning kernel / DB / Runtime / Conf
file descriptors, ulimit, conntrack
PostGIS / profil d’import
Optimiser l’architecture
Cache de niveau 2 – Object Storage
Séparation DB / Render

42. 300+ Références
42

43. 300+ Références
43
Pourquoi n’es-tu pas sur cette liste?

44. Jawg Lab
Viens, on est bien!

45. White Papers
1. Map services: from theory to implementation
Disponible maintenant @ http://jawg.io
2. Map services: Benchmarks & high-scale profiles
Disponibles sur demande

46. Loïc Ortola
CEO @ jawg
Loïc Ortola @LoicOrtola
loic@jawg.io
jawgmaps Merci
?