Compression zlib sans passer par la directive « zlib.output_compression »

    23:52 24 09 2007

En PHP, il est possible de compresser les sources envoyés vers le navigateur afin d’économiser de la bande passante. Cela s’appelle la compression zlib. Il est possible de l’activer directement dans le fichier php.ini grâce à la directive zlib.out_compression.

Mais voilà, on n’a pas toujours accès au fichier php.ini. Vous allez alors me dire

« bah, t’as qu’à faire un ini_set() dans ton code! ».

Je suis d’accord, sauf que l’utilisation d’ini_set() est gourmande en temps d’exécution vu que l’a conf est rechargée à chacun de ses appels.

Une solution tierce que m’a donné un stagiaire sur une formation que j’anime cette semaine est de passer par l’output buffering.

Il est possible de passer une fonction de callback à ob_start(). Cette fonction sera exécutée sur l’ensemble de votre buffer, donc de votre page. Or il existe une fonction spécifique en PHP permettant d’effectuer la compression zlib avec l’output buffering : ob_gzhandler()

En complant les deux, on obtient une compression zlib sur sa page :

ob_start(‘ob_gzhandler’);

Cette astuce est certainement connue de beaucoup de monde vu qu’elle est directement décrite dans la documentation de PHP (http://fr.php.net/manual/fr/function.ob-gzhandler.php) mais je doit avouer que je n’étais jamais tombé dessus.



Photoshoot avec les stars du PHP

    22:56 20 09 2007

En faisant du ménage sur mon portable, je suis retombé sur cette photo plutôt marrante :

Romain Bourdon, Rasmus Lerdorf, Zeev Suraski

Cette photo date du Forum PHP 2004.
J’étais parti faire des courses car on manquait de bouteille d’eau pour les participants et en revenant je me suis trouvé au milieu d’un photoshoot de Rasmus et Zeev pour divers journalistes présents sur place. On (je ne sais plus exactement qui) m’a alors demandé de me mettre à côté d’eux pour le côté fun de la situation…malheureusement (ou heureusement), la photo n’a pas été sélectionnée pour les magazines en question ;-)



Première revue de WampServer 2

    08:54 20 09 2007

Comme certains le savent peut-être, je suis actuellement en train de travailler sur WampServer 2, la prochaine version de WAMP5 qui devrait sortir avant la fin de l’année.
Cette fois, il s’agit non pas d’une évolution de WAMP5, mais bien d’une refonte lourde de l’application.

Certains vont me demander « Pourquoi? Qu’est ce qu’il t’a fait WAMP5 pour mériter cela? »
et je leur répondrait « WAMP5 a fait son temps, il n’a pas démérité et aura bien sûr sa place au tableau d’honneur, mais il est temps de se tourner vers l’avenir et de réfléchir aux générations futures qui ont également le droit à l’innovation! ».
Comment ça, je pars en vrille…?!

Donc une nouvelle version de WAMP, mais alors pourquoi ce changement de nom?
Je commencerais par dire, que dans WAMP5, il y a 5 en référence à PHP5 et que bientôt (enfin, dans les 12 mois), il y aura PHP6 et que je n’ai pas envie de tout changer à ce moment là. Par ailleurs, mon idée première était que WAMP5 s’appelle WampServer mais, à l’époque, je suis parti sur WAMP5 en décidant que ce serait une série spéciale en référence à la sortie de PHP5. La série spéciale est restée et est devenue la référence. Je dirais ensuite que WAMP5 1.x.x, ça fait beaucoup de chiffres pour une seule application!
Retour aux origines, la prochain version s’appellera donc WampServer 2.0.

Mais alors, quel est donc l’objectif de ce WampServer 2.0 machin chose?

WAMP5 (ou WampServer maintenant) a pour objectif premier de permettre aux développeurs de reproduire leur environnement de production sur leur poste Windows afin d’en faire un environnement de développement. Le problème est que jusqu’à présent, chacun peut reproduire un environnement à peu près équivalent à celui de production, les versions de Apache, PHP, et MySQL étant liés à la version de WAMP5 que vous installez. Il n’est pas possible, par exemple, d’avoir un apache 2.0.45 avec un PHP 5.1.3 et un MySQL 4.0.25 (au pif) à moins de télécharger une vieille version de WAMP5 et de la bidouiller.
WampServer 2 va remédier à cela!

