Kiwiparty 2011 - Optimisation des sites internet

Optimisation des sites internet Lilian RIGARD

Qui suis-je ? Lilian RIGARD - CEO & CTO Devclic - Dans l'internet depuis 1995 - Fort intérêt pour l'optimisation des sites internet - Développeur PHP et Administrateur Système / Réseau - 10 ans d'expérience en PHP - Formation : autodidacte - Twitter : @liliandev - Email : [email_address]

Qui est Devclic ? - Fondée en 2004 (SARL depuis 2005) - Hébergeur de sites internet / Opérateur Internet / Consulting
Hébergement mutualisé / dédié / infogéré et de sites internet à fort trafic
Opérateur internet déclaré au RIPE : ADSL, SDSL, Fibre Optique, Transit IP
Consulting en création de sites internet / Développement spécifique
- Editeur de sites internet
Blog du High-Tech / NDFR / MeilleursPrix / Forum-Webmaster
- Infrastructure :
Présence dans 3 Datacenters (2 à Strasbourg, 1 à Paris)
150 Serveurs en propre (Virtuels et Physiques)
- Références :
Jetelecharge / Zebest-3000 / Videoavolonte / FC Metz / Les-Horaires / Fysiki / Direct FM
Des nouveaux à venir : ... vous ?
- Twitter : @devclic - Email : [email_address] - Site internet : non mentionnable … :-)

L'Optimisation des sites internet Ma définition : C'est le fait de gagner partout on l'on peut des « ms » afin de faire diminuer la charge serveurs , diminuer le temps de chargement des pages du site internet et devenir un peu plus « green » Cela permet :
De faire des économies
Sur l'hébergement
Sur la bande passante
Sur les machines
De rentabiliser au maximum son site internet et son activité
Plus de revenus PUB
Plus de transformation
Plus de fidélisation
De supporter plus de trafic pour un investissement très bas voir néant
Le développeur doit faire correctement son travail
D'être mieux référencé (Google)
D'améliorer la disponibilité de son site internet
D'afficher que votre site internet est « vert » (« green »)

Pourquoi ne pas optimiser ?
Manque de compétences en interne
Méthode Microsoft : je rachète des plus gros serveurs ou j'en mets plus
Manque de temps
Fainéantise
Y trouver aucun intérêt (enfin jusqu'à aujourd'hui …)

L'importance du temps de chargement Des résultats de mesures effectuées :
Google : Chargement + 500 ms donne 20 % de trafic en moins
Yahoo : Chargement +400 ms donne un abandon de 5 à 9 %
Bing : Chargement : +1 s donne 2,8 % de perte en publicité
Impacts :
Chiffre d'affaires en moins
Internautes cherchant d'autres sites internet (manque de temps général)
Coûts d'exploitation augmentés

Exemples concrets de non optimisation
Jetelecharge
Utilisation d'un script tout fait et mal développé
France.fr
Manque de savoir faire dans l'intégration et l'utilisation de Drupal
Manque de savoir-faire dans les architectures Web
Manque de savoir-faire dans l'optimisation des sites internet
Facebook
Manque de connaissance au démarrage du projet

Exemple concret d'optimisation JeTelecharge ( Lexgo Network EURL ) : En 2002 :
Création du site internet avec l'utilisation d'un script déjà tout fait
Peu de visiteurs
En 2003 :
1000 à 4000 visiteurs / jour
Plantage régulier du serveur -> Administrateur Système pas content :-)
Webmaster pas content non plus ( manque de Chiffre d'Affaires ) et perte de visiteurs
En 2004 :
Intervention Devclic : création d'un nouveau script avec reprise de la base de données de l'ancien
-> Plus de problème de charge
-> Le site accueille sans problème plus de visiteurs
En 2011 :
50 à 60 000 visiteurs uniques / jour
167 000 € de CA pour l'année 2010 (source societe.com)
4 ou 5 sites sur le même modèle de script avec des améliorations de la part du Webmaster ( ancien stagiaire Devclic :-) )

