mai 20

Chers lecteurs (sisi y’en a encore, j’ai les stats [superemotions file="/fun/magento_darwin_awards_les_oscars/icon_redface.gif" title="Redfaced / Embarassed"]),

Voici bien longtemps que je n’ai pas eu le temps de poster quoique ce soit. Mes confrères bloggers me l’ont tous dit, « un blog, c’est une discipline, de la régularité, un contenu à date fixe »…

Oui mais voila j’ai eu le site de NBS System à refaire et Bargento 4 à organiser. Cependant, les excuses ne servent à rien, le mieux est d’aller de l’avant.

Alors voila un billet, en attendant de poster pas mal de « lourd » dans les semaines à venir.

Pour se remettre en selle, un petit « bestof » des meilleurs gags sous Magento auxquels nous avons dû faire face récemment ! Avec plus de 200 sites hébergés, on a eu quelques frayeurs et quelques moments de solitudes, je voulais vous faire profiter des intégrations les plus pénibles, des dialogues les plus sourds, des propositions les plus farfelues.

Bref, toute mon équipe se joint à moi pour vous faire part de nos tranches de vie d’hébergeurs.

Nous rions de bon cœur, jamais méchamment car chaque travail a ses difficultés et l’anodin devient le calvaire des autres sans que ce soit fait exprès (c’est réciproque d’ailleurs) !

Voici le palmarès :

Idée la plus folle en intégration, le SDLM (« Le Slider De La Mort »)

Le concept est brillant, simple, élégant. Une interface Web, 5 curseurs à déplacer sur des positions.

Un pour le produit, un pour la couleur, un pour la taille, un pour la forme etc… Quand un internaute déplace un des curseurs, on charge les produits qui vont bien en fonction de la position des différents curseurs, par exemple pantalon, 60, noir, jean, femme, etc.

15 produits * 6 tailles * 12 couleurs * 6 formes * 6 typologies (femme – homme – enfant H/F – adolescent H/F)  = 38 880 requêtes en base de données à chaque déplacement d’un curseur… Bien sur on pourrait optimiser et stocker un résultat de requête, générer un cache ou autre mais le développeur n’avait pas vu les choses sous cet angle… Tout cela part avec une requête Ajax et on attend la réponse pour peupler la page.

Maintenant, on prend sa souris et on bouge son curseur de gauche à droite bien rapidement. Et hop, un dénis de service à coup de millions de requêtes SQL dans la base de données.

Et paf le serveur.

La surenchère au SDLM : l’OMODLM (« on mouse over de la mort »)

Ils ont eu l’idée après ceux du slider de la mort alors le résultat est plus fort mais moins de mérite sur le concept original :)

Bonne note cependant car la version est très évoluée, on a plus besoin de cliquer ou de drag & droper un curseur, passer au dessus des catégories de produit suffit à créer une charge relativement indécente de travail pour les serveurs.

Un confort d’utilisation indéniable somme toute ! Avec le OMODLM (On Mouse Over De La Mort), le déni de service est au bout de votre pointeur, 10 allers-retours bien rapide sur les catégories produit et hop, 200 produits chargé par catégories, 10 catégories, 10 allers-retours du mulot et… et… ben des requêtes javascript en chaine qui font 20 000 requêtes de produits soit en requêtes SQL, facilement le triple.

Et paf le serveur.

La grande méchante Cron : 2 Go c’est trop peu !

Ah les crons, un grand plaisir régulier, qui ne cesse de nous faire trembler.

La plupart du temps ce sont des imports automatiques de produits ou ce type de traitements. Les scripts consomment de plus en plus de RAM, ne trouve jamais leur conditions de sortie et on se retrouve avec un bon gros PH qui pèse 1 ou 2 Go en mémoire et qui continu à manger des ressources sans jamais sortir.

Que du bonheur…

Alors l’idée c’est qu’on a un nombre de tickets impressionnants qui demandent à passer la PHP memory limit à 2 Go voir plus, juste pour laisser la Cron_qui_tue en PHP finir son travail. Cette limite étant appliquée à tous les processus PHP, ca peut très vite, très très vite, dégénérer.

Alors non, on ne passe pas à la limite à 2 Go, on optimise son code ou on gère différemment.

L’auto dérision est un sport, alors nous aussi témoignons !

On est pas plus parfait que les autres alors évidemment on en fait une ou deux.

On utilise Sysfence pour vérifier si certains processus ne deviennent trop gourmands, risquant ainsi de tuer la machine. Ce sysfence vérifie si la machine Swap (et donc manque de RAM) et si c’est le cas, il redémarre le service consommateur.