Avec WampServer 2, il sera possible d’installer autant de version de Apache, PHP et MySQL que souhaité et basculer de l’une à l’autre. La version de base sera toujours livrée avec les dernières version disponibles mais il sera ensuite possible de télécharger des modules complémentaires pour ajouter d’autres versions, le nombre de versions installables étant virtuellement infini.

L’idée semble simple, mais elle implique une refonte complète de WampServer, le menu devant s’adapter à chaque switch effectué. Par exemple, je switch d’une version de PHP à une autre. Dans le menu, il faut alors recharger toutes les extensions, les options de configuration, changer le chemin d’accès au fichier php.ini..etc
C’est pourquoi dans WampServer 2.0, le menu sera entièrement regénéré à chaque lancement de l’application ou à chaque changement de conf grâce à un unique script CLI refresh.php.
Cela implique également d’autres changements importants dans le fonctionnement et l’architecture de WampServer mais je vous épargnerais ces détails.

Voilà pour la principale nouveauté, d’autres seront également incluses (nouvelle page d’accueil, modification de la structure du menu, changement de l’arborescence de WAMP, etc…) mas ça, je vous l’expliquerais dans un autre post ;-)



PHP à New York

    09:03 30 05 2007

Voilà, ma semaine de vacances à New York est terminée. Cette ville est vraiment fabuleuse, unique…bref, j’ai adoré et je conseille à tout le monde d’y aller au moins une fois dans sa vie, ca vaut vraiment le coup. Par contre, il faut prévoir le budget, la vie coûte cher de l’autre côté de l’atlantique!

Bien sûr, j’en ai profité pour continuer la lutte :

PHP1

PHP2

PHP3

PHP4

PHP5



PHP aux ARCS 1800

    22:06 15 03 2007

Je viens de passer quelques jours aux ARCS…et je n’ai pas pu m’en empêcher!

sticker PHP

sticker PHP

Pas de répit dans la promotion de PHP, vous pourrez en trouver quelques uns dans la station et sur les pistes.
D’ailleurs, ça m’a donné l’idée de lancer un concours de collage de stickers PHP, si jamais j’ai le temps…



Wikeo, le site de Bisto

    18:32 25 01 2007

Bistory, un des modérateurs des forums de WAMP5 vient de sortir une nouvelle version de son site. Joli travail entièrement réalisé en PHP.

Selon ses propres mots :

Wikeo est une plate forme simplifiée de création et d’hébergement de sites web. Grâce à Wikeo, vous allez pouvoir créer un site très rapidemment sans taper une seule ligne de code.
Différents modules dynamiques pourront agrémenter votre site afin d’avoir une réelle interaction avec les visiteurs.
Tout a été pensé dans un système de simplicité et rapidité de prise en main afin d’obtenir un résultat satisfaisant pour votre site perso, site de votre organisation, d’une petite PME, …

http://www.wikeo.be

Félicitations encore Bistory



Zend/PHP conference à San Jose

    18:44 31 10 2006

Je suis invité, toute cette semaine, à la Zend/PHP conférence qui se déroule à San José CA. J’y suis avec mon associé Cyril, pour plus d’infos sur la conf et notre semaine sur place, consultez son blog :http://www.cyruss.com/blog



PHP, clusters et sessions

    13:05 5 03 2006

Un des principaux problèmes que l’on peut rencontrer lorsque l’on utilise une architecture LAMP dans le cadre d’un site à fort trafic est l’utilisation des sessions sur un cluster de serveurs. En effet, par défaut, chaque serveur gère ses propres sessions sur son disque, l’utilisateur se verra donc attribuer une session différente à chaque fois qu’il sera redirigé par le répartiteur de charge sur un serveur différent du cluster. Plusieurs solutions plus ou moins efficaces permettent de résoudre ce problème. Sans être un expert de ce genre de problématiques, j’ai pu rencontrer plusieurs cas lors de mes différentes missions qui comportent toutes des avantages et des inconvénients.

