Concevoir des back-offices performants

Transcript

1. Concevoir des back-offices performants
2. Interactivité - Questions dans LiveStorm - Traitées par popularité - Le chat pour parler entre vous Merci de respecter le code de conduite de l’Afup.
3. Le plan - Le front-office, rapidement - Pourquoi c’est lent ? - Mesurer et analyser - Cas pratiques - Pourquoi c’est rapide ? - Bonnes pratiques à emporter
4. Introduction
5. Du front-office au back-office Front-Office Back-Office
6. L’appel HTTP
7. L’appel HTTP Le Back-Office Requête Réponse
8. L’appel HTTP Le Back-Office Requête Réponse
9. Les appels HTTP
10. Notre champ d’étude Front-Office Back-Office
11. Arrêt n°1 sur 6
12. Les lenteurs
13. Calcul Transport Mémoire La performance du système
14. Le processeur Problèmes courants : - Calcul coûteux - Peu/pas de disponibilité - Un seul coeur utilisé - iowait
15. La mémoire Types : RAM / SSD / HDD / Réseau Problème courants : - RAM saturée (= SWAP) - Disques durs - Latence lecture/écriture - IOPS - Réseau lent - Cf slide suivante d’après
16. Le transport Types : Intranet / Extranet Problèmes courants : - Latence - Débit - Connexions impossibles - Connexions perdues
17. Stockage et distance Sources: https://gist.github.com/hellerbarde/2843375 et https://wondernetwork.com/pings Type Latence Équiv. Distance L1 0.5 ns 1 centimètre RAM 100 ns 2 mètres SSD 150 µs 3 kilomètres HDD 10 ms 200 kilomètres Paris > Londres 10 ms 200 kilomètres Paris > New York 75 ms 1500 kilomètres
18. PHP Problèmes courants : - Opcache absent - Autoload non optimisé - Utilisation du disque dur Aller plus loin - validate_timestamps
19. Bases de données Problèmes courants : - Slow queries - Requêtes répétées inutilement
20. Arrêt n°2 sur 6
21. Mesurez
22. Pas d’amélioration sans mesure - Instrumentalisation, journalisation - Agrégation des données (moyenne, min-max, quartiles)
23. L’architecture, rapidement Système Services Applications
24. Cartographiez
25. Stressez
26. Stressez
27. Descendez Identifier une requête lente L’optimiser
28. Tracez
29. Tracez
30. Stressez
31. Stressez
32. Mesurez
33. Arrêt n°3 sur 6
34. Cas pratique : Insertion SQL
35. Nom Type id uuid user_id uuid created_at datetime event_type varchar data json user_event
36. Insérer 500 entités avec Doctrine ORM
38. Insérer 500 entités avec Doctrine ORM
40. Insérer 500 entités avec Doctrine DBAL
42. Cas pratique : Lecture SQL
43. Requête de lecture
44. Exemple SQL : les index
45. Fonctionnement de l’index * register login logout 2020 2019 2018 Mai Juin Avril
46. Cas pratique : extraction CSV
47. Manière brute
48. Morceau par morceau
50. Arrêt n°4 sur 6
51. Pourquoi c’est rapide
52. Spécialisation - Bases de données relationnelles : MySQL, Postgres - Cache : Redis, memcached - Recherche : ElasticSearch - Séries temporelles : InfluxDB, Graphite - Messagerie : ActiveMQ, RabbitMQ - Flux d’événements : Kafka - Stockages larges : MongoDB
53. Multi-threading - Pas possible en PHP et permet d’éviter beaucoup d’erreurs - Lancer le même processus plusieurs fois, en parallèle
54. Multiplier les instances - Élasticité verticale
55. Ne pas utiliser le disque dur - PHP, correctement optimisé, travaille uniquement en RAM - S’assurer que son traitement n’utilise pas le disque
56. Conférence liée Bonnes pratiques de déploiement PHP en 2015 Quentin Adam
57. Les clusters
58. Réplication Écritures Lectures Lectures Lectures
59. Principal et réplication / Primary and replica Permis par la plupart des système, plus ou moins facilement. Si l’instance principale échoue, une des réplication deviendra principal. Principal Réplication Réplication Réplication
60. Distribution A-E F-J K-O P-T U-Z
61. Aggrégation A-E F-J K-O P-T U-Z
62. Arrêt n°5 sur 6
63. Bonnes pratiques à emporter
64. Puppet show Bonjour, je voudrais la liste de tous les utilisateurs, toutes ses informations personnelles, ses e-mails, ses numéros de téléphones, ses adresses, ses 10 dernières connexions, la liste des amis et la liste de ses permissions. S’il te plaît.
65. Puppet show 20 Go
66. Quand on conçoit un traitement - Identifier les données impliqués, leurs volumes - Identifier les transports associés - Identifier les calculs faits Restez le plus simple possible Si impossible : découper, distribuer, cacher, etc.
67. Comprendre avant d’agir En priorité, cherchez à avoir de la visibilité et une mesure du problème : - iowait = 80% - Disques durs plafonnent en IOPS Une fois la cause exacte identifiée en production, reproduire en local.
68. Abandonner le mythe “iso-production”
69. Le cycle d’optimisation de la performance Mesurer le problème Changer 1 chose
70. Dernier arrêt
71. Remerciements - Afup, tous ses bénévoles et tous ses membres - Les-Tilleuls.coop pour l’hébergement - WeLoveDevs.com pour le matériel - Icônes par Freepik de Flaticon - Code rendu par carbon.now.sh