Voici de quoi remuer tout ça, et augmenter nos scores Yslow ou Page Speed (et nous aimons ça). On va chasser les octets superflus, on va s’attaquer aux CSS.

Et l’occasion qui fait le larron, c’est la sortie de MAX CssMin, un optimiseur CSS écrit en PHP que je viens de releaser en GNU GPL. Une sortie du placard car cela fait un petit moment que je l’utilise pour différents projets. Il ne touche pas à la sémantique, que de l’amélioration de syntaxe. Pour l’instant, c’est le meilleur que j’ai pu essayé. Bon, à la fin, c’est la guerre des octets, que des micros optimisations, mais j’en ai encore quelques unes en réserves. La version 0.2 verra une option pour tout mettre sur une seule ligne. Pour l’instant ça le fait pas encore (vous pouvez en éditant le fichier cssmin et en décommentant la ligne en dessous du commentaire « Efface les retours à la ligne (à désactiver par défaut) »).

On va se faire un petit script à placer sur le serveur, lancé par cron chaque nuit qui va optimiser vos fichiers CSS, tout seul.

Aller, on se ssh à son serveur.

Les prérequis (rien de bien extraordinaire, adaptez la commande à votre système de paquet) :

aptitude install php5-cli unzip

On commence par installer le MAX CssMin en version script (CLI). Copiez-collez ceci (après avoir lu et compris) dans votre terminal :

wget http://libre.maxbusiness.fr/files/cssmin/cssmin-0.1.zip
wget http://libre.maxbusiness.fr/files/cssmin/cssmin-0.1.zip.md5
md5sum -c cssmin-0.1.zip.md5
unzip cssmin-0.1.zip
chmod +x cssmin
mv cssmin /usr/local/bin
cssmin --help

Bonus, ça vérifie même la somme md5 de l’archive. C’est installé. Tapez cssmin --help pour les options courantes.

On va créer un script shell, nommons le css.sh qui va contenir les commandes de minification. C’est lui qui sera appelé par la tâche cron toutes les nuits. Créons le. Voici son contenu :

#!/bin/sh
cssmin -rbq /var/www/monsite/css/style.css
cssmin -rbq /var/www/monsite2/css/style2.css

Explications : -q vous passe en mode quiet (pas de blabla sauf si erreurs), -r c’est le mode replace (on écrase le fichier CSS par sa version minifiée) et -b c’est le mode better (on ne fait les changements que si le résultat est meilleur). En l’occurrence, le mode better vous permettra de ne pas avoir la date de modification du fichier mise à jour chaque nuit (apache s’en sert pour les instructions de cache aux navigateurs).

Vous placer une ligne comme ça par fichier à optimiser. Je vous conseille d’essayer en console avant (sans l’option -q).

On rend ce script exécutable :

chmod +x css.sh

Maintenant, on enregistre une tâche cron, réglée pour être lancée pour tous les jours à 03:05. Tapez crontab -e et ajoutez dont une ligne :

5 3 * * * /home/mon/chemin/vers/mon/script/css.sh

Et voilà. Vos fichiers CSS se ré-optimiseront tout seuls, même après vos uploads de nouvelles versions, non optimisées.

MAX CssMin n’en est qu’à ses débuts publics, mais on peut déjà faire des choses intéressantes avec. Un bonus pour la fin :

cat style-1.css style-2.css style-3.css | cssmin > all-min.css

Donc pour cette occasion un peu spéciale, je vais vous présenter une méthode un peu inattendue pour calculer Pi. On va utiliser la fonction rand().

On va utiliser le hasard et les probabilités. Fuyez pas, vous allez voir, c’est sympa. C’est la méthode de Monte-Carlo (vous savez, ses casinos, ses jeux de hasard…).

Regardons cette figure présentant un quart de disque de rayon 1 :

L’aire de ce quart de disque est de Pi / 4 et l’aire totale du carré est de 1.

Le principe est simple : on va tirer des points au hasard. La probabilité (notons la P) que chaque point soit dans ce quart de cercle est donc de P=Pi/4. Et cette probabilité, on va la calculer en faisant un tirage de N points. Il y en aura disons X qui tomberont dans le quart de cercle. On divise X par N et on a notre probabilité P.

Finalement, on a P=Pi/4 et P=X/N donc Pi/4=X/N d’où Pi=4*X/N.

On tire alors un point au hasard. On va utiliser la fonction rand (ou mt_rand, plus rapide et meilleure au niveau distribution aléatoire) pour déterminer ses coordonnées X et Y. Et s’il vérifie X²+Y² < 1 alors il est dans le quart de cercle. On répète ça un paquet de fois et le tour est joué.

Voyons comment on code ça en PHP. J’ai optimisé un peu la chose en ne ramenant pas les coordonnées dans [0,1]² ce qui évite des divisions. Le code :

<?php
$totalDotNumber = 100001;