La première consiste à lier un utilisateur à un serveur donné du cluster. Pour cela, lors de la première page affichée, le système de répartition de charge envoie un cookie à l’utilisateur afin de garder une trace du serveur vers lequel il a été redirigé. Lors des requêtes suivantes, l’utilisateur sera toujours redirigé vers le même serveur et conservera donc sa session. Cette solution bien que très facile à mettre en oeuvre pose plusieurs problèmes.
Premièrement, elle ne fonctionne bien sûr pas si l’utilisateur a désactivé les cookies. En même temps, les sessions ne devraient pas non plus fonctionner sans cookies à moins d’activer le use_trans_sid mais chacun sait que, par défaut, cela entraîne d’importantes failles de sécurité.
Le deuxième vient de la haute disponibilité. En effet, si le serveur sur lequel l’utilisateur a sa session tombe, il sera redirigé vers un autre serveur par le système de répartition de charge et perdra donc toutes les données de sa session courante ce qui peut être très problématique dans le cadre d’un site de vente en ligne par exemple.

Une autre solution va consister à redéfinir le handler (gestionnaire) de sessions afin de le rediriger vers un espace de stockage mutualisé pour les différents serveurs du cluster. Deux grandes possibilités sont généralement utilisées :
–le partage NFS – cette solution consiste à utiliser un serveur accessible en partage réseau et de stocker les sessions de tous les serveurs dessus. Elle est efficace pour de petits clusters mais, à ce que j’ai pu voir, les montées en charge entraînent rapidement des problèmes de lecture sur disque et donc des ralentissements importants de l’application.
– le stockage des sessions en base de données – le principe est très similaire sauf que les sessions sont stockées en base de données. Pour que cette solution soit efficace, il est primordial de dédier ce serveur de base de données uniquement au stockage des sessions. Une telle solution est généralement moins rapide que les sessions natives à cause du temps nécessaire à établir la connexion avec la base de données.

La dernière solution rencontrée est la solution propriétaire proposée par Zend au travers de sa Zend Paltform. Celle-ci dispose d’un module de cluster de sessions qui vient remplacer les sessions natives de PHP et permet aux différents serveurs du cluster de partager leurs sessions. De ce que j’ai pu voir, cette solution est plutôt efficace et stable, le partage des sessions n’induit pas spécialement de différences de temps de réponse avec les sessions natives. Elle est également très facile à mettre en oeuvre, il suffit d’installer la PlatForm, tout est géré automatiquement. Solution la plus professionnelle, elle a malheureusement aussi ses inconvénients.
D’abord le coût de licence de la PlatForm. Celui-ci n’est pas très élevé en regard des services qu’elle fournit mais il s’agit tout de même d’une somme non négligeable. Cette solution très complète de pilotage d’architecture PHP ne peut donc convenir qu’à des projets commerciaux d’une certaine envergure et ne peut pas être utilisée dans le cadre de projets communautaires ou à faibles revenus.
Ensuite, le système de cluster de session n’offre pas de redondance des données (hic!). Pour le moment, les sessions ne sont toujours stockées que sur leur serveur d’origine et partagées au moment de leur appel, donc si un serveur tombe, les sessions qui sont dessus ne sont plus disponibles. D’après une conversation que j’ai eu récemment avec Zeev, des fonctionnalités de redondance devraient rapidement être introduites dans les prochaines versions de la Platform ce qui permettra de résoudre ce problème. Quoi qu’il en soit, il apparaît que cette solution est pour le moment la plus efficace et je pense qu’on devrait rapidement la retrouver sur de nombreux systèmes.

Pour finir, je dirais simplement qu’il est peut être temps que la communauté se penche serieusement sur cette problématique. Si l’on souhaite que PHP s’impose en environnement professionnel, il faut lui en donner les moyens. A ceux qui me diront « Bah t’as qu’à le faire! », je répondrais simplement « J’aimerais bien, mais je n’en ai ni le temps, ni les compétences » :D



Metro, boulot, boulot, boulot…

    16:05 3 03 2006

Voilà, trois mois que je n’ai pas posté sur ce blog, trois mois complètement débordé par mon travail et ma vie personnelle; je viens enfin de refaire surface ce matin et de respirer une grande bouffée d’air, ouf…

Comme certains d’entre vous le savent peut être déjà, ZEND a décidé de profiter de cette année 2006 pour s’installer en France. Pour cela, ils ont choisi Anaska/Kaptive comme partenaire pour les formations et les missions de consulting/développement. Pour cela, Guillaume Ponçon, l’auteur du livre Best Practices PHP5 à rejoint notre équipe, ou plutôt va rejoindre notre équipe dés que sa période de préavis sera terminée chez son précèdent employeur.