Sauf que le service en question (apache en l’occurrence) quand on le redémarre, cela ne libère instantanément les ressources allouée, donc le Swap est toujours utilisé et sysfence redémarre le service, et encore, et encore et encore.

Et le site Web, il clignote. (Une temporisation avant de relancer le démon, le temps de laisser le swap se vider, à résolu le problème)

My Java is beautiful

Alors ce n’est pas directement du Magento mais un service connexe de catalogue (comme un catalogue papier dont on tourne les pages). Le moteur de catalogue est assez évolué et permet des trucs totalement inutiles, comme par exemple tourner le catalogue de 3° vers la gauche…

Enfin passons. Il a « l’avantage » de resizer les images à l’affichage donc si on a du 800*600 c’est à la bonne taille et si on est en 1200*1024 etc. Sauf que plutot que de contraindre les images par le CSS ou même de stocker 3/4 versions de tailles différentes, il resize à chaque fois, pour chaque visiteurs et stock tout dans la JVM (oui c’est du Java, c’est plus drôle).

Résultat, au bout de 12H d’utilisation à 10 000 visiteurs, 16 Go de RAM consommés et 86 Go de Swap…

Alors on force la désalocation, le garbage collecting avec des paramètres passé à la JVM mais rien y fait. Alors on tue le démon à intervalle régulier, histoire de pas saturer les deux serveurs de catalogues.

Le superviseur

C’est l’histoire d’un programmeur qui veut faire un outil de supervision de la charge des deux serveurs frontaux de son client. Nos serveurs se portent bien mais il souhaite pouvoir vérifier si un de ses scripts exécuter régulièrement ne prend pas trop de CPU / RAM et sinon le killer.

Bon le script en question consomme effectivement pas mal de ressource alors il code un démon en PHP pour vérifier la charge des serveurs afin de tuer le script si besoin. Seul soucis, il exécute la routine de vérification de la charge avec du PHP, connu pour sa légèreté (5 Mo en RAM pour vérifier la charge alors qu’un démon en C prend 5 Ko). Enfin seul soucis pas vraiment, dans le but de bien faire et d’être réactif, il lance son check toutes les 35 millisecondes… Un script PHP qui a lui seul met plus de 35 ms à s’exécuter.

Et paf le serveur…

My slave is beautiful

Allo ? Mme ……. de la société …… (grand compte).

Oui bonjour, que puis-je pour vous ?

[...] je souhaiterai savoir à quelle date vous pourriez intervenir pour venir configurer nos serveurs ? [...]

Ah, nous ne faisons pas ce type de prestation madame, nous optimisons les serveurs de nos clients et les nôtres mais pas ceux de votre infogérant actuel. (qui ne travail pas avec/sur Magento)

Ah mais attendez, on vous paye. 450 €, par jour ! Par contre il faut être là dès demain matin et les 5 prochains jours d’affilé.

Je me suis mal fait comprendre, cela ne fait pas partie de nos prestations madame.

De plus un expert Magento, peut importe qu’il soit développeur ou infogérant, ca ne coûte pas ce tarif là. Même si nous faisions cela, on a déjà pas mal de travail on ne peut pas se libérer 5 jours d’affilé du jour au lendemain.

Écoutez, je vois que vous ne faites aucun effort, je pense que nous n’allons pas travailler ensemble…

Je vous poste mon site ?

Alors c’est l’histoire d’un mec, il veut mettre son site Magento en ligne. Jusqu’ici, rien d’original. Au bout de 4H, il appel le support et annonce :

Votre système plante au bout de 5 Mo de transfert, je n’arrive pas à mettre le site de mon client en ligne.

Vous utilisez quel protocole ? FTP, SFTP, SCP ou SVN pour faire cette mise en ligne ?

Écoutez, je vous dis que ca plante au bout de 5 Mo, ce n’est pas une question de protocole.

Ca pourrait nous aider à trouver le soucis, sait-on jamais. Quel protocole utilisez-vous ?

J’utilise OTRS.

Notre interface de déclaration de tickets pour le support niveau 1 ?

Oui.

Mais monsieur, le champ upload d’OTRS sert a nous envoyer une copie d’écran, pas le site, il faut utiliser les accès que l’on vous a envoyé SFTP ou SVN par exemple.

Les accès quoi ?

Mention spéciale du jury : Je SVN, tu SVN, il flingue le site…

