Parce que l’hébergeur ne traite qu’une partie de la problématique et la vraie réponse passe par un travail commun avec les équipes développements, voici un petit rappel (2 ans déjà!) des équipes de Yahoo à garder en tête…
Le forum PHP s’est déroulé le 12 et 13 Novembre à la Cité des Sciences et de l’Industrie de Paris. Nous nous y sommes rendus le 12 pour rencontrer le petit et grand monde de la communauté PHP.
L’avenir de LAMP
De nombreux acteurs étaient présents lors de ce forum. La conférence sur l’avenir de LAMP et les nouvelles briques architecturalesconfirme l’émergence de solutions capables de prendre en compte des traitements toujours plus complexes. Ces solutions, à destination de sites à fort trafic, sont considérées comme un des premiers pas vers la scalabilité. Pour n’en citer que quelques unes :Gearman, Couchdb, Hadoop, Map reduce… autant de références que nous invitons les développeurs à y jeter un coup d’œil. Nous serons contents de les accompagner pour mettre en œuvre ces technologies.
MySQLnd
Autre conférence faisant partie du programme de la journée lemug : MySQL native driver for PHP : Les améliorations de la stack. La conférence animée par Serge Frezefond (directeur technique de MySQL France) a été l’occasion pour Sun de nous présenter le nouveau driver MySQLnd pour php. Même si celui-ci n’a pas été annoncé pour offrir plus de performance, il gère bien mieux sa mémoire (donc plus de perf 
). Il impacte aucunement le développement et vient rationaliser les couches de drivers déjà existantes.
Sun en a profité pour nous présenter le MySQL Enterprise Monitor, outil mis à la disposition des développeurs et administrateurs pour surveiller et optimiser le comportement d’un simple serveur ou d’un cluster MySQL.
L’outil Mysql Query Analyzer est vraiment très utile et offre de nombreuses possibilités en terme d’optimisation.
Mais attention, ces outils ont un coût. L’analyzer comme le monitor consomment des ressources sur les serveurs sur lesquels ils sont installés. Il est donc nécessaire de prendre des précautions si vous désirez le mettre en production sur un environnement déjà très surchargé.
Quelques optimisations MySQL
Pour finir, Au secours, ma base de données fait ramer mon application ! organisée à nouveau par LeMug et présentée par Stéphane Combaudon a fait salle comble ! Comme quoi le problème reste récurrent.
Stéphane a expliqué les fondements que tout DBA et plus particulièrement les développeurs PHP devraient connaître pour optimiser ses requêtes et ses schémas. Des exemples concrets, l’utilisation d’index réfléchie et la compréhension d’Explain montre que MySQL peut être très bien exploité pour de résultats performants.
Nous n’avons malheureusement pas pu participer à la journée de vendredi mais félicitation à l’AFUP pour cette belle organisation et à tous ses intervenants. Vivement l’année prochaine pour les 15 ans de PHP et 10 ans de l’AFUP.
Yahoo! annonce la distribution en open-source de Traffic Server.
L’utilisation d’un serveur de cache augmente fortement la capacité de traitement d’un site Web. Plus l’applicatif est « gourmand » en ressource plus le cache est une solution pour gagner en scalabilité. Nous avons expérimenté plusieurs technologies de type « Reverse Proxy Cache » comme Squid ou Varnish qui ont pour objectif de conserver en mémoire les pages générées par les serveurs applicatifs afin de les resservir plus rapidement.
Yahoo! annonce 35 000 requêtes par seconde avec Traffic Server. On a hâte de tester cela.
AFK Partners ont fait paraitre un liste (parmi tant d’autres) « bonnes pratiques » au niveau de l’évolutivité des logiciels. En voici la traduction avec quelques petites adaptations d’interprétation :
1. Asynchrone - Utilisez des flux asynchrones dès que possible,
2. Cloisonnement – Concevez des « silos » matériel indépendants entre chaque client/projet,
3. Cache - Utilisez les technologies de « cache » sur chaque couche applicative,
4. Monitoring - Evaluez la performance de votre application aussi du point du vue du client,
5. Réplication - Utilisez la réplication pour la reprise en cas de panne mais utilisez aussi ces ressources pour alléger le serveur principal des lectures faites par plusieurs instances applicatives,
6. Sharding - Séparez votre application et vos bases de données par service et/ou client et affectez chaque instance à un « silos » matériel distinct,
7. Utilisez avec parcimonie les possibilités de votre SGBDR – Utiliser les bases de données interactive uniquement comme système de stockage persistent,
8. Déployez prudemment – Déployez votre code, idéalement sur un serveur de qualification, sans rendre indisponible le système complet en cas d’erreur,
9. Tests de charge et de performance – Testez les performances des nouvelles versions avant de les passer en production,
10. Capacity Planning / Connaissez vos limites – Prenez conscience de la puissance encore disponible sur chaque élément de votre infrastructure,
11. Rollback – Gardez toujours la possibilité de retourner à une version antérieure,
12. Analyse des avaries – Ne pas soigner les symptômes, mais les causes des problèmes,
13. Qualité – On ne rajoute pas la qualité à postériori, elle fait partie des bases.
Un contenu distribué, MySQL utilisé juste pour des tables contenants des couples entrées valeurs, un memcache « énorme » rempli des données les plus souvent consultées, etc.
Cette présentation est un bon exemple de design appli/archi poussé à l’extrême (mais nécessaire).
Ca se passe sur infoQ, ça dure une heure et c’est en anglais.
Oxalide était sponsor du Railscamp de Paris. A cette occasion, en tant qu’infogérant / hébergeur, nous avons partagé notre retour sur expérience sur Capistrano.
On a fait une petite présentation qui synthétise en quelques slides les enjeux, les contraintes et les apports d’un déploiement d’une application PHP avec Capistrano.
Traduction d’un agrégat d’un thread de yCombinator par Tod Hoff.
Ces règles ne sont en aucun cas exhaustives. Elles doivent jouer le rôle de « muses » pour les développeurs pour permettre lors du design de l’architecture de très facilement mettre en oeuvre les possibilités de répartition et de scalabilité.