En attendant, je me suis donc retrouvé à gérer les premières missions ZEND/ANASKA en même temps que mon travail courant, deux audits complets (environnement de dev, environnement de prod, best practices, architecture, infrastructure…) pour deux grands sites Français très connus (je suis toujours en attente de l’accord de ces sociétés pour les citer).

Ces deux missions ont été très enrichissantes pour moi.
D’abord par les intervenants avec lesquels j’ai été amené à travailler : Zeev Suraski, Chuck Hagenbuch (créateur de horde) ou encore Shahar Evron (spécialiste des produits Zend) .

Ensuite par les différents environnements de production que j’ai pu voir; d’un côté, un niveau professionnel très élevé avec plus de 70 serveurs en production, des procédures pointues de gestion et de maintenance; d’un autre côté, un environnement beaucoup plus artisanal avec une équipe obligée de s’adapter à de fortes contraintes budgétaires et n’ayant pas le temps de mettre en oeuvre des procédures évoluées de gestion.
Au final, deux environnements très différents mais permettant dans les deux cas de maintenir un site professionnel de services à destination des internautes soutenant une charge très élevée.
Nous avons émis, lors des deux missions, de nombreuses recommandations leur permettant d’atteindre un niveau d’excellence (quoi mes chevilles?) dans l’environnement de développement et de production PHP.

A part cela, nous avons été invités, Cyril (mon associé) et moi par Microsoft à l’International Technology Summit qui se déroulera à Redmond en Avril. L’occasion pour l’éditeur d’échanger avec des acteurs importants de la communauté Open Source sur leurs positions sous la forme de discussions interactives. Je vous ferai bien sûr un retour sur ce déplacement dés mon retour.

Voilà, il me reste quelques heures de répit avant de repartir en apnée, j’en profite donc pour ranger mon bureau, régler les affaires courantes et si j’ai le temps, mettre à jour WAMP ;-)



Communiquer avec PHP en CLI (ligne de commande)

    21:57 30 11 2005

J’ai dernièrement ajouté des fonctionnalités de gestion des extensions PHP à WAMP5. Pour cela, j’ai créé quelques scripts PHP en CLI appelés par le gestionnaire de WAMP. Mais comment communiquer avec PHP, lui passer des paramètres ou encore interagir avec l’utilisateur?

Je me suis donc penché sur la question et voici mes conclusions.

Passer des paramètres à un script CLI :

Pour cela , il suffit de fournir ces paramètres lors de l’appel au script. Attention, on a l’habitude de les passer grâce à la syntaxe HTTP. Quelque chose du genre :

« php index.php?toto=valeur »

Cela ne fonctionnera pas en CLI, cette syntaxe est liée au protocole HTTP (méthode GET), PHP cherchera un fichier s’appelant « index.php?toto=valeur ». en ligne de commande, il suffira d’ajouter ces paramètres à la suite de l’appel au script :

« php index.php valeur »

On pourra alors accéder aux paramètres grâce aux tableaux $_SERVER['argv'] et $_SERVER['argc']. argc permettra de connaître le nombre de variables passées à PHP, argv permettra d’accéder à ces paramètres. Dans l’exemple précèdent

$_SERVER['argv'][0] vaudra « index.php »
$_SERVER['argv'][1] vaudra « valeur »

Interagir avec l’utilisateur lors de l’exécution du script :

Il peut arriver que l’on ait besoin de poser des question à l’utilisateur, récupérer des variables. Dans le cas de WAMP5, un des scripts permet d’ajouter une extension dans le php.ini, il faut donc que l’utilisateur puisse taper le nom de cette extension. Pour cela, il suffit d’utiliser l’entrée standard STDIN.

La commande

$newext_name = trim(fgets(STDIN));

permet de lire ce qui arrive de STDIN jusqu’à ce qu’il y ait un retour chariot. Concrètement, cela permet à l’utilisateur de taper tout ce qu’il veut jusqu’à ce qu’il tapes sur la touche Entrer. le contenu tapé est alors récupéré dans la variable $newext_name.
Un petit echo avant cette commande permettra de poser une question à l’utilisateur. Par exemple :

echo ‘Veuillez taper quelque chose :’;
$newext_name = trim(fgets(STDIN));

Le contenu tapé par l’utilisateur sera récupéré dans la variable $newext_name.

En conclusion, si vous voulez des exemples pratiques de ces méthodes, téléchargez la dernière version de WAMP5 (1.5.0 à l’heure où j’écris ce post) et regardez ce qui se trouve dans le répertoire scripts ;-)