Quels axes d'optimisation ? L'architecture -> Permet d'obtenir tout de suite la meilleure architecture logicielle et la meilleure façon d'arriver à notre but -> Permet en remplaçant un logiciel par un autre d'enlever le point de blocage -> Permet en activant certaines options du kernel Linux de diminuer les coûts d'exploitation -> Permet de supprimer des points de blocage en changeant l'architecture de la solution ( ex. : Master / Slave MySQL ) Le code source
Côté Utilisateur
Côté Serveur
->Permet de gagner très simplement de la charge et de diminuer les temps de réponse ( modification du code )

Optimisation de l'architecture L'architecture est composée de 2 architectures liées :
L'architecture logicielle (votre application et toutes les applications permettant son fonctionnement)
L'architecture matérielle
L'architecture logicielle doit être pensée dès le début du projet à savoir comment je vais arriver à mon but, quelle est la meilleure façon pour le faire (on doit penser optimisation dès le début) Exemple : un compteur de connectés en simultané, comment le développer sans impacter mes performances ? Facebook, à ses débuts, à utiliser une base de données MySQL, choix qui s'est annoncé très problématique puisque le site a connu de fortes indisponibilités dès lors qu'il y avait beaucoup de connectés L'architecture logicielle dimensionne l'architecture matérielle et les conséquences peuvent être lourdes si l'application est mal conçue / pensée

Optimisation de l'architecture Changer de serveur Web, faire un choix entre :
Apache
Nginx
Cherokee
Lighttpd
Lequel choisir ?
Apache pour PHP
Nginx, Cherokee, Lighttpd pour les fichiers statiques
Pourquoi ?
Garder la flexibilité d'Apache ( .htaccess et certains autres modules utiles )
Limiter l'utilisation de la RAM ( Apache gère très mal les fichiers statiques)
Profiter de la puissance des serveurs alternatifs : moins gourmands, plus résistants
Possibilité d'utiliser les serveurs alternatifs comme Reverse Proxy Cache
Impacts : Aucun, que du plus :-), il faut juste de la configuration

Optimisation de l'architecture Mettre un reverse proxy devant votre cluster Apache avec au choix :
Varnish
Squid
Lequel choisir ?
Cela dépend des affinités, il y a des plus et des moins dans chacun
Pourquoi ?
Garder la flexibilité d'Apache ( .htaccess et certains autres modules utiles )
Limiter l'utilisation de la RAM ( Apache gère très mal les fichiers statiques)
On stocke les images en RAM sur le Reverse Proxy
Les reverses proxys peuvent s'échanger les fichiers directement entre eux
Impacts : Aucun, que du plus :-) sauf 1 cas : l'authentification Basic qui ne fonctionnait pas correctement

Optimisation de l'architecture Optimiser Apache
Décharger les modules inutiles
Adapter les paramètres
- MaxClient / StartServer
- Timeout
- MinSpareServers / MaxSpareServer
- HostnameLookups Off
- MaxRequestsPerChild
Bien régler le cache client à l'aide de mod_expires
<IfModule mod_expires.c> ExpiresActive On <FilesMatch ".(ico|pdf|flv|swf)$"> ExpiresDefault "access plus 1 weeks" </FilesMatch> ExpiresByType text/css "access 1 weeks" ExpiresByType text/javascript "access 1 weeks" ExpiresByType application/x-javascript "access 1 weeks" ExpiresByType application/javascript "access 1 weeks" ExpiresByType image/gif "access 1 months" ExpiresByType image/jpeg "access 1 months" ExpiresByType image/png "access 1 months" </IfModule>

Activer la compression des pages via mod_deflate ou bien alors donner cette tâche à Nginx
<IfModule mod_deflate.c> <Location /> # Insert filter AddOutputFilterByType DEFLATE text/plain AddOutputFilterByType DEFLATE text/xml AddOutputFilterByType DEFLATE application/xhtml+xml AddOutputFilterByType DEFLATE text/css AddOutputFilterByType DEFLATE application/xml AddOutputFilterByType DEFLATE image/svg+xml AddOutputFilterByType DEFLATE application/rss+xml AddOutputFilterByType DEFLATE application/atom_xml AddOutputFilterByType DEFLATE text/javascript AddOutputFilterByType DEFLATE application/x-javascript AddOutputFilterByType DEFLATE application/javascript AddOutputFilterByType DEFLATE application/x-httpd-php AddOutputFilterByType DEFLATE application/x-httpd-fastphp AddOutputFilterByType DEFLATE application/x-httpd-eruby AddOutputFilterByType DEFLATE text/html BrowserMatch ^Mozilla/4 gzip-only-text/html BrowserMatch ^Mozilla/4.0[678] no-gzip BrowserMatch bMSI[E] !no-gzip !gzip-only-text/html # Don't compress images SetEnvIfNoCase Request_URI .(?:gif|jpe?g|png|zip|rar|flv|pdf|wmv)$ no-gzip dont-vary # Make sure proxies don't deliver the wrong content Header append Vary User-Agent env=!dont-vary </Location> </IfModule>

