Concevoir des back-offices performants

Concevoir des back-offices performants

8665aad8f35b1710df79e9aef52d6daa?s=128

Alexandre Salomé

June 26, 2020
Tweet

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

  37. None
  38. Insérer 500 entités avec Doctrine ORM

  39. None
  40. Insérer 500 entités avec Doctrine DBAL

  41. None
  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

  49. None
  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