echo « my heart will go on »;
21 octobre 2008 - 12 commentaires
Développer (au sens technique du terme) un service web ressemble à un iceberg: 90% de votre travail est invisible de l’extérieur.
Comme pour n’importe quelle entreprise il faut communiquer, or il n’est pas évident de communiquer sur la partie invisible.
Pourtant, c’est souvent en faisant attention à ce que les choses soient bien faites que l’on arrive à un service de qualité (primordial pour la fidélisation des utilisateurs)
La partie invisible a donc une vraie valeur mais son exploitation sous la forme de communication immédiate est très limitée.
Depuis 9 mois je nous ai imposé un rythme d’une nouveauté « visible » par semaine (chaque mardi)
Étant donné que notre équipe est petite, cela impose que l’un de nous trois bosse uniquement sur ces nouveautés (Thomas en ce moment).
Je ne peux pas passer mon temps sur du développement technique, je ne représente donc pas un tiers de l’équipe technique mais disons 20% (si on prend en compte l’ensemble des problématiques de développement).
Là où cela devient vraiment gênant c’est quand Christophe ET Thomas bossent sur la partie visible (ce qui est le cas en ce moment)
Certains utilisateurs m’ont signalé des ralentissements du service à certaines heures de la soirée, nous allons donc réserver un peu de temps pour faire en sorte que l’équilibre soit rétabli (à nous les joies du profiling).
Je me demande comment cela se passe pour les boites qui ont externalisé leur développement: lorsqu’un site est « victime de son succès » que propose le prestataire, un audit ? un changement de serveur ? Il botte en touche ?
Comments closed
Discussion:
Sans être mauvaise langue, c’est rarement les sites qui ont tout externalisé qui finissent par être victimes de leur succès…
Probable en effet dans le cadre d’un service mais pour un e-commerçant par exemple ?
Ah chic un truc de barbu !
Tu as la bonne démarche: essayer d’optimiser pour ne pas gaspiller des ressources. Maintenant si tu veux mon avis, financièrement je ne suis pas sur que ce soit la meilleure solution. Je vais développer un peu cette idée…
Qu’entends-tu par « victime de son succès » ?
Quand un hébergement mutualisé ne suffit plus ?
Quand un hébergement sur un serveur dédié ne suffit plus ?
Si c’est à ce genre de problème que tu fais référence, alors oui, optimiser pour libérer des ressources permettra de tenir le coup quelques semaines ou quelques mois.
Quand on est sur des projets plus importants, la façon de penser est totalement différente. Clustering, loadbalancing, failover … etc … tu n’y échappes pas, les besoins ne sont pas les mêmes.
Passer d’une architecture simple, un serveur ou deux, à une architecture plus complexe telle que citée plus haut n’est pas une mince affaire, et justement il faut prévoir cela à temps.
A l’heure actuelle, le cout du matériel est inférieur à la main d’œuvre d’un développeur. Lorsque tu es dans une situation avec une architecture complexe de type clustering/loadbalancing, et que tu vois tes ressources commencer à être insuffisantes, tu ajoutes des machines tout simplement …
Je prend l’exemple d’un serveur web; aujourd’hui ajouter un backend à un loadbalancing c’est à la louche 1/2 journée d’install et de config, et 30 secondes pour l’intégrer à ton architecture.
Pour prendre le cas qui t’intéresse ici, les services web, tu peux facilement prévoir et encaisser une augmentation de trafic, sans avoir ton service à plat car trop de requetes en cours.
Un exemple tout simple: un « super service web » voit le jour. Tout doucement, tous les blogs en parlent, le trafic augmente de façon constante.
Un soir TF1 en parle au JT, tu peux être sur que tes services seront à plat pendant plusieurs heures car trop de connexion simultanées.
Dans le cas d’un loadbalancing, tu peux par exemple tabler sur deux backends, plus deux en standby (électriquement éteint). Avec quelques scripts aux petits oignons, tu contrôles la charge de tes deux backends actifs. Lorsque la charge de chacun dépasse un certain seuil, tu peux de façon automatique démarrer les backends en standby, les intégrer au loadbalancing et du coup pendant ce pic de trafic, ton service continue de fonctionner normallement. Lorsque le « buzz » est passé, tu coupes ces backend de secours pour fonctionner normalement, sans consommer de l’électricité inutilement.
On est clairement loin d’un hébergement sur un serveur dédié je te l’accorde.
Donc pour répondre à ta question, de nos jours il est plus facile et « rentable » d’ajouter des machines que d’optimiser son code. Après se posent les questions d’écologie (consommation électrique des machines et des clims, etc …)
Mais ça restera toujours une bonne chose d’optimiser ton code, c’est certain.
Je ne sais pas si tu peux répondre à cette question, mais comment est organisé l’hébergement de Hellotipi actuellement ? Je suis curieux ?
Dans tous les cas, si tu en es à optimiser pour gagner des ressources, tu peux déjà te pencher sur des solutions citées plus haut, par lesquelles tu passeras inévitablement. En tout cas je te le souhaite, ce qui voudrait dire que Hellotipi connait un fort succès !
Par contre, je ne sais pas si tu souhaitais une réponse aussi longue …
Concernant Xdebug c’est un chouette outil (que j’exploite peut être a 2% …), je te conseille également d’activer les notices dans la conf de php sur ton environnement de développement, ça permet de peaufiner, et on y pense pas toujours …
Woops … le pâté !
Désolé
Tuxyroots>heu…
Je suis d’accord avec toi sur le principe du coût du matériel vs coût du travail
Là on a toute une série de petits bugs « non critiques » à corriger dans notre todo list, donc je pense qu’on va faire un filet garni avec de l’optimisation/mise en cache.
Tuxyroots> Fort intéressant ! Il est vrai que pour un gros projet, il n’y a aucun intérêt à optimiser le code en terme de coût. Dans une autre vie, j’ai bossé pour des clients qui planchaient depuis 1 an sur des optimisations de code radicales sans grand succès alors que leurs serveurs avait plus de 4 ans au compteur. Puis un nouveau responsable d’infra est arrivé, il a organisé le renouvellement des serveurs et tout est rentré dans l’ordre pour 1/10eme du coût du dev de l’année écoulée… Sans compter le coût que représente la quantité astronomique de café consommé par ses satanés développeurs
Pourquoi tu ne passes pas certaines parties en open source (parties où tu as peut être utilisé des devs open source que tu as amélioré ?). idem sur les traductions pour capter de nouvelles langues ?
JM> pas forcément si simple mais j’y réfléchis. en revanche pour la traduction je compte bien le faire (mais il faut bien organiser le bousin pour éviter que ça devienne le foutoir)
Problématique intéressante, je pense aussi qu’un bon couple architecture matériel / code est le meilleur moyens d’avoir un rapport temps/cout qui soit optimisé.
Tuxyroots> Le souci c’est quand on passe de 1 à 2 serveurs dédiés à un système avec loadbalancing, il faut avoir les moyens en terme d’argent et de compétences. Pour un PME c’est pas évident que ce soit rentable, sur le court/moyenne terme en tout cas.
Sur le long terme vaut toujours mieux avoir un bonne architecture prête à évoluer rapidement.
Bonjour François,
je me permet de laisser mon premier commentaire sur ton blog que je lis avec fidélité !
Je pense que tu as voulu dire plus haut que le problème est quand tes deux collaborateurs travaillent sur la partie « invisible » plutôt que visible ?
Pour l’optimisation tu as plusieurs solutions rapides et peu couteuses en fonction de la source de ton ralentissement.
Au niveau SQL :
- La première chose est d’optimiser sa configuration pour qu’il cache le mieux et le plus possible. Je ne sais quel base de données tu utilise, mais tu dois également avoir un moyen de forcer le cache du résultat d’une requête en particulier, à toi de cacher en priorité tes requêtes les plus importantes (gourmandes ou redondantes) ;
- Optimiser tes requêtes SQL, ta base de données évolue au fur et à mesure de tes développements, certaines requêtes peuvent surement être ré-optimisées ;
- Éviter les clauses « Order by », cela oblige ton serveur SQL à parcourir l’ensemble des enregistrements et c’est très long !
- Tu peux aussi utiliser la session de tes membres pour mettre en cache quelques informations que tu affiche à chaque page. Pour les mettre à jour tu feras une requête sur une toute petite table de type Heap (chargée totalement en mémoire). Le contenu d’une table stockée en mémoire est perdu si le serveur reboot, mais comme elle n’est jamais stockée sur le disque elle est vraiment très rapide. La définition de la table est stockée sur le disque, donc la table sera recréée au reboot.
Au niveau HTTP :
- Tu héberge au même endroit tes images et tes pages dynamiques, lorsqu’un processus apache est créé il emporte avec lui toutes ses extensions (php, gd, client SQL, etc…). Du coup c’est lourd en mémoire, en processeur, et ça diminue les ressources disponibles pour ton serveur de base de données. Utilise un lighthttpd pour le JavaScript, le CSS et toutes les images, c’est beaucoup plus rapide ! Tu peux faire cohabiter les deux sur un même serveur
Au niveau PHP :
- Je n’ai jamais utilisé de système de gestion de cache (je n’en ai pas eu le besoin) mais je vais m’y mettre pour ma nouvelle version, apparemment c’est très performant !
En espérant qu’une de mes remarques touche un point que tu n’a pas encore approfondi !
Salutations,
Sébastien
Pierre>Effectivement se pose le problème des compétences. Mais au delà de ça, et concernant le cout, il peut être réduit en utilisant du matériel entrée de gamme voir même grand public. A partir du moment où tu es dans une architecture de répartition de charge et haute dispo, tu peux sans problème encaisser la perte d’une machine si l’ensemble est dimensionné pour. Cela te permet de travailler avec du matériel certes moins fiable que de « vrais serveurs », mais à un cout à l’achat tout à fait raisonnable.
Il y a aussi toute la partie continuité de service qui est importante. Lorsqu’un backend tombe, tu remplaces. Lorsque l’ensemble devient insuffisant, tu ajoutes. C’est vraiment très souple sur du long terme. Je privilégie un ensemble de petites machines à un plus petit ensemble de machines plus performantes (vous me suivez ?)
Sébastien> Je ne suis pas totalement d’accord en ce qui concerne le cache de MySQL. Le cache de MySQL peut dans certains cas être très pénalisant sur des tables comportant beaucoup d’enregistrements et une taille de cache élevée peut même devenir une source de lenteur supplémentaire (lorsqu’il s’agit « d’invalider » ces requêtes en cache). J’en ai déjà fait les frais… François en parlait dans un précédent billet, memcache est une solution terriblement efficace !
J’ai donc pris l’habitude de ne pas trop compter sur le cache de MySQL. (une bonne source d’info sur le sujet: mysqlperformanceblog.com ).
Concernant lighthttpd c’est également très intéressant pour tous les contenus statiques, pour économiser des ressources pour les raisons que tu as citée plus haut (thttpd ou webfs, de mémoire, sont encore moins gourmands).
Attention tout de même à ne pas choisir la solution de facilité en les laissant écouter sur un autre port que le 80 si hébergés sur la même machine. De nombreux réseaux universitaires ou réseaux d’entreprises ne laissent accès qu’aux ports standards. Du coup un site sans css ou images, c’est pas top
Coté cache php, eaccelerator est très bon, et les gains sont considérables. Ça se met aisément en place et je n’ai jamais rencontré de problème avec que l’on pourrait qualifier « d’effets secondaires ».
Le rapport temps investi/gain de perf, est bluffant.
Désolé pour la longueur de mes commentaires, mais quand ça me passionne …
Merci pour vos commentaires, je connais une bonne partie de ces solutions et d’ailleurs un certain nombre sont déjà en fonctionnement sur Hellotipi.
Pour MySQL en effet le blog mysqlperformanceblog est une mine d’or (même si ça vole parfois un peu haut
)
Concernant le système de cache de MySQL en effet le défaut d’une mise en cache au niveau de la base est un manque de contôle de la granularité: une donnée change dans la table et hop! tout le cache lié à celle-ci saute…
Quand on héberge des sites il y a les données de plusieurs sites dans une même table, il est donc plus pertinent de découper le cache par site: c’est là qu’intervient memcache.
Je ferai probablement un bilelt explicatif le jour où je remettrai en place le cache memcache sur Hellotipi.
Bref beaucoup à dire sur le sujet et peu de généralités malheureusement.