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...
Qui est Devclic ? - Fondée en 2004 (SARL depuis 2005) - Hébergeur de sites internet / Opérateur Internet / Consulting <ul>...
Opérateur internet déclaré au RIPE : ADSL, SDSL, Fibre Optique, Transit IP
Consulting en création de sites internet / Développement spécifique </li></ul></ul>- Editeur de sites internet <ul><ul><li...
150 Serveurs en propre (Virtuels et Physiques) </li></ul></ul>- Références :  <ul><ul><li>Jetelecharge / Zebest-3000 / Vid...
Des nouveaux à venir : ... vous ? </li></ul></ul>- Twitter : @devclic - Email :  [email_address] - Site internet : non men...
L'Optimisation des sites internet Ma définition :  C'est le fait de gagner partout on l'on peut des « ms » afin de faire  ...
Sur la bande passante
Sur les machines </li></ul></ul><li>De rentabiliser au maximum son site internet et son activité </li><ul><ul><li>Plus de ...
Plus de transformation
Plus de fidélisation </li></ul></ul><li>De supporter plus de trafic pour un investissement très bas voir néant </li><ul><u...
D'améliorer la disponibilité de son site internet
D'afficher que votre site internet est « vert » (« green ») </li></ul></ul>
Pourquoi ne pas optimiser ? <ul><li>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 …)  </li></ul>
L'importance du temps de chargement Des résultats de mesures effectuées :  <ul><ul><li>Google : Chargement + 500 ms donne ...
Yahoo : Chargement +400 ms donne un abandon de 5 à 9 %
Bing : Chargement : +1 s donne 2,8 % de perte en publicité </li></ul></ul>Impacts :  <ul><ul><ul><ul><li>Chiffre d'affaire...
Internautes cherchant d'autres sites internet (manque de temps général)
Coûts d'exploitation augmentés </li></ul></ul></ul></ul>
Exemples concrets de non optimisation <ul><li>Jetelecharge </li><ul><ul><ul><li>Utilisation d'un script tout fait et mal d...
Manque de savoir-faire dans les architectures Web
Manque de savoir-faire dans l'optimisation des sites internet </li></ul></ul></ul></ul><ul><li>Facebook  </li><ul><ul><li>...
Exemple concret d'optimisation JeTelecharge ( Lexgo Network EURL ) : En 2002 :  <ul><ul><ul><ul><ul><ul><ul><li>Création d...
Peu de visiteurs </li></ul></ul></ul></ul></ul></ul></ul>En 2003 : <ul><ul><ul><ul><ul><ul><ul><li>1000 à 4000 visiteurs /...
Plantage régulier du serveur -> Administrateur Système pas content :-)
Webmaster pas content non plus ( manque de Chiffre d'Affaires ) et perte de visiteurs </li></ul></ul></ul></ul></ul></ul><...
-> Plus de problème de charge
-> Le site accueille sans problème plus de visiteurs </li></ul></ul></ul></ul></ul></ul></ul>En 2011 : <ul><ul><ul><ul><ul...
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 me...
Côté Serveur </li></ul></ul></ul></ul></ul></ul></ul>->Permet de gagner très simplement de la charge et de diminuer les te...
Optimisation de l'architecture L'architecture est composée de 2 architectures liées :  <ul><ul><ul><ul><ul><ul><ul><ul><ul...
Prochain SlideShare
Chargement dans…5
×

Kiwiparty 2011 - Optimisation des sites internet

4 334 vues

Publié le

Publié dans : Technologie
2 commentaires
5 j’aime
Statistiques
Remarques
  • Page 33, l’exemple utilisé est mauvais car dans for ($expr1; $expr2; $expr3) {} l’expression $expr1 ne sera évaluée qu’une seule fois, avant tout le reste. Un exemple sur lequel l’optimisation est valable serait :
    for ($cur=0; $cur<count($tab); $cur++) {}

    (Mais avec un tableau cela ne sera pas pertinent pour les langages qui n’ont pas de traitement à effectuer pour obtenir la taille.)
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
  • Oh mon dieu, vous avez vraiment projeté ça ? Allez voir du côté des présentations de Christian Heilmann ou David Larlet...
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
Aucun téléchargement
Vues
Nombre de vues
4 334
Sur SlideShare
0
Issues des intégrations
0
Intégrations
256
Actions
Partages
0
Téléchargements
0
Commentaires
2
J’aime
5
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Kiwiparty 2011 - Optimisation des sites internet

  1. 1. Optimisation des sites internet Lilian RIGARD
  2. 2. 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]
  3. 3. Qui est Devclic ? - Fondée en 2004 (SARL depuis 2005) - Hébergeur de sites internet / Opérateur Internet / Consulting <ul><ul><li>Hébergement mutualisé / dédié / infogéré et de sites internet à fort trafic
  4. 4. Opérateur internet déclaré au RIPE : ADSL, SDSL, Fibre Optique, Transit IP
  5. 5. Consulting en création de sites internet / Développement spécifique </li></ul></ul>- Editeur de sites internet <ul><ul><li>Blog du High-Tech / NDFR / MeilleursPrix / Forum-Webmaster </li></ul></ul>- Infrastructure : <ul><ul><li>Présence dans 3 Datacenters (2 à Strasbourg, 1 à Paris)
  6. 6. 150 Serveurs en propre (Virtuels et Physiques) </li></ul></ul>- Références : <ul><ul><li>Jetelecharge / Zebest-3000 / Videoavolonte / FC Metz / Les-Horaires / Fysiki / Direct FM
  7. 7. Des nouveaux à venir : ... vous ? </li></ul></ul>- Twitter : @devclic - Email : [email_address] - Site internet : non mentionnable … :-)
  8. 8. 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 : <ul><ul><li>De faire des économies </li><ul><ul><li>Sur l'hébergement
  9. 9. Sur la bande passante
  10. 10. Sur les machines </li></ul></ul><li>De rentabiliser au maximum son site internet et son activité </li><ul><ul><li>Plus de revenus PUB
  11. 11. Plus de transformation
  12. 12. Plus de fidélisation </li></ul></ul><li>De supporter plus de trafic pour un investissement très bas voir néant </li><ul><ul><li>Le développeur doit faire correctement son travail </li></ul></ul><li>D'être mieux référencé (Google)
  13. 13. D'améliorer la disponibilité de son site internet
  14. 14. D'afficher que votre site internet est « vert » (« green ») </li></ul></ul>
  15. 15. Pourquoi ne pas optimiser ? <ul><li>Manque de compétences en interne
  16. 16. Méthode Microsoft : je rachète des plus gros serveurs ou j'en mets plus
  17. 17. Manque de temps
  18. 18. Fainéantise
  19. 19. Y trouver aucun intérêt (enfin jusqu'à aujourd'hui …) </li></ul>
  20. 20. L'importance du temps de chargement Des résultats de mesures effectuées : <ul><ul><li>Google : Chargement + 500 ms donne 20 % de trafic en moins
  21. 21. Yahoo : Chargement +400 ms donne un abandon de 5 à 9 %
  22. 22. Bing : Chargement : +1 s donne 2,8 % de perte en publicité </li></ul></ul>Impacts : <ul><ul><ul><ul><li>Chiffre d'affaires en moins
  23. 23. Internautes cherchant d'autres sites internet (manque de temps général)
  24. 24. Coûts d'exploitation augmentés </li></ul></ul></ul></ul>
  25. 25. Exemples concrets de non optimisation <ul><li>Jetelecharge </li><ul><ul><ul><li>Utilisation d'un script tout fait et mal développé </li></ul></ul></ul></ul><ul><li>France.fr </li><ul><ul><ul><li>Manque de savoir faire dans l'intégration et l'utilisation de Drupal
  26. 26. Manque de savoir-faire dans les architectures Web
  27. 27. Manque de savoir-faire dans l'optimisation des sites internet </li></ul></ul></ul></ul><ul><li>Facebook </li><ul><ul><li>Manque de connaissance au démarrage du projet </li></ul></ul></ul>
  28. 28. Exemple concret d'optimisation JeTelecharge ( Lexgo Network EURL ) : En 2002 : <ul><ul><ul><ul><ul><ul><ul><li>Création du site internet avec l'utilisation d'un script déjà tout fait
  29. 29. Peu de visiteurs </li></ul></ul></ul></ul></ul></ul></ul>En 2003 : <ul><ul><ul><ul><ul><ul><ul><li>1000 à 4000 visiteurs / jour
  30. 30. Plantage régulier du serveur -> Administrateur Système pas content :-)
  31. 31. Webmaster pas content non plus ( manque de Chiffre d'Affaires ) et perte de visiteurs </li></ul></ul></ul></ul></ul></ul></ul>En 2004 : <ul><ul><ul><ul><ul><ul><ul><li>Intervention Devclic : création d'un nouveau script avec reprise de la base de données de l'ancien
  32. 32. -> Plus de problème de charge
  33. 33. -> Le site accueille sans problème plus de visiteurs </li></ul></ul></ul></ul></ul></ul></ul>En 2011 : <ul><ul><ul><ul><ul><ul><ul><li>50 à 60 000 visiteurs uniques / jour
  34. 34. 167 000 € de CA pour l'année 2010 (source societe.com)
  35. 35. 4 ou 5 sites sur le même modèle de script avec des améliorations de la part du Webmaster ( ancien stagiaire Devclic :-) ) </li></ul></ul></ul></ul></ul></ul></ul>
  36. 36. 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 <ul><ul><ul><ul><ul><ul><ul><li>Côté Utilisateur
  37. 37. Côté Serveur </li></ul></ul></ul></ul></ul></ul></ul>->Permet de gagner très simplement de la charge et de diminuer les temps de réponse ( modification du code )
  38. 38. Optimisation de l'architecture L'architecture est composée de 2 architectures liées : <ul><ul><ul><ul><ul><ul><ul><ul><ul><ul><li>L'architecture logicielle (votre application et toutes les applications permettant son fonctionnement)
  39. 39. L'architecture matérielle </li></ul></ul></ul></ul></ul></ul></ul></ul></ul></ul>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
  40. 40. Optimisation de l'architecture Changer de serveur Web, faire un choix entre : <ul><ul><ul><ul><ul><ul><ul><ul><ul><ul><li>Apache
  41. 41. Nginx
  42. 42. Cherokee
  43. 43. Lighttpd </li></ul></ul></ul></ul></ul></ul></ul></ul></ul></ul>Lequel choisir ? <ul><ul><ul><ul><ul><ul><ul><ul><ul><ul><li>Apache pour PHP
  44. 44. Nginx, Cherokee, Lighttpd pour les fichiers statiques </li></ul></ul></ul></ul></ul></ul></ul></ul></ul></ul>Pourquoi ? <ul><ul><ul><ul><ul><ul><ul><ul><ul><ul><li>Garder la flexibilité d'Apache ( .htaccess et certains autres modules utiles )
  45. 45. Limiter l'utilisation de la RAM ( Apache gère très mal les fichiers statiques)
  46. 46. Profiter de la puissance des serveurs alternatifs : moins gourmands, plus résistants
  47. 47. Possibilité d'utiliser les serveurs alternatifs comme Reverse Proxy Cache </li></ul></ul></ul></ul></ul></ul></ul></ul></ul></ul>Impacts    : Aucun, que du plus :-), il faut juste de la configuration
  48. 48. Optimisation de l'architecture Mettre un reverse proxy devant votre cluster Apache avec au choix : <ul><ul><ul><ul><ul><ul><ul><ul><ul><ul><li>Varnish
  49. 49. Squid </li></ul></ul></ul></ul></ul></ul></ul></ul></ul></ul>Lequel choisir ? <ul><ul><ul><ul><ul><ul><ul><ul><ul><ul><li>Cela dépend des affinités, il y a des plus et des moins dans chacun </li></ul></ul></ul></ul></ul></ul></ul></ul></ul></ul>Pourquoi ? <ul><ul><ul><ul><ul><ul><ul><ul><ul><ul><li>Garder la flexibilité d'Apache ( .htaccess et certains autres modules utiles )
  50. 50. Limiter l'utilisation de la RAM ( Apache gère très mal les fichiers statiques)
  51. 51. On stocke les images en RAM sur le Reverse Proxy
  52. 52. Les reverses proxys peuvent s'échanger les fichiers directement entre eux </li></ul></ul></ul></ul></ul></ul></ul></ul></ul></ul>Impacts    : Aucun, que du plus :-) sauf 1 cas : l'authentification Basic qui ne fonctionnait pas correctement
  53. 53. Optimisation de l'architecture Optimiser Apache <ul><li>Décharger les modules inutiles
  54. 54. Adapter les paramètres </li><ul><ul><ul><ul><ul><ul><ul><ul><ul><li>- MaxClient / StartServer
  55. 55. - Timeout
  56. 56. - MinSpareServers / MaxSpareServer
  57. 57. - HostnameLookups Off
  58. 58. - MaxRequestsPerChild </li></ul></ul></ul></ul></ul></ul></ul></ul></ul><li>Bien régler le cache client à l'aide de mod_expires </li></ul><IfModule mod_expires.c> ExpiresActive On <FilesMatch &quot;.(ico|pdf|flv|swf)$&quot;> ExpiresDefault &quot;access plus 1 weeks&quot; </FilesMatch> ExpiresByType text/css &quot;access 1 weeks&quot; ExpiresByType text/javascript &quot;access 1 weeks&quot; ExpiresByType application/x-javascript &quot;access 1 weeks&quot; ExpiresByType application/javascript &quot;access 1 weeks&quot; ExpiresByType image/gif &quot;access 1 months&quot; ExpiresByType image/jpeg &quot;access 1 months&quot; ExpiresByType image/png &quot;access 1 months&quot; </IfModule>
  59. 59. Optimisation de l'architecture Optimiser Apache <ul><li>Activer la compression des pages via mod_deflate ou bien alors donner cette tâche à Nginx </li></ul><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>
  60. 60. Optimisation de l'architecture Optimiser Apache <ul><li>Activer les etags
  61. 61. Changer le mode de fonctionnement d'Apache ( MPM Worker vs MPM Prefork ). </li></ul>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.
  62. 62. Optimisation de l'architecture Optimiser Apache <ul><li>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. </li></ul><ul><li>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 </li></ul>
  63. 63. Optimisation de l'architecture Optimiser PHP <ul><li>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 </li></ul><ul><li>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 </li></ul><ul><li>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. </li><ul><ul><ul><ul><ul><ul><ul><ul><ul><li>- Ajout du support de PHAR ( l'équivalent des .jar de java )
  64. 64. - Meilleur support de l'objet
  65. 65. - Apport de PHP FPM
  66. 66. - Nouveau module de communication avec MySQL </li></ul></ul></ul></ul></ul></ul></ul></ul></ul></ul>
  67. 67. Optimisation de l'architecture Choisir des alternatives à MySQL <ul><li>Utiliser du stockage orienté document ( MongoDB ) : plus rapide que MySQL, supporte les transactions et les propriétés ACID </li><ul><ul><ul><ul><ul><ul><ul><ul><li>- permet de stocker très facilement un article et des commentaires liés à cette article -> représentation sous forme de tableau </li></ul></ul></ul></ul></ul></ul></ul></ul></ul>Exemple : <ul><ul><ul><ul><ul><ul><ul><ul><ul><li>$article = { 'title' => 'KiwiParty', </li></ul></ul></ul></ul></ul></ul></ul></ul></ul> '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 <ul><li>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 </li></ul>
  68. 68. Optimisation de l'architecture Choisir des alternatives à MySQL <ul><li>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 )
  69. 69. Utiliser un autre SGBD : </li><ul><ul><ul><ul><ul><ul><li>Maria DB qui se base sur MySQL mais qui profite d'améliorations de la part du créateur de MySQL
  70. 70. SQLite en memory ou bien sur un TMPFS ( RAMDISK ) </li></ul></ul></ul></ul></ul></ul></ul>
  71. 71. Optimisation de l'architecture Optimiser MySQL <ul><li>Bien choisir le format de vos tables MySQL ( Innodb vs MyISAM ) </li><ul><ul><ul><ul><ul><ul><li>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 )
  72. 72. InnoDB supporte les transactions mais est moins performante ( verrouillage de la ligne ) </li></ul></ul></ul></ul></ul></ul></ul>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 <ul><li>Partir sur de la répartition de charge MySQL via du Master / Slave </li><ul><ul><ul><ul><ul><ul><li>Ne jamais utiliser du MySQL Cluster ( données stockées en RAM, risque de grosse perte si un node se coupe )
  73. 73. 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 </li></ul></ul></ul></ul></ul></ul></ul>
  74. 74. Optimisation de l'architecture Optimiser MySQL <ul><li>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
  75. 75. 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)
  76. 76. 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 </li></ul>
  77. 77. Optimisation de l'architecture Optimiser Memcache <ul><li>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 ... </li></ul>
  78. 78. 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
  79. 79. 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 : <ul><ul><ul><ul><ul><ul><ul><ul><ul><ul><li>On sait très bien ce que contient chaque release du Kernel Linux alors que pour Windows c'est plutôt obscure
  80. 80. Peu ou pas de tuning possible avec Windows </li></ul></ul></ul></ul></ul></ul></ul></ul></ul></ul>Choisir Linux pour ces serveurs : <ul><ul><ul><ul><ul><ul><ul><ul><ul><ul><li>Avoir accès à des paramètres qui peuvent faire gagner en performance
  81. 81. Activer le KSM (Kernel 2.6.32) -> déduplication mémoire
  82. 82. Transmit Packet Steering de Google ( amélioration du transfert des paquets réseaux )
  83. 83. Transparent Hugepages (THP) (Kernel 2.6.38) -> réduction du nombres d'allocations mémoires nécessaires et donc augmentation des performances
  84. 84. Mettre le noatime sur ses partitions pour diminuer la charge des I/O
  85. 85. Pouvoir monter des RAMDISK ou du TMPFS (TMPFS est autorisé à utiliser la SWAP à l'instar de RAMFS) </li></ul></ul></ul></ul></ul></ul></ul></ul></ul></ul>
  86. 86. Optimisation de l'architecture Optimisation de l'architecture matérielle Virtualisation au maximum : <ul><ul><ul><ul><ul><ul><ul><ul><ul><ul><li>Diminuer les coûts de production en utilisant moins de machines et en les utilisant le mieux possible
  87. 87. Activation de KSM qui permettra d'économiser sur la mémoire, moins de RAM utilisée
  88. 88. Allocation dynamique de la mémoire : pour une ressource donnée, je vais pouvoir l'autoriser à utiliser des Pics
  89. 89. Amélioration du rendement de l'infrastructure : moins d'alimentation puisque moins de serveurs, moins de chaleur dégagée </li></ul></ul></ul></ul></ul></ul></ul></ul></ul></ul>Développement orienté cluster : <ul><ul><ul><ul><ul><ul><ul><ul><ul><ul><li>Multiplication des petites machines ( moins performantes ) vs une grosse machine -> gain énergétique
  90. 90. Beaucoup plus scalable </li></ul></ul></ul></ul></ul></ul></ul></ul></ul></ul>
  91. 91. Optimisation côté Utilisateur Moins de code pour obtenir le même rendu <ul><ul><ul><ul><ul><ul><ul><ul><ul><ul><li>Des div imbriqués dans d'autres div
  92. 92. Utiliser un simple <a href=&quot;/&quot; class=&quot;logo&quot;>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é )
  93. 93. 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 </li></ul></ul></ul></ul></ul></ul></ul></ul></ul></ul>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 <ul><ul><ul><ul><ul><ul><ul><ul><ul><ul><li>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() )
  94. 94. Réduit également la taille du fichier par la suppression des commentaires et espaces inutiles </li></ul></ul></ul></ul></ul></ul></ul></ul></ul></ul>
  95. 95. Optimisation côté Utilisateur <ul><li>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 ) </li></ul><ul><li>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 ... </li></ul><ul><li>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 :-) </li></ul>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. <ul><li>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) </li></ul><ul><li>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 </li></ul>
  96. 96. <ul><li>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 </li><ul><ul><ul><ul><ul><ul><ul><ul><ul><li>Le navigateur va directement récupérer le fichier dans son cache et va l'executer
  97. 97. Vous faîtes des économies de bande passante
  98. 98. Tous les utilisateurs consultant votre site internet s'implique dans la politique « green » </li></ul></ul></ul></ul></ul></ul></ul></ul></ul></ul><ul><li>Eviter d'utiliser des Frameworks Javascript quand c'est inutile ( le bon vieux code JavaScript peut très bien le faire ) </li></ul><ul><li>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 </li></ul><ul><li>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) </li></ul><ul><li>Passer vos images à Smushit : il se fera un plaisir de supprimer les META DONNEES inutiles </li></ul>Optimisation côté Utilisateur
  99. 99. Comment y arriver ? <ul><li>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
  100. 100. Utiliser un site comme GTMetrix qui regroupe ces 2 barres sur un seul et même site, cela permet aussi d'avoir un historique
  101. 101. 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
  102. 102. Pour l'utilisation du CDN Google, voir ici ( http://code.google.com/intl/fr-FR/apis/libraries/ )
  103. 103. Pour optimiser vos images, il suffit de les envoyer à Smushit ( http://www.smushit.com/ysmush.it/ ), il y en a d'autres qui existent </li></ul>Optimisation côté Utilisateur
  104. 104. 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)
  105. 105. 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
  106. 106. 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 &quot; KiwiParty &quot;   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 !'
  107. 107. 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
  108. 108. Optimisation du code source -> Conseils <ul><li>Effectuer des benchmarks sur des valeurs grandes ou bien utiliser des résultats de benchmarks déjà existants </li></ul><ul><li>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) </li></ul><ul><li>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) </li></ul><ul><li>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 </li></ul><ul><li>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 ) </li></ul><ul><li>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 ) </li></ul>
  109. 109. Optimisation du code source -> Conseils <ul><li>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
  110. 110. 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 ...)
  111. 111. 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. </li></ul>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 ) <ul><li>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 </li></ul>
  112. 112. Optimisation du code source -> Conseils <ul><li>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.
  113. 113. 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 </li><ul><ul><ul><ul><ul><ul><ul><ul><ul><li>On ne surcharge par le serveur du WebService pour rien
  114. 114. 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
  115. 115. Vous sur-consommez en bande passante </li></ul></ul></ul></ul></ul></ul></ul></ul></ul></ul>
  116. 116. Optimisation de WordPress <ul><li>Quels plugins ? </li></ul><ul><ul><ul><ul><ul><ul><ul><ul><ul><ul><li>WP SuperCache -> plugin qui permet de générer les pages de votre blog en pages statiques permettant ainsi d'éviter du traitement inutile
  117. 117. WP Minify -> permet de compresser vos fichiers CSS et Javascripts. Il permet aussi de les regrouper en un seul et même fichier </li></ul></ul></ul></ul></ul></ul></ul></ul></ul><li>Quelle architecture technique ? </li></ul><ul><ul><ul><ul><ul><ul><ul><ul><ul><ul><li>Reverse proxy avec Nginx et Apache pour le PHP. Le reverse proxy va directement aller chercher les pages statiques si elles existent
  118. 118. Memcache pour les sessions
  119. 119. PHP-APC pour diminuer la charge
  120. 120. Utilisation du Worker MPM avec PHP5 en CGI
  121. 121. Mise en place du cache côté navigateur ( cache des images ) </li></ul></ul></ul></ul></ul></ul></ul></ul></ul></ul>
  122. 122. Fin de la présentation ! Des Questions ?

×