$inCircleDotNumber = 0;
$maxRand = mt_getrandmax();
$maxRand_pow2 = pow($maxRand, 2);

for ($i=0; $i<$totalDotNumber; $i++) {
    if ( (pow(mt_rand(), 2)+pow(mt_rand(), 2) ) < $maxRand_pow2) {
        $inCircleDotNumber++;
    }
}

$frequency = $inCircleDotNumber / $totalDotNumber;
$pi = $frequency*4;

echo 'Points tirés : '.$totalDotNumber."\n";
echo 'dont dans le cercle : '.$inCircleDotNumber."\n";
echo 'Fréquence : '.$frequency.' (=Pi/4)'."\n";
echo 'd\'où : Pi = '.$pi."\n";
?>

On tire 500 000 points, ça prend 5 secondes et on obtient par exemple Pi=3,14436971126. Bon la précision n’est pas fameuse, mais on a bien (heu souvent…) 3,14 et des poussières.

On va s’arrêter là avec Pi, on va pas chercher à améliorer la chose, c’était juste pour le principe. La méthode de Monte-Carlo permet de calculer des intégrales de dimensions supérieure à 1 (avec 2 on a des aires, 3 des volumes, 4 c’est pour Albert Einstein dont c’est l’anniversaire aujourd’hui…).

Moi, ça m’épate. Pas vous ?

Les développeurs de Facebook ont mis au point HipHop for PHP. Pas si loin du compilateur PHP tel que Roadsand ou phc, HipHop réalise une traduction du code source PHP en C++ et se charge de le compiler en embarquant un serveur HTTP léger.

Alors on entend tout et rien à son sujet, alors mettons quelques éléments de compréhension sur la table.

Optimiser son application / son site est un domaine en soi. On peut mettre en cache les résultats des appels aux bases de données (via la base elle-même ou un autre moyen), mettre en cache des parties ou des pages entières générées… Memcached sera votre ami dans bien des cas. Je ne parle même pas d’une utilisation optimale de plusieurs serveurs HTTP (un pour les données statiques, un autre pour les scripts).

Enfin bref, on arrive vite à une limite, un appel où tout est en cache. Et quand on veut améliorer les performances, il faut se tourner du côté de PHP.

Il est déjà important de savoir comment fonctionne PHP. Quand on appelle un script, il est parsé, puis traduit en opcode lequel opcode est ensuite lancé dans une machine virtuelle qui fera le reste du boulot (traduction en instructions CPU et exécution). Ceci à chaque fois.

On peut évidemment optimiser un peu ça. Il y a principalement les caches d’opcode (APC, eAccelerator…). Mais on arrive vite à une autre limite, la machine virtuelle prendra bien un opcode caché, mais elle refera éternellement le même boulot.

L’idée est alors de compiler le PHP. Passons sur phc qui semble inactif.

On a d’un côté Roadsand, qui proposent une autre implémentation de PHP et qui vont effectivement traduire votre script en instructions binaires pour le CPU (bref compiler). Et de l’autre on a HipHop qui va traduire votre script PHP en C++, puis le compiler. Pourquoi j’ai séparé les deux ? Ils arrivent au même résultat. Mais par des moyens différents. On a un binaire. Selon les possibilités, il intègre son serveur HTTP, ou bien il dialogue via FastCGI avec un serveur HTTP.

Roadsend permet du runtime eval (eval, include), HipHop non et le sacrifie fièrement. On va pas rentrer dans les détails inutiles ici.

Je passe aussi l’optimisation au sens propre du code : profilage, blablabla et tout et tout. Ça se fait très bien et permet de voir des défauts d’architecture.

Bref, voyons ce qui nous a amené ici : l’optimisation, compiler PHP et les diverses conneries entendues. Ne retenons qu’une seule chose entendue, qui n’est pas foncièrement une connerie et qui mérite nuance et explication. Les conneries, elles, elles resteront.

Lu chez Maxime Valette :

Avant d’en arriver au stade d’avoir besoin de compiler du PHP transformé en C++, il faudrait déjà penser à s’affranchir de son framework qui ne peut que ralentir l’exécution de son site.

Bon, un framework, pourquoi ? Si Yahoo a choisi Symfony, c’est pour une bonne raison : le développement. Ils savaient très bien que c’est une surcharge de PHP. Mais un développement en équipe, agile, reposant sur des briques découplables, testable est plus qu’un confort. C’est générique. mais c’est un gain d’argent. Un développeur coûte cher. Les serveurs, c’est pas cher. Seule la bande passante est chère. (comparativement)

Il y a des cas où le service est relativement simple, avec une évolution limitée des fonctionnalités. Dans ce cas, oui, faites sans framework. Il ne sert à rien de sortir le marteau pilon pour écraser la mouche. Vous pouvez, mais ne râlez pas à propos de performance sur la lourdeur du framework. Vous avez fait un choix, celui de penser aux capacités de développement avant tout. Si vous voulez, vous pouvez créer votre propre framework, adapté à votre utilisation, pour combiner le meilleur des deux. Mais quand vous aurez tout optimisé, système de cache et tout et tout, alors PHP sera votre facteur limitant, du fait de votre framework. The bottleneck.