Activer les etags
Changer le mode de fonctionnement d'Apache ( MPM Worker vs MPM Prefork ).
Intérêt : MPM Worker utilise des threads et est donc moins gourmand. MPM Prefork utilise des processus. L'utilisation des threads est beaucoup plus léger au niveau du système d'exploitation. - Dans le cas de PHP : si vous voulez garder un contrôle total via vos .htaccess alors vous pouvez laisser tomber MPM Worker, les php_admin_value, ou php_value ne sont pas interprétés étant donné que l'on doit utiliser PHP en mode CGI OU FPM. Il faut donc utiliser un php.ini pour modifier les directives, ce qui devient vite lourd dans le cas où l'on héberge plusieurs sites internet … Un module ZTS doit changer la donne, ma dernière tentative s'est vouée être un échec. - Dans le cas de Python : le mode MPM Worker permet d'utiliser WSGI qui stocke en RAM les fichiers Python. Votre application Web Python devient alors un processus à part entière.

Utiliser vlogger pour les ErrorLogs et AccessLogs pour tout simplement décharger Apache de cette fonction. Dans le cas ou l'on utilise WSGI, le reload d'Apache n'est pas très recommandé et régulièrement sur Zebest-3000, Apache se killer tout seul. Passage à vlogger et la suppression du reload a résolu le problème.
Mettre un niveau de logs suffisant : cela permet de réduire les I/O sur les disques, à fortiori si vous êtes sur un SAN ISCSI qui traverse un réseau de type ethernet

