Communautés iWeb: Blog

Si vous parcourez les guides et les billets publiés sur le blogue de iWeb durant les 3 derniers mois, vous pourrez voir beaucoup d’articles sur comment mettre en place un site, comment choisir un serveur dédié, comment transférer un site web sur un nouveau hébergeur etc.

Jusqu’à présent, il n’y a pas eu d’articles avancés qui traitent des architectures plus complexes ou des conseils sur comment gérer la croissance d’un site web. La raison est simple: par expérience, c’est mieux de lancer d’abord le site web, d’avoir les premiers usagers, et alors optimiser quand des goulots d’étranglements et des problèmes de performance surviennent. La plupart des équipes de développement suivent ce principe; autrement, ils feraient de l’optimisation prématurée, et aussi dû au fait que chaque site web a différents besoins et donc différents problèmes techniques à résoudre.

Vous pouvez voir par exemple le graphique suivant pour le chargement de la page d’accueil de delicious:

Cela a pris 1.85 sec pour afficher le site, sachant que d’autres sites comme flickr.com visent des temps de chargement totaux de 250 ms. Le graphique d’en haut montrent que la réponse http du serveur a pris 1.3 sec, ce qui est quasiment 2/3 du temps total. Cela signifie que c’est soit le serveur DNS, ou tout simplement les serveurs de delicious qui doivent traiter trop de trafic, et donc étaient de train de mettre peut-être la requête dans une file d’attente.

Voici un graphique pour un autre site web (TechEntreprise):

Le temps de réponse est similaire à delicious, en 1.83sec, cependant c’est une réponse opposée par rapport à delicious: la réponse du serveur est en moins de 100ms, mais les fichiers statiques comme les fichiers, le css, ou le javascript prennent le reste du temps. L’envoi de fichiers statiques doit donc être optimisé sur ce site, en utilisant la compression, en essayant d’utiliser moins de fichiers statiques, ou d’utiliser des solutions d’hébergement avancées pour rendre le site plus rapide.

Lors de la durée de vie d’un site, une équipe de développement doivent donc surveiller ces données; et optimiser à chaque itération, à chaque fois sur un goulot d’étranglement différent. Le problème peut arriver dans:

1. Les serveurs DNS
2. La capacité des serveurs d’entrée
3. La vitesse et la capacité des serveurs d’application
4. La performance des serveurs de base de données
5. Les serveurs de fichiers statiques

1. Serveurs DNS

Quand un nouveau usager veut visiter un site qui n’a pas été visité récemment, il doit y avoir d’abord une requête DNS. Les requêtes DNS peuvent être signifiants si le visiteur est sur un autre continent ou si vous avez des serveurs DNS lents. Learnhub, un site web réalisé par une compagnie Torontoise, voyait par exemple que le temps de réponse DNS pouvait prendre jusqu’à 500ms, et ils ont donc opté pour Dynect pour avoir un service ultra-rapide de DNS. Le graphique suivant montre les améliorations quand ils ont fait le changement:

Le temps de réponse est maintenant 3 fois moindre pour Learnhub, une amélioration importante pour tous ses usagers en Asie du Sud-Est.

2. Capacité des Serveurs d’Entrée

Ces serveurs sont les premiers à traiter votre requête, à les mettre dans une file d’attente, et ensuite les distribuer au serveur approprié, comme un serveur d’application, le cache (ou memcached). Ces serveurs peuvent être des programmes spécialisés (comme haproxy ou nginx, qui ont des fonctionnalités de répartition de charge integrées) ou cela peut être aussi des machine faites pour la répartition de charges. Dans d’autres sites web, Apache ou le serveur web peut être le serveur d’entrée et à la fois le serveur d’application.

Dans la plupart des architectures web, le goulot d’étranglement est rarement à ce niveau. Si c’est le cas, c’est peut-être parce que vous n’avez pas choisi le meilleur algorithme de routage, en choisissant par exemple le round-robin au lieu d’algorithme de route en fonction de la charge. Dans beaucoup de cas, il peut aussi arriver qu’il n’y a pas assez de serveurs d’application, et que les serveurs d’entrée attendent juste que les requêtes soient traités. Voici par exemple comment les temps de réponse changent quand vous rajoutez plus de connections aux serveurs d’application (avec le même répartiteur de charge en front)

