Le document aborde la scalabilité et la haute performance des applications PHP legacy, en mettant en lumière les défis liés à la performance et aux exigences des clients. Il distingue clairement les concepts de scalabilité, de haute performance et de haute disponibilité, tout en proposant des solutions techniques pour améliorer la situation des applications existantes. Enfin, il évoque des astuces pour l'optimisation de la mémoire, des bases de données, ainsi que l'utilisation d'outils pour le test de charge et l'accélération des serveurs.

1. SCALABILITÉ &
HAUTE
PERFORMANCE
DES
APPLICATIONS
PHP LEGACY

2. QUI-SUIS-JE ?
Arnaud LEMAIRE
www.software-craftsman.fr
Lead developer @Ibsciss : www.ibsciss.com
Software Architect @Quantis : alemaire@quantis.fr
Lead Software Architect @LeMêmeEnMieux : www.lmem.net
Twitter : @lilobase

3. !! PUB !!
• Le même en mieux : nous vous apportons un meilleur produit
que celui que vous consultez, et c’est vraiment cool !
(www.lmem.net)
• Ibsciss : développement logiciel à haute valeur ajoutée pour les
entreprises en phase de transitions (www.ibsciss.com)
• Quantis : conseil & formation en architecture logicielle
(alemaire@quantis.fr)
• 1cup Expert : conseil et aide bénévole 1 après midi par mois
pour des entrepreneurs (www.1cup.io)

4. EN FORMATION SUR LA SCALABILITÉ
PHP 5.5, Besoin pris en compte dès le démarrage, développeurs ultra
compétents, sujet maitrisé, etc.

5. MAIS EN RÉALITÉ

6. VOTRE MISSION SI VOUS L’ACCEPTEZ :
RENDRE LE PRODUIT SCALABLE SANS
TOUCHER À LA CODEBASE !

7. EXEMPLE DE
SITUATION
Super Projet W :
• PHP 5.3
• Code Spaghetti
• Des dépendances dans tous les sens
• Base de donnée avec des doublons, plus d’une centaines
de table, etc.
• …
En résultat :
on touche, ça s’effondre

8. ELÉMENT
PERTURBATEUR (1)
Le client :
« Je vous achète le produit s’il répond en moins de 4
secondes à 500 requêtes / secondes dans 1 mois. »
Le commercial :
« Pas de problème ! »

9. ELÉMENT
PERTURBATEUR (2)
Le gestionnaire :
« On a pas le budget pour faire des modifications sur le
logiciel en avant projet »
Le développeur :
« … »

10. LE DÉVELOPPEUR (2)

11. THÉORIE !

12. SCALABILITÉ
≠
HAUTES PERFORMANCE
≠
HAUTE DISPONIBILITÉ
DÉFINITIONS

13. • Un système scalable peut être très lent et régulièrement
en panne
• Un système performant peut ne pas être scalable et
tomber régulièrement en panne
• Un système qui ne tombe jamais en panne peut être très
lent et ne pas être scalable.
SOUVENT CONFONDU, CE SONT DES CONCEPTS
DIFFÉRENTS (MAIS TRÈS LIÉS)

14. DÉFINITION :
SCALABILITÉ
D’après wikipedia : En informatique matérielle et logicielle et en télécommunications, la
scalability ou scalabilité (calque de traduction) désigne la capacité d'un produit à
s'adapter à un changement d'ordre de grandeur de la demande (montée en
charge), en particulier sa capacité à maintenir ses fonctionnalités et ses performances
en cas de forte demande.
SCALABILITÉ = ON PEUT AUGMENTER LE NOMBRE DE
REQUÊTES EN SIMULTANÉE

15. VERTICALE OU HORIZONTALE ?
SCALABILITÉ

16. VERTICALE : ON ACHÈTE UN SERVEUR PLUS PUISSANT,
HORIZONTALE : ON DÉPLOIE SUR PLEIN DE PETIT SERVEURS

17. HAUTE
PERFORMANCE
HAUTE PERFORMANCE = ÇA RÉPOND (TRÈS) VITE
Le temps de réponse, ou temps de latence, est le temps écoulé
entre une commande et la réalisation de cette commande.

18. DÉFINITION :
HAUTE
DISPONIBILITÉ
D’après wikipedia : La disponibilité d'un équipement ou d'un système est une mesure
de performance qu'on obtient en divisant la durée durant laquelle ledit
équipement ou système est opérationnel par la durée totale durant laquelle on
aurait souhaité qu'il le soit. On exprime classiquement ce ratio sous forme de
pourcentage.
Il ne faut pas confondre la disponibilité avec la « rapidité de réponse », que l'on
appelle aussi « performance ».
HAUTE DISPONIBILITÉ = ÇA MARCHE TOUJOURS