Optimisation de l'architecture Optimiser PHP
Utiliser un cache d'OpCode ( PHP APC ) comme Python le fait : transformation du code pré-processé en bytecode directement exécutable, ce qui fait gagner une étape et diminue la charge ainsi que le temps nécessaire à l'exécution
Stocker vos sessions PHP dans du Memcache ou via le handler files mais sur un tmpfs. Si vous vous servez de l'id de session donné par le handler de session de PHP pour stocker des informations comme le contenu d'un panier e-commerce alors stockez plutôt cela avec Redis. Redis est comme memcache sauf que l'on peut utiliser la réplication et qu'il enregistre les données toutes les 5 minutes ( paramétrable ) sur le disque dur
Utiliser la dernière version de PHP ( valable pour les autres langages notamment Python ). PHP 5.3 est plus rapide, plus performante et moins gourmande en mémoire.
- Ajout du support de PHAR ( l'équivalent des .jar de java )
- Meilleur support de l'objet
- Apport de PHP FPM
- Nouveau module de communication avec MySQL

Optimisation de l'architecture Choisir des alternatives à MySQL
Utiliser du stockage orienté document ( MongoDB ) : plus rapide que MySQL, supporte les transactions et les propriétés ACID
- permet de stocker très facilement un article et des commentaires liés à cette article -> représentation sous forme de tableau
Exemple :
$article = { 'title' => 'KiwiParty',
'comments' => { 'userid'=>'1', 'text' => 'Trop cool !' }, { 'userid'=>'10', 'text' => 'Kikoo, LOL !' } } On a un article avec des commentaires directement rattachés, on évite les JOIN en tout genre
Utiliser Redis ou Memcache pour stocker des données nécessaires à du cache, à de l'affichage dynamique ou bien partagées entre plusieurs utilisateurs. L'intérêt est que c'est stocké en RAM : très rapide. Redis et Memcache sont des serveurs de stockage de type clé / valeur

Optimisation de l'architecture Choisir des alternatives à MySQL
Pour vos champs de recherches sur vos sites internet, il est fortement déconseillé d'utiliser les fonctions de recherches intégrées dans MySQL car ce n'est pas du tout optimisé ( le FULLTEXT ). On recommande vivement l'utilisation de logiciels faits pour cela ( Sphinx ) qui va faire les recherches régulièrement dans la base de données, les récupérer et les stocker à sa façon. On a constaté des énormes gains de temps ( Tests sur Zebest-3000 ou Videoavolonte )
Utiliser un autre SGBD :
Maria DB qui se base sur MySQL mais qui profite d'améliorations de la part du créateur de MySQL
SQLite en memory ou bien sur un TMPFS ( RAMDISK )

Optimisation de l'architecture Optimiser MySQL
Bien choisir le format de vos tables MySQL ( Innodb vs MyISAM )
MyISAM est la plus performante en lecture brut mais ne supporte pas les transactions ( verrouillage de toute la table, les requêtes en SELECT sont en attente )
InnoDB supporte les transactions mais est moins performante ( verrouillage de la ligne )
Préconisation de MyISAM dans la plupart du temps sauf pour des données critiques nécessitant des transactions. Si vous faîtes que des INSERT et très peu de SELECT (grâce au cache), vos visiteurs ne verront pas de latence
Partir sur de la répartition de charge MySQL via du Master / Slave
Ne jamais utiliser du MySQL Cluster ( données stockées en RAM, risque de grosse perte si un node se coupe )
Utiliser une architecture à base de Master / Slave : plusieurs slaves répliquent leurs données à partir du Master. Le Master sert uniquement pour les INSERT et les Slaves pour les SELECT. On élimine le problème de la concurrence des requêtes. L'execution des requêtes passe d'abord par le log binaire de MySQL et l'ordre est envoyé à tous les SLAVE

Optimisation de l'architecture Optimiser MySQL
Utiliser la libtcmalloc : librairie développée par Google permettant d'allouer beaucoup plus rapidement de la mémoire quand la fonction malloc est appelée
Mettre les tables temporaires MySQL en RAM avec un TMPFS : MySQL quand vous faites des ORDER BY utilise des tables temporaires qui sont stockées sur le disque dur et cela a pour effet de réduire très fortement les performances (un disque dur est beaucoup plus lent que de la RAM)
Faire en sorte d'avoir les bons index aux bons endroits, il faut tester ses requêtes avec la commande EXPLAIN de MySQL qui permet de savoir comment MySQL se débrouille avec votre requête

Optimisation de l'architecture Optimiser Memcache
Memcache fonctionne avec 2 protocoles : UDP et TCP. Il est vivement conseillé sur un réseau local d'utiliser UDP ( réseau composé de switchs ), par contre si vous attaquez des serveurs distants, vous DEVEZ l'attaquer en TCP. La différence est que TCP inclut un méchanisme de checksum qu'UDP n'a pas et donc on gagne encore du temps ...

Optimisation de l'architecture Optimisation du stockage de votre site internet Moins il y a d'I/O, plus vous pourrez accueillir de visiteurs sans problème -> utilisation de TMPFS pour stocker vos fichiers du site internet -> utiliser du stockage basé sur de la déduplication ( ZFS) ( moins de disques durs utilisés, moins de courant consommé, une architecture moins gourmande en besoin énergétique ) -> permet dans le cas d'un SAN ISCSI de ne pas avoir un point de failure surtout avec des filesystem de type cluster

Optimisation de l'architecture Optimisation du système d'exploitation ( Linux vs Windows ) Choisir le bon système d'exploitation permet tout de suite de partir sur de bonnes bases :
On sait très bien ce que contient chaque release du Kernel Linux alors que pour Windows c'est plutôt obscure
Peu ou pas de tuning possible avec Windows
Choisir Linux pour ces serveurs :
Avoir accès à des paramètres qui peuvent faire gagner en performance
Activer le KSM (Kernel 2.6.32) -> déduplication mémoire
Transmit Packet Steering de Google ( amélioration du transfert des paquets réseaux )
Transparent Hugepages (THP) (Kernel 2.6.38) -> réduction du nombres d'allocations mémoires nécessaires et donc augmentation des performances
Mettre le noatime sur ses partitions pour diminuer la charge des I/O
Pouvoir monter des RAMDISK ou du TMPFS (TMPFS est autorisé à utiliser la SWAP à l'instar de RAMFS)

Optimisation de l'architecture Optimisation de l'architecture matérielle Virtualisation au maximum :
Diminuer les coûts de production en utilisant moins de machines et en les utilisant le mieux possible
Activation de KSM qui permettra d'économiser sur la mémoire, moins de RAM utilisée
Allocation dynamique de la mémoire : pour une ressource donnée, je vais pouvoir l'autoriser à utiliser des Pics
Amélioration du rendement de l'infrastructure : moins d'alimentation puisque moins de serveurs, moins de chaleur dégagée
Développement orienté cluster :
Multiplication des petites machines ( moins performantes ) vs une grosse machine -> gain énergétique
Beaucoup plus scalable

Optimisation côté Utilisateur Moins de code pour obtenir le même rendu
Des div imbriqués dans d'autres div
Utiliser un simple <a href="/" class="logo">Mon Site Internet</a> à la place de la classique balise image et du lien qui l'entoure ( économie de bande passante car moins de code HTML dans la page et SEO optimisé )
Réduire la taille des pages ( cf. Google ), permet au navigateur de réduire son temps de parcours et d'analyse des pages, économise aussi de la bande passante
Utiliser au maximum les CSS -> réduit la bande passante consommée grâce à la mise en cache des feuilles de style : il vaut mieux un code HTML petit et des gros fichiers CSS que l'inverse Mettre en place de la compression des fichiers HTML / CSS / JavaScript grâce à du Minify
Réduit la taille du fichier par le remplacement de certaines portion de code par d'autres plus petites ( function test() deviendra par exemple function a() )
Réduit également la taille du fichier par la suppression des commentaires et espaces inutiles

Optimisation côté Utilisateur
Envoyer des fichiers pré-compressés via Gzip : évite de gzipper à la volée et pour chaque requête HTTP le fichier ( économie de processeur au niveau des serveurs )
Utiliser l'Ajax à bon escient : la technologie permet d'aller charger du contenu dynamiquement mais elle permet aussi de ne charger que ce qui est réellement nécessaire. A noter que l'on peut mettre en cache les données côté client ( économie de bande passante et de puissance de calcul ). On peut tout à fait créer des problèmes si l'on fait n'importe quoi en Ajax ...
Utiliser au maximum le cache côté Navigateur : cela permet d'éviter des requêtes HTTP inutiles pour re-télécharger toujours les mêmes ressources ( CSS, Images ). A noter que vous devenez green puisque vous ne sollicitez plus les routeurs et serveurs inutilement :-)
Si la ressource en cache est valide ( la date maximale de conservation n'est pas dépassée ), le navigateur va directement regarder dans son cache.
Regrouper toutes vos petites images (picto, boutons) en une seule image plutôt que de les séparer. En terme de ressources prises sur les serveurs et le réseau, il vaut mieux télécharger un seul gros fichier plutôt que plusieurs petits (moins d'entêtes HTTP utilisées -> économie de bande passante)
Utiliser le plus possible un domaine séparé pour tous les fichiers statiques : cela permet d'éviter de transférer des données de cookie pour rien si vous les utiliser

Utiliser un CDN du style Google, Yahoo, Akamai, Amazon avec des framework JavaScripts (jQuery, Dojo, Prototype ) : les CDN forcent les navigateurs à mettre en cache les fichiers
Le navigateur va directement récupérer le fichier dans son cache et va l'executer
Vous faîtes des économies de bande passante
Tous les utilisateurs consultant votre site internet s'implique dans la politique « green »
Eviter d'utiliser des Frameworks Javascript quand c'est inutile ( le bon vieux code JavaScript peut très bien le faire )
Effectuer des benchmarks côté JavaScript pour réduire les temps de parcours dans le DOM ou réduire la charge côté navigateur client
Essayer de mettre tous vos fichiers JavaScript en fin de page afin de ne pas pénaliser le chargement de la page et aussi de ne pas ralentir le serveur (une requête http bloquante va bloquer les autres requêtes à cause du KeepAlive qui permet de n'utiliser qu'une seule connexion pour tout télécharger -> moins de socket ouverts, réduction de la charge côté client et navigateur car on enlève la partie ouverture de socket)
Passer vos images à Smushit : il se fera un plaisir de supprimer les META DONNEES inutiles

Comment y arriver ?
Utiliser Yslow par Yahoo et Google Page Speed : ce sont des barres qui se rajoutent à Firefox ou Chrome, la barre vous donne le résultat et vous dit ce qu'il faut faire
Utiliser un site comme GTMetrix qui regroupe ces 2 barres sur un seul et même site, cela permet aussi d'avoir un historique
Pour compresser vos CSS et JavaScripts via du Minify, vous pouvez utiliser Minify ( http://code.google.com/p/minify/ ) -> en production sur Forum-Webmaster.com
Pour l'utilisation du CDN Google, voir ici ( http://code.google.com/intl/fr-FR/apis/libraries/ )
Pour optimiser vos images, il suffit de les envoyer à Smushit ( http://www.smushit.com/ysmush.it/ ), il y en a d'autres qui existent

Optimisation du code source PHP -> Petit Jeu Exemple (1) Quelle fonction est la plus adaptée ou la plus rapide ? require OU require_once Réponse : La fonction require Pourquoi ? Aussi simplement que ça, require effectue une simple inclusion du fichier sans effectuer d'opérations supplémentaires alors que require_once va effectuer dans tous les fichiers existants et déjà chargés, si une fonction n'est pas déjà déclarée, ce qui induit une perte de performances de 40 % ( selon les benchmarks réalisés ) Conclusion : require_once est la fonction du fainéant ! En tout cas elle est bannie chez Devclic et est fortement déconseillée par Zend (les utilisateurs du Zend Framework sont invités à utiliser la ligne de commande qui va bien et qui permet de supprimer tous les require_once)

Optimisation du code source PHP -> Petit Jeu Exemple (2) Quelle fonction est la plus adaptée ou la plus rapide pour récupérer le contenu d'un fichier ? require OU file_get_contents Réponse : La fonction file_get_contents Pourquoi ? Tout simplement parce que require demande à l'analyseur PHP de parcourir le fichier à la recherche de code PHP alors que filte_get_contents est tout simplement un alias de fopen / fget / fclose. L'appel à require ou include alors que l'on sert pertinemment que l'on a pas de code PHP dans le fichier appelé fait perdre du temps et aussi augmente la charge Conclusion : mauvaise habitude de la part des développeurs et aussi de la part de certains tutoriels sur internet

Optimisation du code source PHP -> Petit Jeu Exemple (3) Quelle syntaxe est la plus adaptée ou la plus rapide pour afficher du texte simple ? echo 'KiwiParty' OU echo " KiwiParty " Réponse : La syntaxe echo 'KiwiParty' Pourquoi ? La première syntaxe va demander à l'analyseur PHP de n'effectuer aucun traitement particulier et lui demander d'afficher tel quel le texte. Dans le deuxième cas, l'analyseur de code PHP va rechercher des eventuelles variables, ce qui induit un temps de traitement supérieur Conclusion : mauvaise habitude de la part des développeurs, il faudrait utiliser le plus possible la syntaxe sans recherche de variables et de même, il est fortement recommandé d'écrire de la façon suivante si vous avez des variables à afficher : echo 'Cher ',$username,', vous êtes bien inscrit à la KiwiParty !'

Optimisation du code source -> Petit Jeu Exemple (4) Que faut-il préféré entre ces 2 codes ( C'est valable pour tous les langages ) ? $tab = array('1','2','3') ; for($cur = count($tab) ; $cur >=0 ; $cur--) { } OU $nbEltTab = count($tab) ; for($cur = $nbEltTab ; $cur >=0 ; $cur--) { } Réponse : La deuxième écriture Pourquoi ? La première fonction va inutilement faire appel à la fonction count à chaque itération de la boucle for, ce qui fait que l'on consomme des ressources pour rien et que l'on ralentit tout ... Conclusion : certainement de la fainéantise ou bien de l'étourderie de la part des développeurs

Optimisation du code source -> Conseils
Effectuer des benchmarks sur des valeurs grandes ou bien utiliser des résultats de benchmarks déjà existants
Utiliser toujours la meilleure fonction possible (regarder les spécificités de chacune, pour PHP -> regarder dans le code source , utiliser des outils comme Xdebug pour profiler votre code)
Pas de petites économies : une application utilise avant tout du temps CPU et de la mémoire, il faut les préserver au maximum car avec la même allocation, vous pouvez accueillir plus de monde sans rien changer d'autre que votre code (toujours penser à l'effet d'échelle et de façon pérenne)
Libérer de la mémoire là où c'est possible ( gros tableaux, ressources utilisées par MySQL ) -> devient absolument utile si on utilise PHP-FPM ou en CGI
Utiliser la base de données uniquement quand c'est réellement nécessaire ( pas de mysql_connect dans toutes les pages alors que cela ne sert pas dans la page appelée )
Attention aux ORM : ils ne produisent pas forcément les meilleures requêtes SQL, il faut s'en servir pour les requêtes simples ( SELECT ) ou bien pour les INSERT mais pas pour les requêtes complexes : les résultats sont assez décevants ( vu avec Java dernièrement, temps execution de 30 secondes avec ORM Java, requête construite à la main : 0,04 s )

Dans le même ordre que les ORM : il vaut mieux envoyer une grosse requête MySQL plutôt que plusieurs -> les SELECT dans une boucle sont à bannir. On peut utiliser SELECT IN et passer les valeurs, MySQL nous retournera une liste de résultats que l'on stockera dans un tableau, que l'on pourra en plus mettre en cache et que l'on parcourra Il ne faudra pas oublier de libérer la mémoire consommée par le tableau et les résultats retournés par MySQL
Dès que l'on a fini d'utiliser une connexion à la base de données, on la ferme le plus tôt possible -> on libère des requêtes pour d'autres clients, on vide les buffers et on attend pas que PHP par exemple le fasse à la fin de la page ( économie de RAM, libération d'un socket ...)
Ne pas hésiter à utiliser le cache de requêtes de MySQL si vous savez que le résultat ne change que très peu mais le mieux est d'utiliser un cache local de résultats -> on utilise pas de socket, on évite l'utilisation du protocole TCP, éventuellement la résolution inverse faite sur l'adresse IP si le serveur MySQL est mal configuré. Le résultat est directement récupéré sur le cache local.
On peut envisager d'utiliser le cache de requêtes MySQL sur plusieurs sites consultant la même base de données ( API ou directement par une connexion à la base )
Utiliser un maximum de cache local ( Memcache / Redis, Fichiers via tmpfs ou cache dans APC ) : le mieux est d'utiliser Zend_Cache. Si vous avez besoin de stocker des données de type tableaux, il faut les serializer : le mieux est d'utiliser igbinary qui est une extension permettant des les serializer plus rapidement et au format binaire

Il faut utiliser du cache à plusieurs niveaux. Vous avez besoin de construire une requêtes dynamique en SQL pour afficher une liste de résultats. Une des premières choses que l'on peut faire est de stocker en cache la requête et aussi stocker en cache la liste de résultats.
Appel à des WebServices Externes : les appels à des webservices externes doivent le plus possible être mis à part de votre code qui affiche vos pages Web. Vous devez faire des scripts qui tournent en tâche de fond ou des crons qui iront récupérer les résultats et les stocker là où vous en avez besoin
On ne surcharge par le serveur du WebService pour rien
Chaque requête d'un visiteur de votre site internet va appeler une requête sur le serveur distant, surtout si vous ne mettez aucun mécanisme de cache
Vous sur-consommez en bande passante

Optimisation de WordPress
Quels plugins ?
WP SuperCache -> plugin qui permet de générer les pages de votre blog en pages statiques permettant ainsi d'éviter du traitement inutile
WP Minify -> permet de compresser vos fichiers CSS et Javascripts. Il permet aussi de les regrouper en un seul et même fichier
Quelle architecture technique ?
Reverse proxy avec Nginx et Apache pour le PHP. Le reverse proxy va directement aller chercher les pages statiques si elles existent
Memcache pour les sessions
PHP-APC pour diminuer la charge
Utilisation du Worker MPM avec PHP5 en CGI
Mise en place du cache côté navigateur ( cache des images )

Fin de la présentation ! Des Questions ?

Kiwiparty 2011 - Optimisation des sites internet

by Devclic on Apr 04, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 102

Statistics

Kiwiparty 2011 - Optimisation des sites internet — Presentation Transcript

http://www.developpez.net	100
http://twitter.com	2