Comme je trouve le sujet intéressant et que j’ai un avis complémentaire, bien que différent, je me permet dont d’écrire cet article pour l’exposer.

Différence entre temps d’exécution et temps de rendu

Pour ma part, je trouve la micro-optimisation assez peu intéressante dans le sens où elle est micro. Cette optimisation se base en tout et pour tout sur le temps d’exécution brut d’un script PHP, en se demandant si je peux gagner 10% en remplaçant tout mes echo par des print, ou alors en utilisant des  » au lieu de ‘.

Sauf que, dans la vie d’une application web, ce temps n’est rien. Pour enfoncer une porte ouverte, le fonctionnement du web se décompose en plusieurs phases :

1. Envoi d’une requête : interroger les serveurs DNS, trouver le serveur et ouvrir une connexion avec lui.
2. Génération de la réponse : le temps d’exécution
3. Téléchargement du résultat : le temps que le HTML généré par le PHP reviennent sur le client
4. Interprétation du résultat : le temps que le navigateur interprète le HTML, découvre les ressources nécessaire au rendu
5. Chargement des ressources annexes (assets) : pour chaque ressource, on repart du début (requête, réponse, téléchargement et interprétation)

Le temps de rendu est l’ensemble des temps nécessaires pour réaliser toutes ces phases.

Prenons l’exemple, au hasard, d’un moteur de recherche bien connu, et analysons le chargement de la page d’accueil :

Analyse du chargement de la homepage

Voici ce que l’on peut apprendre de cette analyse :

• le temps complet de chargement de la page est de 964ms
• la requête initiale (requête, génération, téléchargement du résultat) prend 110ms (95ms de génération du résultat)

Il est donc clair que le temps de rendu (le temps nécessaire pour que l’utilisateur puisse utiliser la page) est 9 fois plus important que le temps d’exécution du script sur le serveur. Du coup, gagner 10% sur le temps d’exécution ne fait gagner que 1% sur le temps de rendu.
Et je parle ici de la page d’accueil de Google, qui optimise beaucoup ses chargements, mais pour d’autres sites, moins optimisé, c’est encore pire dès que le nombre de CSS, de JS ou d’images croît.

Optimisez vos chargements

Pour agir de façon drastiquement efficace sur votre temps de rendu, tant que le temps d’exécution est inférieur à 75% du temps de rendu, c’est du côté du chargement qu’il faut chercher.

Pour agir sur le chargement, j’utilise 2 outils : Page Speed et Yslow. Ces outils se basent sur une liste d’optimisations de chargement de pages web.
Je vous conseille de ne pas chercher à atteindre la perfection sur tout les points, mais c’est une bonne base de travail. Je vous conseille également de travailler avec les 2 outils en parallèle, car ils ne sont pas toujours d’accord, et cela permet de pondérer les conseils de chacun.

Micro-optimisation vs. macro-optimisation

Sur ce point, je suis totalement d’accord avec ZenProg : commencer par ce qui apporte réellement un gain de performance à vos sites !

Par expérience, je sais que lorsqu’un script PHP est lent, il faut commencer par traquer les causes suivantes :

1. Requêtes non optimisées
2. Schéma de base de données non optimisé
3. Requêtes dans des boucles
4. Boucles non optimisées

Requêtes non optimisées

Faire un EXPLAIN PLAN est un minimum vital pour des requêtes un minimum complexe. Dans de (trop) nombreux cas, 80% du temps d’exécution du script est l’oeuvre d’une requête non optimisée qui bloque le PHP

Schéma de base de données non optimisé

Comme le dit ZenProg, un index bien pensé (un index sur le(s) champ(s) sur lequel/lesquels se base les requêtes les plus fréquentes) permet de gagner beaucoup de temps, pour la même raison que pour le point précédent.

Requêtes dans une boucle