19. LA SCALABILITÉ EST UNE SOLUTION POUR
OFFRIR HAUTE PERFORMANCE & HAUTE
DISPONIBILITÉ

20. REVENONS
À NOS
MOUTONS
VOUS SAVEZ, LES 500 REQ/S…

21. DÉCOUPONS LE
TRAVAIL
Une application classique :
PHP MySQL

22. HTTP EST STATELESS
PHP est construit sur le modèle d’HTTP
très bonne nouvelle :
• Toute la mémoire est détruite après chaque requête :
• Que ce soit A ou B qui exécute la requêtes le résultat est
normalement le même (si ce n’est pas cas, VOUS avez fait
une connerie).

23. OU PAS…
PHP est stateless, sauf la session…

24. LE PROBLÈME DE LA
SESSION : 5 MINUTES
• On installe un memcacheD
• On change deux clefs du php.ini :
• session.save_handler = memcached
• session.save_path = hoteMemecacheD :port
• On relance Apache
C’EST FINI, VOTRE COUCHE APPLICATIVE
EST PRÊTE !

25. TRAVAILLER LES
PERFORMANCES
Cache d’opCode :
• APC pour php 5.3 (que vous ne devriez plus utiliser !)
• Astuce : apc.stat=0 (évite des I/O disque)
• Inclus par défaut dans PHP 5.5
• Placez la directive opcache.enable sur On (dans php.ini)
• Astuce : opcache.validate_timestamps=0 (évite les accès
disques)

26. LA BASE DE DONNÉE

27. MAIS…
La base de donnée est rarement le point de blocage lors la
première montée en charge de votre application !
(dans notre cas, avec deux serveurs applicatifs à 100% en
plein test de charge, la charge CPU de l’unique serveur de
DB était à 10%)

28. MAIS ENCORE
A condition de faire une petite optimisation :
• PLEIN de ram (en tout cas plus que la taille de votre base)
• innodb_buffer_pool_size avec une valeur la plus haute
possible : 5-6GB (8GB RAM)
• mysql_query_cache avec une bonne valeur (pas trop non
plus car cela augmente la charge CPU)

29. DOCTRINE2
Petite astuce : utilisez le eager loading
(cela évitera 300 requêtes par pages quand une seule suffit)

30. DES INDEXES, PLEINS
D’INDEXES
La mise en place d’index sur les colonnes utilisées dans les
clauses WHERE ou de jointure accélèrent (vraiment
beaucoup) le temps de réponse de la Base de donnée

31. ET LA RÉPLICATION
MAITRE ESCLAVE ?
On est dans une application légacy, vous pensez vraiment
qu’il y a une séparation entre écritures et lectures ?

32. OK, DONC DU MAITRE
MAITRE ?
Le vrai nom est : circular replication
• Problème de
modifications
concurrentes
• Et si un des serveurs
tombe en panne ?
• Ça pose pas mal de
problèmes !

33. MYSQL CLUSTER
La Rolls-Royce : actif actif, temps réel !

34. ON ESSAYE DE SCALER VERTICALEMENT SA BASE
DE DONNÉE, QUAND ON NE PEUT PLUS ON PASSE
SUR DU CLUSTER.

35. INFRASTRUCTURE
• Mettez en place un « accélérateur web » type varnish en
frontal qui servira les assets statics
• Utiliser un outil de provisionning (Ansible) pour configurer
vos serveurs.

38. DEMO
La question est de savoir comment mettre en place ce type
d’architecture simplement.
La solution Gandi IAAS/VM à été utilisée pour mettre en place
l’infrastructure en question en quelques heures.

39. GESTION DES SERVEURS

40. ASTUCE : PLACER UN ACCÉLÉRATEUR WEB EN
FRONTAL DES SERVEURS APPLICATIFS

41. CONFIGURATION DES SERVEURS APPLICATIFS
LOAD BALANCÉ PAR L’ACCÉLÉRATEUR WEB

42. IL EST TEMPS DE
TESTER LA CHARGE
• Siège : très simple, en gros un DOS (outil « desktop »)
• Jmeters : test de charge avec scénario (outils « desktop »)
• Loader.io : test de charge avec scénario (outil « saas »)