Archives pour la catégorie Performance

Un nouveau reverse proxy cache

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.

13 bonnes pratiques pour garantir la scalabilité

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.

L’architecture Facebook expliquée

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.

Hébergeur Magento

Magento Hosting Gold PartnerOxalide est maintenant « Gold Partner » Magento. Qu’est ce que ça veut dire? Et bien outre le fait d’être dans les petits papiers de Varien, nous développons l’expertise autour de cette solution e-commerce comme nous avons déjà été amené à le faire avec Prestashop.

Cette solution e-commerce qui a le vend en poupe qui malgré sa jeunesse offre (presque) toutes les possibilités d’une boutique e-commerce de rêve. Attention en revanche à la montée en charge car en cas de succès de la boutique, il faut garantir la performance de sa boutique et rester disponible au moment de la plus forte affluence. Justement, on aime ce genre de défis ! :)

« Nous avons appris une chose : choisir un bon hébergeur, du bon matériel et un bon administrateur DB est excessivement important »

Ces propos sont tenus par Siqi Chen and Alexander Le les main développeurs du module friends sale pour facebook dans la présentation de leur architecture. L’applicatif traite plus de 300 millions de pages vues mensuelles. Ce trafic s’est constitué en moins de 3 mois.

Le service a été initialement lancé sur un hébergeur « low-cost » permettant de lancer facilement le service mais qui a très vite montré ses limites.

Quelque soit le nombre de parts allouées initialement, le service a subi de nombreuses interruptions et ce malgré les ressources spécifiques allouées par l’hébergeur. La réponse n’est donc pas systématiquement : augmentation linéaire de ressources.

La démarche a été celle de la professionalisation : le design de l’architecture par des personnes expérimentées, la sélection d’un matériel sur-mesure et une infrastructure réseau de qualité avec une section privatisée.

« Nous aurions définitivement dû migrer chez un meilleur hébergeur plutôt dans la partie so we would have been up. »

« Je pense que le travail à distance ou outsourcing sont compliqués : je préfère éviter ce type de scénario. Pour l’administration système ou l’optimisation de la BDD cela a plus de sens. »

Trop souvent, les équipes projets attendent que ca casse avant de prendre les mesures nécessaires. Les compétences nécessaires sont pointues et l’expérience est une valeure chère dans ce domaine.

Dommage de constater que souvent le motif pour « Travailler » sur son infrastructure est la rupture de services. Fort heureusement, les développeurs ont été très bien accompagnés par un tiers pour mettre en place l’architecture.