L’une des plus grosses fautes de développement, selon moi, c’est de ne pas contrôler les requêtes générées par son code source. Il est très facile de se retrouver dans un cas de figure où une requête est exécutée dans une boucle, surtout avec les frameworks MVC.
Contrôler le nombre de requêtes générées, et travailler sur des données de test réalistes (des dizaines d’enregistrement minimum) permettent donc de se rendre compte quand le nombre de requêtes d’une page semble trop important pour le travail réalisé, et donc se rendre compte qu’on a des requêtes inutiles.

Boucles non optimisées

Je vois trop souvent des algos qui, suite à plusieurs évolutions, se retrouvent avec plusieurs parcours d’un même tableau.
Au final, c’est du temps perdu lors des milliers/millions d’exécution de l’algo, juste parce le développeur n’a pas voulu « perdre » quelques minutes à prendre du recul sur son algo.

La lisibilité du code

Je sais que je sors un peu du sujet, mais je trouve qu’on y perd plus lorsque la micro-optimisation d’un code source rend sa lecture difficile

L’optimisation hors script

Je ne pouvais pas finir cet article portant sur l’optimisation sans parler de l’optimisation que j’appelle « hors site ».
J’entends par là qu’il y a des optimisations qui sont applicables sans se pencher sur un script, mais qui améliorent drastiquement son temps d’exécution :

• Mettre en place un cache d’Opcode (APC, …)
• Mettre en place un cache de rendu

Conclusion

Pour moi, bencher si print est plus efficace que echo, c’est de la masturbation intellectuelle pour la plupart des développeurs web que nous sommes.
Après la démonstration que je viens de vous faire, je pense que le jour où vous en serez réduis à remplacer vos print par des echo dans votre code source pour l’optimiser, c’est que vous aurez des besoins en performance très particulier, et que vous aurez déjà éculé les optimisations que je vous ai listées.

J’ai détecté le soucis en essayant de mettre à jour les ports
sudo port selfupdate
sudo port upgrade outdated


Je suis tombé rapidement sur l’erreur suivante (dans mon cas, c’était sur gettext) :
Error: Target org.macports.build returned: shell command failed (see log for details)
Log for gettext is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_gettext/gettext/main.log
Error: Status 1 encountered during processing.
To report a bug, see


Le soucis viens en fait de MacPorts, qui n’est plus adapté au nouvel OS, mais qui ne sais pas se mettre à jour.
Pour résoudre ce soucis, il existe heureusement une explication fournie par MacPort.

Pour information, je n’ai toujours pas migré de Snow Leopard vers Lion, car j’attends les 1er retours avant de me jeter sur la mise à jour.

Mais revenons au sujet : le remplacement de MySQL par PostGreSQL.
Pour ma part, cela fait longtemps que MySQL n’est plus mon SGBD préféré, et je dirais même que j’ai pas mal de choses à lui reprocher, dont la source est toujours la même : sous couvert de simplicité d’utilisation, il ne respecte pas la norme SQL ANSI-92.