C’est l’histoire d’une marque qui lance des ventes privées. Un jour, elle appelle sont intégrateur à J-20. « Tu peux me faire une ou deux modifs ? » , « pas de problème je te fais ca ». Les modifications sont mises en ligne, tout fonctionne. Le jour J c’est le drame.

  • 500 visiteurs simultanés, tout va bien
  • 1 000 visiteurs simultanés, tout va … curieusement… La charge monte… un peu trop vite
  • 1 500 visiteurs simultanés tout va plus du tout, serveurs couchés, médore tourne à un load de 70… Soit une surcharge colossale !

On cherche, on cherche, on cherche… Rien à faire les serveurs sont en débandade complète. Mais que se passe t’il ? Eh bien la Web Agency avait écrasé le fichier /var/www/eu/app/etc/use_cache.ser avec son propre fichier… Oui mais un développeur, lui, il coupe les caches pour voir ses modifications instantanément. Quand il publie son fichier use_cache.ser avec 6 cache sur 8 de désactivés, les serveurs sautent.

Ma page d’accueil est lente…

Alors, voyons voir, je prends mes 6000 produits, je code ma boucle, et pour chaque produit sur ma home, je lance ma fonction qui cherche dans les 6000 produits.

Mince, ça rame… Je ne comprends pas ?

écrit par Philippe Humeau


10 commentaires sur “Magento Darwin Awards : les oscars”

  1. 1. Christophe - Dn'D Dit :

    Génial, magnifique et colossal :-)
    Mon préféré sera : « Je vous poste mon site via OTRS » !

  2. 2. cobolian Dit :

    Arfff, ça me rappelle plein de souvenirs ça, de quoi écrire un bouquin.

    Genre virer un batch de quelques centaines de lignes, qui tournait pendant 4 heures et plantait tout le temps pour le remplacer par 3 requêtes SQL, 3 secondes d’exécution maxi.

  3. 3. Simo Dit :

    rolf ! et paf le serveur :p

  4. 4. Magentix Dit :

    Ah oui çà peut aller très loin… Le coup des 38 880 requêtes / mouvement c’est très fort !!
    Bon j’ai fait planter un de vos serveurs une fois mais c’était à cause d’un bug de Magento ;)

  5. 5. Philippe Humeau Dit :

    oui, en plus l’idée de fond était bonne, l’intention tout au moins :) C’est pour ca qu’un dialogue entre les intégrateurs et les infogérants en amont est souvent une bonne chose !

    Pour le serveur planté, ca arrive, et ca arrive aussi à cause de Magento, c’est clair. Avec les versions successives, on a eu tellement de petits bonheurs, de surprises, d’imprévus. Là on en a un en ce moment avec la 1.4 dont le cache Zend a changé en terme de déclaration dans la config et dans l’arborescence. Mais bon, life is life, dans l’ensemble ca tourne super bien.

    A bientot, au Bargento 4.

  6. 6. Gilles Dit :

    Les infogérants, admin systèmes, exploitants, … ont encore de beaux jours devant eux :-)
    Chacun a sa place un développeur développe et un admin système fait son boulot d’administration…

  7. 7. Philippe Humeau Dit :

    Oui Gilles, je suis bien d’accord et je reconnais volontiers que les développeurs ont, eux, milles sujets de préoccupations et soucis à gérer de leurs cotés.
    Disons qu’une collaboration à certains moments clef évite les drames et permet aussi d’optimiser en amont l’ensemble site+infra.

  8. 8. Mathieu Minard Dit :

    alors sans aucun doute, je décerne la palme à OTRS! mais bon je ne veux pas trop faire le malin, car notre mise en prod approche .. :) et si peux rassurer NBS, nous n’importerons pas nos 150.000 produits avec le système de dataflows de Magento :)

  9. 9. Jeff Dit :

    Ouahhhhh des larmes de rire un samedi matin comme ça ça fait un bien fou, merci Philippe, ça me rappelle quelques bonnes parties de rigolade aussi (que celui qui s’amuse à logguer ses requetes sql qu’on se demande bien pourquoi arrete immediatement et supprime ce fichier de 60go qui plante l’os merci !!!!)

    Sinon comme Samuel (AKO10) t’as dit on ne pourra pas etre présent à la v4 et on le regrette beaucoup, mais c’est que partie remise, on reste op pour participer à la délocalisation dès que ça se mets en route.

    Bon courage pour l’orga.

  10. 10. Magento Darwin Awards 2010 part II : the fall & winter best of | Communauté Magento francophone Dit :

    [...] the success of last semester MDA (Magento Darwin Awards), we decided to publish the 2010 [...]

Poster une réponse