Le document aborde l'optimisation et la sécurisation du code pour PrestaShop, en se concentrant sur les meilleures pratiques en matière d'architecture et de performance. Il souligne l'importance de la maintenabilité du code avant la performance, en émettant des recommandations sur les moments appropriés pour optimiser, ainsi que sur les outils et méthodes pour mesurer les performances du système. Enfin, il met en avant l'impact des architectures d'infrastructure et des requêtes de base de données sur la vitesse et l'efficacité des applications.

1. Optimisation et sécurisation du code de PrestaShop

2. GroupeSitti (www.sitti.fr)

3. Équipe de 6 développeurs & intégrateurs

4. 400 PrestaShop installés – versions de 0.9.6 a 1.3.1

5. Hébergementmutualisé – cluster de 10+ machines (load balancers, serveurs web, serveurs de fichiers, serveurs de bdd) A propos de nous ?

6. Les 4 pilliers de la performanceInfrastructure(serveurs, bases de données)

7. Focus sur : Code côtéserveur (1ère couche, PHP + SQL)

8. Réseau, protocolede transport

9. Code côté client (2eme couche: HTML+ CSS + Javascript)(…) Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: 1premature optimization is the root of all evil.Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified.Très important(Donald E. Knuth)

10. Votre architecture doitêtreéfficace(une bonne planification)

11. Vousdevez coder en utilisant les meilleurespratiques(ne pas faire de choses stupides ;))

12. Préférezplutôt la "maintabilité" et la lisibilité du code aux performances

13. Lorsquela performance n'estpas critique (ex. systèmes temps réel, sites à fort trafic), vouspourrezl'améliorerdansdes versions ultérieuresQuand faut-il optimiser ?

14. Mesurezd'abord ! Vousdevezconnaitre les points critiques, les goulotsd'étranglement

15. Mesurezdifférents scénarii et configurations

16. Passer sous Linux? Test Linux, non Win. => différences

17. Aurez-vous plus de 10000 produits? Tester votre module avec une base de 10000 élémentset non 5

18. Est-ceque 1% d'amélioration justifie un travail additionnel?

19. Et 5%? 10%?

20. Essayez d'estimer le coût de développement vs. coûtmatériel : parfoisc'est moins cherd'ajouter de la mémoire viveQuand faut-il optimiser ?

21. Les petits gains de performanceEn utilisant (int) au lieu de intval () estpeutêtre 4x plus rapidemaisle gain global estnégligeable (saufsivousêtesFacebook)Le code exécutéuneseulefoisTools::setCookieLanguagepourraitêtreaméliorée, maisellen'estexécutéequ'uneseulefoisLes optimisationsmythiques ( ” vs ' )Mais”$a $b $c” … est plus rapideque $a.” ”.$b.” ”.$c Qu'est-ce qu'il n'est pas nécessaire d'optimiser ?

22. Charge serveur:ab, siege, multi-mechanize ...Charge de la base de donnée:MySql Slow Query Log, mysql proxy, ...EXPLAIN PHP:xdebug, dbg, xhprof ...Network / client sideYslow, Firebug, WebKitinspector, dynaTrace AJAX, fiddler, Google webmaster toolsComment mesurer ?

23. Serveur:Tâchedifficile, voire impossible sur des hébergementsmutualisésDemandez à votre admin sys ;)Le CPU est rarement un point critique, il indique généralement des problèmes avec le code non-optimiséLa RAM est bon marché mais pas illimitée - attention à la consommation de mémoire des scriptsProblèmetypique : gd + jpg -> 2 Mb surdisque, 33 Mb décompressésen mémoire

24. Ramdisk pour les fichierssouventappelés (frameworks, configuration, tmp) Le point généralement critique: I/O (filesystem, dbs)Amélioration de l’infrastructure

25. Chaque appel aux fichiers a un coût qui dépend de l'OS, du système de fichiers et du nombre de fichiersToujoursutiliser des cheminsabsolusdans require/ includeLes performances peuventcommencer à se dégradersivousavez plus de 50 000 fichiersdans un répertoire

26. Chaqueproduit a une image, chaque image a 6 vignettes

27. Debian+ Apache 1.3 (hébergement mutualisé, nfs):Système de fichiers# FilesGlob('*') exec. in sec.file_exists / sec.10004,59360001100013,30210006500055,811475122000142,16718

28. Fractionnement du contenu des répertoiresimg/p/534-189-small.jpg devient img/p/small/534-189.jpgLecture transparente avec un .htaccessRewriteRule (.*)/p/([^/]*)home\.jpg $1/p/home/$2home.jpgEcriture transparente en php if (!imageResize($file, $dir.$imageType['name'].'/'.$language['iso_code'].'-default- '.stripslashes($imageType['name']).'.jpg', ...Solution

29. Base de donnéeVérifiezvos indexes!

30. Attention aux jointures!SELECT * FROM ps_feature` f LEFT JOIN ps_feature_lang` fl ON ( f.`id_feature` = fl.`id_feature` AND fl.`id_lang` = 1) WHERE f.`id_feature` = 1SELECT * FROM ps_feature_lang` fl WHER fl.`id_feature` = 1 AND fl.`id_lang` = 1 VersionTablesColumnsWithout index1.1.0.588458501.2.0.5134670501.3.101356792 (cool! :)

31. Utilisez des VIEWs à la place de SELECTs compliquésAvezvousbesoin de ps_connections& ps_connections_page?Si vousavez un traficconséquent, celles-cipeuventgrossir de plus de 10+ Mb / jourBase de donnée

32. Grosproblème, requêtes non uniques: 1.3.10, simulation du processus de commande:Index – recherche – connexion – commande(11 pages au total)3001 requêtes SQL, maisseulement 1314 uniques! (44%) PHP - SQL

33. Requêtes répétées

34. Requêtes non optimisées

35. Le mieuxestd'utiliser un proxy MySQL oumemcached

36. Utiliserun cache en interne:Peutêtreplacé en local ou globalPrestaShop utilisepartiellementun cache local