• Possibilité d’utiliser des mots-clés réservés pour les tables, colonnes, … en utilisant le « ` »
• Création automatique d’index
• Intégration des dates plus que limitée (tout est converti en timestamp à votre insu)
• tant encore

Je sais bien que vous pourrez me répondre « mais si c’est plus simple à utiliser, où est le mal ? ». Et j’aurais du mal à vous contredire sur ce point.
Mais le soucis est ailleurs, au niveau de la maîtrise.
Non seulement, les milliers (millions ?) de développeurs ayant découvert le SQL avec MySQL apprennent de très mauvaises habitudes, mais les défendent alors même qu’elles sont contraires aux standards.

Le plus marrant, selon moi, est que ce sont ces mêmes personnes qui défendent Mozilla parce que « c’est libre, respectueux des standards, alors que Internet Explorer, non » qui utilisent MySQL (preuve selon moi de l’immense majorité de personnes qui ont adoptés Firefox pour être « hype » et pas par conviction).

Bref, pour en revenir à nouveau au sujet de base, j’utilise PostGreSQL depuis plusieurs années, et j’en pense le plus grand bien : non seulement il est ouvert, en pleine force de l’âge, équipé pour supporter les très gros volumes, permettant l’utilisation de techniques SQL avancées, mais également utilisable rapidement pour des sites à petits volumes, avec des bases de données simples.

Donc, en conclusion, je trouve que cette migration est une très bonne nouvelle pour PostGreSQL, pour augmenter sa visibilité au développeurs amateurs, qui apprennent sur les outils démocratiques.
Et, qui sais, un jour nous aurons une majorité de LAPP (Linux-Apache-PostGreSQL-PHP) au détriment du traditionnel LAMP (Linux-Apache-MySQL-PHP)

Sous l’impulsion de Geoffrey Bachelet, il y a une équipe de motivé, dont je fais parti, qui est composé d’une dizaine de personnes.

Nous sommes en phase de création, on se cherche un peu, mais nous avons déjà de bonnes idées, et des mises en pratique vont suivre dès la rentrée.
Au programme, nous avons :

• Coding party pour recoder le site aperophp.net
• Organisation d’une conférence technique à la rentrée
• Déposer une candidature pour le PHP Tour 2012

Un leitmotiv que nous allons tenter de suivre va être l’ouverture aux autres technologies. Et dans cette voie, nous avons participé il y a quelques temps au Barcamp Lyon 2011, avec des devs Java, JS, Ruby, Microsoft, …
De cet évènement sont ressortis quelques contacts intéressants qui annoncent des collaborations intéressantes. Affaire à suivre

Je suis très content qu’une communauté de développeurs PHP se mette enfin en place sur Lyon je suis très motivé par cette association, et je compte donc m’investir autant que possible dans son activité.

Je suis très heureux que ça bouge enfin

Je sais que je m’y prend un peu tard, puisque l’évènement aura lieu dans moins de 15 jours maintenant, mais le week-end des 25 et 26 juin 2011 se tiendra à Lyon la première Game Dev Party Lyonnaise.

Le principe est simple :
Vous êtes développeur et vous ne savez pas comment utiliser vos compétences ?
Vous avez une super idée de jeu, mais vous n’avez pas le temps/les compétences/la motivation pour la mettre en pratique ?
Rejoignez-vous pour 48h, et pour aller le plus loin possible dans la réalisation de cette idée.

Le lieu est également sympa puisque ça sera l’atelier des médias

Je m’étais inscrit parce que le challenge m’intéressais beaucoup, mais des obligations familiales font que je serais dans le sud ce week-end là.

Ce projet, en plus d’être très prometteur, est dans une phase de développement très forte, et toujours en version beta, ce qui implique que de nouvelles versions sortent très régulièrement (15 versions depuis le début de l’année 2011, dont une version majeure).
La principale conséquence est qu’il est à la fois difficile d’être toujours à jour, mais également qu’un code peut ne plus fonctionner du jour au lendemain.
Heureusement, dans ce genre de technos très dans le vent, il existe toujours une solution.

L’astuce du jour s’appelle n. C’est un package qui permet d’installer/activer/supprimer rapidement et facilement n’importe quelle version de node.js, en permettant à plusieurs versions de cohabiter.

Installation

n s’installe très facilement grâce à npm :
sudo npm install -g n

C’est tout. Il y a pire me direz vous.

EDIT : comme me le fait remarquer Naholyr dans les commentaires, la version actuelle de npm demande l’option « -g » pour une installation globale

Utilisation

n permet de consulter les versions de node installer, d’en ajouter, de changer la version utilisée, de supprimer des versions inutiles, ou d’installer rapidement la dernière version disponible :

Voir les versions installées

Cette commande affiche la liste des versions de node installées
mrandy:~$ n
0.4.6
ο 0.4.7


Activer/installer une version de node.js

Imaginons que vous avez besoin d’installer node.js v0.3.8 (dernière version 0.3) pour exécuter un de vos codes
mrandy:~$ sudo n 0.4.6
mrandy:~$ n
ο 0.4.6
0.4.7

Cette commande va modifier la version active de node (celle appelée par défaut).
Dans le cas où la version demandée n’était pas installée, cette commande va télécharger les sources, les compiler, installer la version et l’activer :
mrandy:~$ sudo n 0.4.0
[...]
mrandy:~$ n
ο 0.4.0
0.4.6
0.4.7


Installer la version la plus récente

Seulement voilà, sur un projet aussi dynamique, on ne sait jamais si on a la dernière version ou pas.
Heureusement, n gère ce cas puisque la commande « n latest » est un alias pour la dernière version disponible.
mrandy:~$ sudo n latest
[...]
mrandy:~$ n
0.4.0
0.4.6
0.4.7
ο 0.4.8


Supprimer une version de node

C’est bien joli tout ça, mais au bout d’un moment, on se retrouve avec plus d’une dizaine de versions installée, et c’est un peu le boxon pour un psychorigide comme moi.
Mais rassurez-vous, là aussi, n a tout prévu :

mrandy:~$ sudo n rm 0.4.0
[...]
mrandy:~$ n
0.4.6
0.4.7
ο 0.4.8


Et tout le reste


n help // affiche la liste des commandes de n
n use 0.4.7 // Execute node avec la version donnée (activation one shot)
n bin 0.4.7 // Affiche le chemin vers l'exécutable de la version donnée
n ls // Affiche la liste des versions de node.js disponible, en indiquant lesquelles sont installée


Comme vous l’aurez compris, je suis un fan de tee-shirt marrant, comme tout geek qui se respecte, et les tee-shirts en question viennent d’un site que j’aime beaucoup : Pilo-Tee.
Non seulement leurs produits sont intéressants, mais la base (souvent American Apparel) est d’excellente facture, les couleurs ne délavent pas et leurs impressions sont d’une superbe qualité (même après plusieurs lavage, aucune dégradation)

Aujourd’hui, pour fêter leur 3 ans, le site organise un jeu concours, et comme je trouve que ce site mérite d’être connu pour la qualité de ses produits, et que je renierais pas de gagner 10 tee-shirts, eh bien je participe
En résumé, je poste un article pour faire connaitre le site, et, en contrepartie, je dispose d’un code promo rien que pour vous, heureux lecteurs, vous permettant de ne pas payer de frais de ports : mrandy

Bien entendu, le jeu concours est ouvert à tous et rien ne vous empêche de participer vous même pour faire connaitre encore un plus cet excellent site.

PS : Liens direct vers les tee-shirt que j’ai acheté : « Fork me i’m famous » et « Error 404 : brain not found »

Pour rappel, je suis responsable technique dans une SSII lyonnaise, Prestaconcept, qui se place sur le segment des applications web, c’est à dire du développement web, mais pour plus qu’un site web vitrine.
Cela parce que nous voulons vendre du développement maintenable, évolutif, avec une vrai utilité, un vrai coeur de métier, et donc accompagner nos clients sur le long terme.
Ce sont d’ailleurs ces idéaux qui me font me sentir bien dans mon entreprise : on ne cherche pas à vendre à tout prix, on essaye surtout de s’inscrire dans la durée avec nos partenaires, et donner les moyens à nos développeurs de produire de la qualité.

Seulement, dans ce superbe tableau, il y a un problème : les clients.
Je sais, ça commence comme une mauvaise blague (trop) souvent répétée, mais ne quitter pas tout de suite la lecture de ce billet.
Ce qui me pousse à écrire ce billet aujourd’hui, ce sont les profils des clients qui viennent nous voir.
Il y a quelques années (juste 3 petites années, avant la fameuse crise), les gens avaient des budgets, des idées. Les personnes qui demandaient des applications web étaient des investisseurs habitués au monde du web, qui connaissaient sa réalité, à savoir que ce n’est pas un eldorado où il suffit de lancer un site pour rentrer un maximum de liquide sans trop d’effort. Bref, en un mot, des gens qui savent ce qu’a été la bulle internet.

Toutefois, depuis le passage de la crise financière (je passerais sous silence mon analyse de cette crise …), j’ai remarqué une progressive mutation du profil client type qui vient nous voir. Nous avons de plus en plus de clients qui décident de changer de vie (travail pas assez payé, licenciement, …) et qui pensent que monter un projet web est une superbe idée, qui plus est facilité par le statut d’auto-entrepreneur.
Du coup, nous voyons de plus en plus de clients qui tombent des nues lorsque nous avançons un budget à 5 chiffres pour une application e-commerce complète, ou qui s’étonnent que les maquettes et le cahier des charges n’est pas offert avant signature.

Maintenant, il me reste à insérer le dernier soucis pour en arriver à ma conclusion : les concurrents qui pourrissent le marché.
Je vous préviens dès le début que je pense manquer de recul sur l’analyse de ces concurrents, et que mon avis n’est donc surement pas totalement éclairé.
Mais je trouve que ces professionnels, souvent des free-lances, des auto-entrepreneurs ou encore des TPE qui, à l’abois, cassent complètement les prix pour survivre.

Mais, dites moi, des clients qui pensent faire fortune juste en étant sur le net, des prestataires qui ne tiennent pas la qualité … ce ne sont pas les ingrédients de la bulle internet ?
Est-ce que le monde capitaliste est aussi cruel qu’il suffit de 10ans pour que les erreurs se répètent ?
De plus, des clients qui cherchent du pas cher, et des prestataires qui sont prêts à se prostituer pour ne pas mourir. Au final, tout cela donne l’image d’un web pas cher, de mauvaise qualité (eh oui, pour 8 000€, on ne recode pas Magento) et qui ne fonctionne pas.

J’avoue que je souri toujours quand un client nous demande de reprendre une application que notre concurrent moins cher lui a vendu, et de me rendre compte qu’elle fait la moitié de ce qu’on avait promis, pour 3/4 du prix qu’on avait proposé (pas besoin d’avoir fait math sup’ pour comprendre le soucis).
Je me doute bien que, humainement, c’est compliqué « d’enterrer » un client qui viens aux abois pour qu’on lui sauve la vie. Mais c’est pas parce qu’ils ont fait confiance à quelqu’un qui n’a pas réussi à tenir ses engagements qu’on doit, nous, lui faire des cadeaux.

Pour finer sur use nouvelle violation de copyright : « I have a dream about a better web world »

Ma société, Prestaconcept, m’a donné l’occasion de passer la certification Zend PHP 5.3 cette année, principalement pour des raisons commerciales, mais j’ai accepté avec plaisir.
Nous étions 2 de ma société, puisque j’ai passé l’examen avec mon collègue Christophe Dolivet.

Ne sachant pas le niveau attendu, et comme je ne m’estime pas non plus le 1er venu en PHP, nous avons décidé de la passer en candidat libre, juste en révisant à l’aide de la documentation Zend et du manuel PHP.

Et bien, malgré mes doutes, JE L’AI EU

Bon, côté des points noirs, maintenant que je l’ai passé, je suis moins ébloui par cette certification, puisqu’il vaut mieux connaitre le manuel sur le bout des doigts que de savoir organiser un code, ou savoir mettre en pratique une factory ou un visiteur.
Mais bon, comme cette nouvelle ligne sur mon CV semble être reconnue, je ne vais pas m’en plaindre

Comme j’ai eu quelques problèmes, notamment lors de l’installation de zombie.js, je vous partage mes découvertes

Installation de node.js

Pour rappel, node.js est un framework JS se basant sur le moteur javascript V8, le moteur utilisé par Chrome.
Il permet de créer des applications serveur codées en javascript.

Pour cette première étape, la procédure donnée par Romain fonctionne sans soucis

git clone https://github.com/ry/node.git
cd node
./configure && make && sudo make install

Pour les débutants de git, la 1ère ligne va downloader le code source de node.js, il est donc nécessaire de se placer dans un répertoire spécifique. Pour ma part, je dispose d’un répertoire « ~/vendor » qui me sert à ça.

Installation de zombie.js

Zombie.js, quand a lui est une extension node.js permettant d’exécuter du code javascript distant.
Romain l’utilise pour réaliser des tests fonctionnels d’écran utilisant javascript.

Installation de npm

La méthode la plus simple est effectivement d’utiliser npm, un package manager for node. En gros, il s’agit d’un macport dédié pour node.js

Pour cela, il suffit de taper la ligne suivante :
curl http://npmjs.org/install.sh | sudo sh

Installation de zombie.js

Maintenant, attaquons la dernière étape, celle qui m’a posé le plus de soucis : l’installation de zombie.js

Normalement, il suffit de lancer la ligne de commande suivante :
sudo npm install zombie

Sauf que, dans mon cas, l’installation échouais sur une erreur de ce type :
npm ERR! Error: base64@1.0.1 install: `node-waf configure build`
npm ERR! `sh` failed with 1
npm ERR! at ChildProcess. (/usr/local/lib/node/.npm/npm/0.2.14-1/package/lib/utils/exec.js:25:18)
npm ERR! at ChildProcess.emit (events.js:34:17)
npm ERR! at ChildProcess.onexit (child_process.js:164:12)
npm ERR!
npm ERR! Failed at the base64@1.0.1 install script.
npm ERR! This is most likely a problem with the base64 package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! node-waf configure build
npm ERR! You can get their info via:
npm ERR! npm owner ls base64
npm ERR! There may be additional logging output above.


En remontant un peu, l’erreur exacte était la suivante :

Waf: Entering directory `/usr/local/lib/node/.npm/base64/1.0.1/package/build'
[1/2] cxx: base64.cc -> build/default/base64_1.o
../base64.cc: In function ‘v8::Handle base64_encode_binding(const v8::Arguments&)’:
../base64.cc:132: error: ‘class node::Buffer’ has no member named ‘data’
../base64.cc:132: error: ‘class node::Buffer’ has no member named ‘length’
../base64.cc: In function ‘v8::Handle base64_decode_binding(const v8::Arguments&)’:
../base64.cc:150: error: ‘class node::Buffer’ has no member named ‘data’
../base64.cc:150: error: ‘class node::Buffer’ has no member named ‘length’
Waf: Leaving directory `/usr/local/lib/node/.npm/base64/1.0.1/package/build'
Build failed: -> task failed (err #1):
{task: cxx base64.cc -> base64_1.o}
npm info base64@1.0.1 Failed to exec install script
npm ERR! install failed Error: base64@1.0.1 install: `node-waf configure build`
npm ERR! install failed `sh` failed with 1
npm ERR! install failed at ChildProcess. (/usr/local/lib/node/.npm/npm/0.2.14-1/package/lib/utils/exec.js:25:18)
npm ERR! install failed at ChildProcess.emit (events.js:34:17)
npm ERR! install failed at ChildProcess.onexit (child_process.js:164:12)


Heureusement, après une petite recherche Google, je suis tombé sur la solution au fond d’un gist : npm utilise une version personnelle de la librairie base64, qui n’est pas la meilleure.
Il vaut mieux commencer par installer la bonne librairie :

git clone git://github.com/substack/node-base64.git
cd node-base64
sudo npm install .


Une fois cette étape réalisée, il suffit de relancer l’installation de zombie pour que ça fonctionne

sudo npm install zombie

Le problème dont parle Romain dans son article était un soucis de « missing dependencies » qui était simplement dû au fait que son npm n’était pas à jour, et il a fallu le mettre à jour, donc en gros de reprendre la procédure d’installation.