C’est un changement significatif, donc améliorer le temps de latence d’un site web peut être juste un changement de configuration.

3. Performance des Serveurs d’Application

Le serveur d’application traite la requête, par exemple en envoyant une page personalisée selon les préférences de l’utilisateur.

Ceci dépend des technologies utilisées par le site web (php, python, java, ruby + et tout autre cadre d’application)

Si le goulout d’étranglement est le serveur d’application, il y a 2 chemins possible: soit optimiser le code de l’application web, ou faire la mise à l’échelle en utilisant plus de serveurs dédiés.

Optimiser le code est au-delà de ce qui est possible pour cet article; ça implique de tester, d’utiliser les meilleurs pratiques, de faire des tests de performance du code, et ensuite de “réusiner” (refactor en anglais) le code pour avoir un meilleur temps de réponse. Cherchez les meilleures ressources pertinents à votre technologie, testez-le, et cherchez de l’aide d’un consultant expérimenté ou d’une équipe de développement.

Si vous avez atteint un mur dans l’optimisation de code, vous pouvez penser à avoir des serveurs plus puissants, et chercher à trouver la meilleure formule de RAM et de CPUs, et utiliser ce serveur modèle pour fiare la mise à l’échelle horizontale. Une solution facile pour des sites web LAMP websites est disponible ici.

Beaucoup de sites web modernes (mettez le mot-clé “web2.0″ ici) ont aussi des fonctionnalités avancées comme des courriels pour usagers et des notifications avancées, le calcul du graphe social, un moteur de recherche, messagerie, des messages textes, traitement de vidéos et d’images, etc. Si vous avez de telles fonctionnalités, un moyen très rapide pour faire diminuer le temps de chargement est d’externaliser ces fonctionnalités à des serveurs dédiés. Vous pouvez par exemple utiliser des serveurs de messagerie comme ActiveMQ, RabbitMQ (un projet Apache) ou même kestrel (celui que Twitter utilise pour traiter le flux de tweets) pour envoyer la charge et les requêtes qui prennent plus de 500ms à des serveurs spécialisés. Faire des requêtes asynchrones permettent en théorie des temps de réponse instantané, donc c’est quelque chose que vous devrez regarder dès que vous avez une architecture avec 3 ou 4 serveurs dédiés.

Utiliser un système de cache est aussi une technique efficace pour traiter les requêtes, pour éviter qu’ils n’atteignent les serveurs d’application. Comme le code d’application, la technologie de système de cache dépend fortement de votre site web.

4. Serveurs de Bases de données

Heureusement, l’optimisation des serveurs de base de données est plus facile que les points précédents

Il y a des solutions connues et testées pour faire augmenter la charge de MySQL, de la réplication à des solutions de maître-esclave, et répartir les charges. Comme les serveurs d’application, vous pouvez chercher le meilleur matériel pour votre serveur, en utilisant des serveurs pro, et avec des disques dur avec des temps de latence minimes. Vous pouvez par exemple voir dans le graphe suivant comment MySQL se comporte pour différents serveurs sous différentes charges, et ensuite planifier en conséquence.

Beaucoup de compagnies web utilisent aussi intensivement memcached avant les serveurs de base de données, pour pouvoir délivrer les objets les plus fréquement demandés de la mémoire.

5. Serveurs de Fichiers

Les serveurs de fichier sont chargés d’envoyer les fichiers statiques, comme les fichiers, les vidéos, les fichiers javascript, et d’autres éléments statiques comme des animations Flash.

Vous pouvez programmer votre application web pour servir moins de fichier (par exemple, mettre tous les fichiers javascripts dans un seul fichier), compresser les fichier (et ensuite g-zipper la réponse).

Optimiser les serveurs de fichiers statiques est probablement le plus facile lorsqu’il s’agit de réduire le temps de réponse d’un site web.