Bon, c’est assez tranché, mais tout ça pour vous dire que le PHP peut devenir le facteur limitant. Parce que déjà, si quelque chose est en cache, il faut bien à un moment ou à un autre l’y mettre. Et puis quand tout sort de cache, il y a quand même du code qui s’exécute.

Pas convaincu ? Essayez de générer un fichier PDF à l’aide de FPDF. Pas le truc de Mickey, un gros PDF, pleins de pages. Par exemple, 5000 bons de commandes en un seul PDF. Vous allez le sentir le bottleneck, vous allez sentir du PHP pur qui tourne. Récupérer les infos de la base de donnée c’est du gâteau à côté (c’est peut-être même déjà en cache ?). Les appels d’appels de re-appels de fonctions, de méthodes, d’objets… c’est élégant, mais ça a un coût.

Donc, compiler PHP peut-être une porte à ouvrir, si on veut gagner en terme de performance. Facebook en était là. Et c’est tant mieux, ça complète la voie.

Crédit photo : DragonBe.

Cela venait d’un caractère UTF8 appelé le BOM (Byte Order Mark – U+FEFF) qui est censé donné l’ordre de lecture des données. Sauf qu’en UTF8, il n’y a qu’un sens, donc ce BOM ne sert à rien. Du coup, je sais même pas pourquoi il existe. Ils se trouvent au tout début de fichier.

Si ce n’était que cela, ça irait. Mais voilà, PHP les envoie et les navigateurs les affichent ces cons de BOM. Cela pose donc deux problèmes : un possible envoi de header prématuré avec PHP (génant) et ce fameux espace à la noix dont on a mis 2h à trouver d’où il sortait.

Les symptômes :

• Erreur PHP « headers already sent » alors que vous avez apparemment rien envoyé au navigateur ;
• Vous avez l’encodage UTF8 de détecté : l’espace blanc à la c..n (si votre fond est blanc, sinon ça peut être un espace bleu…);
• Vous forcez l’encodage du navigateur en ISO-8859-1 :  apparait à la place de l’espace blanc ;

Pour résoudre ça, si vous avez l’option (idiote soit dit en passant) de pouvoir enregistrer en UTF8 avec ou sans BOM dans votre éditeur favori, vous choisirez la version sans BOM.

Sinon, vous sortez votre éditeur héxadécimal et la séquence à éradiquer est EFBBBF. En général il se trouve au tout début du fichier. Mais attention, ce caractère de 3 octets est vil et mesquin, avec des copiés-collés, il peut se multiplier et se retrouver pas qu’au début. (Sous VIM il apparait en tant que <FEFF> mais uniquement s’il n’est pas au début, s’il l’est, on le voit pas).

Il aura fallu que je rapatrie des fichiers PHP UTF8 de Windows pour voir arriver ce genre de merdouille. Robix, Linux, c’est pour quand ?

Quand on accède à des variables non déclarées, cela a un coût en terme de performance. En effet, PHP tente de la trouver, constate qu’il n’y arrive pas et lève une erreur de type E_WARNING, et ce même si vous ne les affichez pas. Démonstration.

Exécutons 100 000 fois le code de référence, la variable $variable n’étant pas déclarée :

if ($variable=='test')
  { }

Cela prend en moyenne 180ms.

Voyons le code, amélioré :

if (isset($variable) && $variable=='test')
  { }

100 000 exécutions prennent alors en moyenne 42ms, soit une amélioration de 75% en terme de rapidité d’exécution.

Ce test donne les même résultats que ce soit une variable ($test), un élément de tableau ($test['test']) ou autre.

PHP est souple au niveau des variables (déclaration, typage), l’avantage en terme de programmation a un coût en terme de performances.

Si vous voulez améliorer celles de votre app, laissez s’afficher les erreurs E_WARNING : en effet ce n’est pas parce qu’elles ne sont pas affichées par votre configuration de PHP qu’elles ne sont pas présentes. PHP lèvent ces erreurs quoiqu’il arrive, donc mieux vaut les voir et les éradiquer.

Déclarez explicitement vos variables, ou testez en premier leur existance via isset() avant d’y accéder.

Crédit photo : DragonBe.

Voici un éléphpant ou un PHP-léphant comme je l’appelle. Version home-made : 0,50€ à Ikéa. Si recruter était aussi simple…

Et si vous vous demandez quel est le rapport entre PHP et un éléphant :

1. Je ne pourrais pas vous embaucher
2. Voilà qui devrait satisfaire votre curiosité :

PHP-léphant, profile moi ce bout de code s’il te plait. Merci.