Pascal MARTIN (n+1).zéro

Bench PHP 5.2 vs PHP 5.3

Pascal MARTIN — Mon, 20 Jul 2009 07:00:00 +0200

Avec la sortie de PHP 5.3 et l’apparition de nouvelles fonctionnalités, une question est fréquemment posée : qu’est-ce que vaut PHP 5.3 au niveau des performances ? Est-ce que toutes ces nouveautés ne vont pas avoir d’impact négatif ?^[1]

Voila plus d’un an que PHP 5.3 est annoncée comme plus rapide que PHP 5.2 (Cf ce post sur internals@, par exemple) ; j’avais moi-même effectué quelques benchmarks synthétiques, dont j’avais posté les résultats en novembre dernier.

Mais ces tests, qui montraient un gain de performance de 10 à 20% pour PHP 5.3 par rapport à PHP 5.2, n’avaient pas été joués avec la version finale de PHP 5.3.0, d’une part, et ne testaient que des fonctions internes de PHP — pas une véritable application.

Voici donc quelques résultats obtenus avec des « vraies » applications, comportant de nombreux fichiers, des appels à une Base de Données, …
… En somme, des applications du genre de celles que nous sommes susceptibles d’utiliser tous les jours sur nos serveurs !

Sommaire de cet article :

Méthodologie

Si vous voulez aller directement aux résultats…

Logiciels testés

J’ai effectué mes tests avec trois logiciels, en installation « de base », sans ajouter de plugin ni quoi que ce soit :

Wordpress 2.8.1 : http://wordpress.org/
- La page testée correspond à la page d’accueil du blog, en front office
Drupal 6.13 : http://drupal.org/
- La page testée est la page d’accueil du site, avec deux articles créés précédemment via le Back Office
Le « Quick Start » de Zend Framework : http://framework.zend.com/docs/quickstart
- La page testée est celle de « guestbook »

Versions de PHP testées

Pour ces tests, j’ai utilisé deux versions de PHP, toutes deux compilées par moi-même, avec les mêmes options de configuration.
Ces deux versions de PHP sont chargées en tant que module Apache, via deux instances différentes d’Apache^[2] :

PHP 5.2.9, avec Apache écoutant sur les ports 529**
Et PHP 5.3.0, avec Apache écoutant sur les ports 530**

Les options de compilation et de configuration ne sont certainement pas optimales : à peu de chose près, j’ai conservé toutes les valeurs par défaut ; mais, considérant que je n’ai tunné ni la première installation, ni la seconde, la comparaison devrait ne pas être « trop faussée ».

Les sorties de phpinfo() sont disponibles ici, si vous voulez en savoir plus :

(Ces sorties de phpinfo() ont été enregistrées alors que j’avais activé l’extension APC)

Deux séries de tests

Les trois applications ont été testées une première fois sans que l’extension APC ne soit activée.

Les mêmes tests ont ensuite été rejoués avec l’extension APC activée.

Méthodologie

Les trois applications ont été testées en utilisant l’outil ab, avec les options suivantes, qui me semblent raisonnables pour ma machine de tests :

concurrence = 10
nombre d’occurrences = 1000

Le test est lancé une première fois sur l’instance en PHP 5.2.9, puis sur l’instance en PHP 5.3.0.
Ceci est répété 10 fois de suite (on a donc un test sur PHP 5.2.9, puis un test sur 5.3.0, puis un test sur 5.2.9, puis sur 5.3.0, etc…)

J’ai ensuite calculé la moyenne des 10 séries de test pour PHP 5.2.9 et pour PHP 5.3.0 ; c’est cette moyenne qui me sert de résultat pour comparer les deux versions.

Et voici quelques éléments de la machine de tests :

CPU Core 2 Quad 9550 ; les quatre cœurs étaient utilisés à 100% pendant l’exécution des tests
6 GB de RAM ; Il restait en permanence de la RAM libre pendant l’exécution des tests
Les binaires d’Apache, PHP, et les scripts testés sont sur un disque dur 10k rpm
Et l’OS est un Linux Ubuntu 64 bits.

Résultats obtenus sans APC

Pour commencer, voici les résultats obtenus pour chacun des trois logiciels testés, sans APC :

Wordpress

PHP 5.2.9 : 33.26 requêtes / seconde
PHP 5.3.0 : 41.54 requêtes / seconde
Différence : 124.91 %

Pour ce graphique, comme pour tous les autres présentés dans cet article, plus la barre correspondant à une version de PHP est haute, plus cette version de PHP est capable de répondre à un nombre élevé de requêtes par seconde — mieux c’est niveau performances, donc.

Drupal

PHP 5.2.9 : 51.33 requêtes / seconde
PHP 5.3.0 : 63.58 requêtes / seconde
Différence : 123.87 %

Quickstart Zend Framework

PHP 5.2.9 : 77.28 requêtes / seconde
PHP 5.3.0 : 97.79 requêtes / seconde
Différence : 126.54 %

Résultats obtenus avec APC

Et maintenant, les résultats des mêmes tests, en ayant activé l’extension APC (aucune option de configuration n’a été définie dans le fichier php.ini ; toutes les valeurs de configuration sont donc celles par défaut — même si ce n’est pas optimal).

Wordpress

PHP 5.2.9 : 128.66 requêtes / seconde
PHP 5.3.0 : 139.38 requêtes / seconde
Différence : 108.33 %

Drupal

PHP 5.2.9 : 207.79 requêtes / seconde
PHP 5.3.0 : 212.84 requêtes / seconde
Différence : 102.43 %

Quickstart Zend Framework

PHP 5.2.9 : 297.87 requêtes / seconde
PHP 5.3.0 : 290.91 requêtes / seconde
Différence : 97.66 %

Conclusion

Pour conclure, voici quelques mots — sans trop réfléchir non plus : c’est aussi à vous d’interprêter ces résultats et de voir en quoi est-ce qu’ils peuvent être intéressants dans votre situation !

PHP 5.3 : gain de performances !

Comme conclusion, je ferai volontairement simple : sur ces quelques tests d’applications « réelles », sur une installation PHP « standard », PHP 5.3.0 s’en sort nettement mieux que PHP 5.2.x : environ 25 % de requêtes par seconde supplémentaires !

Une fois l’extension APC activée, le gain est nettement moins visible : seulement quelques pourcents, voire même une légère perte dans un cas :-(
Cela dit, on voit encore une fois l’intérêt d’activer APC, à partir du moment où vous êtes libre d’installer des extensions sur votre hébergement : sur ces tests, un très rapide calcul montre que vous répondez à environ trois fois plus de requêtes par seconde avec APC que sans !

A quoi est dû ce gain ? Je n’entrerai pas dans les détails^[3], mais il y a fort à parier que les quelques optimisations citées ici n’y sont pas pour rien :

Déplacement des constantes vers des zones mémoire en lecture-seule
Amélioration du gestionnaire d’exceptions : il est maintenant plus simple, et tient sur moins de code.
Suppression d’appels système à « fopen » pour les inclusions de fichiers via require_once et include_once, résultant en une amélioration de la rapidité de ces deux directives.
Refactoring de la pile d’appels
Utilisation de gcc4 pour la compilation.

Pour plus d’informations, n’hésitez pas à consulter le changelog de PHP 5.3.0.

Quel intérêt ?

J’en entends déjà certains se demander Mais quel intérêt pour mon application ? Et quid du coût probable de migration de PHP 5.2 vers 5.3 ?

Et bien, pour votre application toute seule, l’intérêt, c’est vous le mieux placé pour le déterminer ; mais pensez à ceci : 20% de gain CPU, si vous avez 10 serveurs faisant tourner du PHP, ça peut signifier que deux de ces serveurs pourraient être utilisés pour autre chose… A vous de voir l’économie que cela peut signifier^[4] ;-)

Après, oui, rendre votre application compatible PHP 5.3, et la re-tester, peut prendre du temps, et représenter un coût non négligeable — mais pour les futures applications que vous allez développer, qu’en est-il ? Pourquoi ne pas partir sur PHP 5.3 dès la phase de développement ?

Disclaimer

A noter tout de même : de manière générale, un serveur faisant tourner PHP aura aussi tendance à servir des fichiers statiques (JS, CSS, images, …), ce qui peut avoir un impact sur sa charge, indépendamment de PHP — et les tests présentés ici ne prennaient en compte que le chargement de la page PHP.

A noter aussi : les tests réalisés ici ne testaient qu’une seule page de chaque application, et non chaque application dans sa globalité. Avant de vous lancer dans une — possiblement coûteuse — migration compléte d’application, il peut être intéressant de jouer des tests un peu plus approfondis !

Aller plus loin ? D’autres tests ?

Si vous effectuez d’autres benchmarks de ce type, ou plus poussés, je suis extrêmement intéressé ! N’hésitez pas à laisser un commentaire ;-)

En attendant, vous pouvez jeter un coup d’oeil sur ces deux benchmarks d’eZPublish, effectués il y a quelques semaines :

Performance PHP 5.2 vs PHP 5.3 - huge gain sous Lindows,
et eZ Publish performance with PHP 5.3.0 sous Linux

Les gains de performance constatés sont du même type que ceux que j’obtiens dans cet article ; et ce, que ce soit sous Linux ou sous Windows, ce qui est une excellente nouvelle !

Au passage, vous trouverez joint à cet article le fichier .ods que j’ai contruit, regroupant tous les résultats obtenus (et pas seulement les moyennes présentées ici).

Notes

[1] D’aucun diraient que ça fait deux questions, et pas une ; mais elles sont liées, donc bon…

[2] Il faudrait, un jour, que je rédige un article expliquant comment installer plusieurs versions de PHP sur une seule machine, d’ailleurs… ça fait plus d’un an que j’ai les notes nécessaires… il faut “juste” que je trouve le temps de rédiger…

[3] Détails que je ne connais pas en détails, d’ailleurs ^^

[4] OK, si vous en arrivez à calculer quelles économies vous pourriez réaliser de cette manière, changer de version de PHP n’est pas la seule chose à laquelle vous penserez : passer à un autre serveur (nginx, par exemple), ou installer un reverse proxy (varnish, par exemple) peuvent être deux bonnes idées)

Google Gears : accélérer le chargement d'une application en cachant les fichiers statiques

Pascal MARTIN — Thu, 21 Aug 2008 08:00:00 +0200

Vous souhaitez proposer aux utilisateurs de votre application Web de continuer à travailler avec celle-ci même lorsqu’ils ne sont pas connectés à Internet ?
C’est possible : prenez par exemple Google Docs, qui vous permet de modifier vos documents^[1] sans être connecté !

Travailler hors ligne ?

Avant de commencer, alors que nous avons de plus en plus tendance à avoir accès à Internet où que nous allions, pourquoi se soucier de développer une application Web qui soit accessible hors-ligne ?

Introduction : accès Internet, ou isolement ?

Et bien… justement parce que nous avons de plus en plus accès à Internet : nous avons tellement l’habitude d’être connectés que nous utilisons de plus en plus de services Web quotidiennement, parfois même à la place des outils “déconnectés” que nous employions auparavant… Mais que se passe-t-il si nous sommes dans une situation où nous n’avons pas de connexion Internet (dans le train ? En vacances chez nos grand-parents qui ne connaissent pas encore Internet ? Au fond de la campagne sans connectivité 3G ? En réunion sans accès wifi ?) ?

Cela implique-t-il que nous n’ayons pas accès auxquels nous nous sommes habitués ? Cela signifie-t-il que nous n’avons plus accès à nos données ?
Cette situation est-elle acceptable pour vous ? Dans certains cas, pas pour moi !

Google Gears

Pour répondre au besoin qu’est la capacité pour une application de vous permettre de continuer à travailler hors-ligne, Google a développé Google Gears.

Je cite WikiPedia :

Gears est un prototype logiciel proposé par Google pour permettre l’accès hors-ligne à des services qui fonctionnent normalement en ligne. Il installe un moteur de base de donnée basé sur SQLite sur le système client pour cacher les données localement. Les pages pour lesquelles Google-Gears est activé utilisent les données en provenance de ce cache local plutôt que celles provenant du service en ligne. Si la connexion réseau n’est pas disponible, la synchronisation est ajournée jusqu’à ce que la connexion revienne. Gears permet donc à des applications web de fonctionner sans accès permanent au réseau.

Gears fonctionne sous la majorité des navigateurs Web que vos utilisateurs sont susceptibles d’utiliser^[2] :

Firefox >= 1.5 (Windows, MacOS X, Linux)
Internet Explorer >= 6 (Windows)

Malheureusement, même si le support de Safari est prévu, il n’est pas encore disponible.
A vous de voir l’impact pour vous utilisateurs…

MAJ le 26/08/2008 : Une première version bêta de Gears est sortie pour Safari !

Je cite, tout de même :

This is BETA, it is not an official release, it might break your browser. Chances are it will break your browser. Please proceed with caution.

Pour plus d’informations, allez voir :

http://googlesystem.blogspot.com/2008/08/gears-for-safari.html
et pour l’annonce officielle sur le Google-group de Gears : http://groups.google.com/group/gears-users/browse_thread/thread/36537d4f47c5495c

Une série d’articles sur Google Gears

Cet article est le premier d’une série - de trois, probablement, si je m’en tiens à mon plan - visant au développement d’une mini-application capable de vous permettre de travailler hors-ligne.

Le plan prévu est le suivant :

Premier article (celui-ci) : installation et activation de Google Gears, concepts de base, et utilisation pour stocker en cache, sur le poste utilisateur, les fichiers statiques utilisés par l’application.
Second article : travail hors-ligne, sans le moindre appel au serveur, une fois l’application en mode “déconnecté”.
Troisième article (octobre 2008 ?) : synchronisation entre les données “en-ligne”, et le travail effectué “hors-ligne”, lors du retour en mode connecté.

Application utilisée pour cet article

Pour cet article, nous développerons une application des plus simple : une application de prise de notes.

Une application simple

L’idée est la suivante :

une note est composée d’un nom d’auteur, d’une date, et d’un texte
un formulaire permet de saisir une note
les trois champs sont obligatoires
la liste des notes saisies est affichée au-dessus du formulaire de saisie.

Au niveau de l’interface, on obtient quelque chose de ce genre :

Rien de très compliqué, donc ^^
(Les sources de l’application sont disponibles en téléchargement ; Cf la pièce jointe à ce billet, tout en bas de celui-ci)

Cette application est développée en PHP + SQLite, avec un brin de Javascript, CSS, et XHTML pour la couche présentation.
Pour faire simple, pas de MVC, pas d’orientation objet, juste un seul fichier .php pour le tout ; à vous de faire plus complet / plus organisé lorsque vous travaillerez sur une application réelle, et non un script d’exemple !

Des temps de chargement non satisfaisant ?

Au fur et à mesure que vous ajoutez des fonctionnalités à vos pages, vous ajouterez - probablement - des fichiers que le navigateur client devra télécharger : feuilles de styles, fichiers Javascript, images, … Tout ceci finit par augmenter les durées de chargement des pages avec lesquelles vos visiteurs travaillent.

Pour la page toute simple que nous avons présenté plus haut, voici la liste des fichiers chargés depuis l’en-tête de la page :

<link href="css/style.css" media="screen" rel="stylesheet" type="text/css" />
<script type="text/javascript" src="js/lib/prototype.js"></script>
<script type="text/javascript" src="js/lib/scriptaculous/builder.js"></script>
<script type="text/javascript" src="js/lib/scriptaculous/effects.js"></script>
<script type="text/javascript" src="js/lib/scriptaculous/dragdrop.js"></script>
<script type="text/javascript" src="js/lib/scriptaculous/controls.js"></script>
<script type="text/javascript" src="js/application.js"></script>

Ceci qui donne le graphe de chargement de page suivant :

(Modulo un ou deux fichiers : cette capture correspond à un graphe de chargement de l’application complète)

Déjà pour cette page simple, qui n’inclut qu’une seule feuille de style et seulement quelques fichiers JS, le chargement de ces fichiers externes - et statiques - prend plus de la moitié du temps de chargement ! Plus de la moitié du temps que l’utilisateur passe à attendre que la page s’affiche correspond à des fichiers qui sont quasiment toujours les mêmes : ils ne seront modifiés que lors de mises à jour de l’application, et il est à parier que celle-ci sera utilisé plus souvent qu’elle ne sera MAJ^[3] !

Gears va permettre de stocker ces fichiers directement sur les postes de vos utilisateurs, qui n’auront donc pas à les re-télécharger à chaque chargement de page.
Bien entendu, cela accélèrera le chargement de notre liste de notes… Mais, surtout, c’est un premier pas vers une version utilisable hors-ligne de notre site !

Quelques remarques :

Pour montrer l’intérêt de ce dont je parle dans cet article, j’ai volontairement inclus plus de fichiers JS que nécessaire pour cette application (j’ai inclus une partie de script.aculo.us) : pour une application un tant soit peu plus complexe, vous en inclurez probablement encore d’autres.
D’un autre côté - et ça vaut mieux considérant mes talents de graphiste - je n’ai pour ainsi dire pas inclus d’image ; disons que ça compense… Plus ou moins.
Bien entendu, dans un cas réel, votre serveur serait certainement configuré pour indiquer au navigateur qu’il doit conserver les fichiers css/js/images en cache, et ne pas les re-télécharger à chaque chargement de page ! Mais cela ne nous aiderait pas vraiment à rendre notre application accessible hors-ligne, n’est-ce pas ?

Premiers pas avec Google gears

Avant de réellement pouvoir travailler avec gears, il vous faut inclure un fichier Javascript fourni par Google, et, bien évidemment, vous assurer que l’utilisateur de votre site a installé le plugin attendu.

Inclusion du fichier gears_init.js

Pour inclure des fonctionnalités liées à Gears sur votre site, vous devez inclure sur vos pages le fichier “gears_init.js” fourni par Google : gears_init.js.

L’idée est la suivante :

vous téléchargez le fichier fourni par google,
vous le stockez sur votre propre serveur, avec vos autres fichiers Javascript,
et vous l’incluez sur vos pages, via une balise <script> tout ce qu’il y a de plus standard :

<script type="text/javascript" src="js/lib/gears_init.js"></script>

Ceci vous permettra d’accéder à l’outil Google gears depuis vos scripts.

Installation de Gears

Une fois le fichier gears_init.js inclut, vous pouvez commencer à travailler avec l’objet google.gears.
Typiquement, le premier pas sera de détecter si l’utilisateur de votre site a installé l’extension / le plugin^[4] google gears, et, si ce n’est pas le cas, de lui proposer de l’installer.

Pour détecter si le plugin gears n’est pas installé, il suffit de deux tests Javascript :

if (!window.google || !google.gears) {
    // Extension google gears non installé
    // => Afficher un lien menant à son installation
}

Le lien proposant d’installer Google Gears doit pointer sur le site de Google ; plus précisément, sur la page permettant… l’installation du-dit plugin.
Il doit être construit de la manière suivante :
http://gears.google.com/?action=install&name=<NOM_APPLICATION>&message=<MESSAGE>&return=<URL_DE_RETOUR>&icon_src=<URL_ICONE>

Bien entendu, à vous d’assigner à chaque variable les valeurs qui correspondent à votre site / votre application :

action = install ou update. De manière générale, si google gears n’est pas installé, vous proposerez à votre visiteur de l’installer.
name = le nom de votre application ; au maximum, 150 caractères.
message = un message à afficher sur la page d’installation de gears ; au maximum, 150 caractères.
return : l’URL de la page de votre site vers laquelle l’utilisateur reviendra après installation du plugin.
icon_src : l’URL d’une icône à afficher sur la page d’installation de gears ; sa taille doit être de 48x48 pixels.

Un point intéressant à noter : pensez à échapper les caractères spéciaux de vos messages, url, …
Mais cet échappement doit être conforme à la RFC 1738 ; cela signifie que le caractère espace ne doit pas être remplacé par un “+“ !
Pour les développeurs PHP, notamment, cela signifie qu’il faut utiliser rawurlencode, et non urlencode !

Ci-dessous, quelques captures d’écran de l’installation de Google gears, sous Firefox 3.0, linux :

Le lien sur notre application proposant d’installer Gears, visible seulement lorsque nous avons détecté que l’extension n’était pas déjà installée :

La page d’installation du plugin gears sur le site de Google : notez la présence des nom, message, et icône, que nous avions spécifiés dans le lien :

Une fois que l’utilisateur a cliqué sur le bouton “Install gears”, il doit accepter les conditions d’utilisation :

Puis l’installation, sous Firefox, du moins, se fait comme pour n’importe quelle extension :

Avec le redémarrage obligatoire de Firefox en fin de processus d’installation :

Maintenant, lors de la prochaine visite de l’utilisateur (lorsqu’il aura redémarré son navigateur), nous détecterons que l’extension gears est installée, et nous pourrons commencer à exploiter ses fonctionnalités.

Activation de gears

Une fois l’extension / le plugin gears installé, nous allons pouvoir commencer à l’exploiter pour notre site.

Autorisation pour votre site

Pour cela, en premier lieu, le visiteur doit autoriser notre site à accéder aux fonctionnalités de gears. Sans cette autorisation, impossible pour vous de déposer des fichiers sur le poste utilisateur (même chose pour les autres fonctionnalités, que nous verrons au cours des prochains articles).

Automatiquement, lors de la première tentative d’accès aux fonctionnalités exportées par google gears, l’extension demande son autorisation à l’utilisateur de votre application : vous n’avez rien de particulier à gérer à ce niveau.
La seule liberté qui vous est offerte, en tant que de développeur, est de pouvoir déterminer si l’utilisateur a autorisé gears pour votre site :

if (google.gears.factory.hasPermission) {
    // gears est autorisé pour votre site
}

Instanciation des composants gears

Pour pouvoir utiliser la fonctionnalité de stockage de fichiers en local, qui est celle qui nous intéresse pour cet article, deux objets sont à instancier :

Le “LocalServer” en lui-même, qui permet à une application Web de stocker en cache, sur le poste client, des ressources (fichiers, notamment) HTTP, et de les servir sans connexion réseau,
Un “ManagedStore”, qui permet de stocker ces fichiers, tout en gérant leur mise à jour régulière et (éventuellement) automatique.

Qu’est-ce que cela donne en terme de code ?

Et bien, commençons par déclarer les deux variables que nous utiliserons pour la suite de nos exemples :

var localServer;
var store;

Et instancions nos deux composants :

localServer = google.gears.factory.create('beta.localserver');
store = localServer.createManagedStore('test');

Tout d’abord, nous obtenons une instance de LocalServer, à partir de laquelle nous serons à même de stocker localement des fichiers auxquels nous accèderions normalement via une requête HTTP - requête qui sera interceptée par gears, qui renverra directement en retour le fichier stocké localement, sans effectuer l’aller-retour client/serveur.
Et, ensuite, nous créons au sein de notre serveur local un ManagedStore, qui contiendra les-dits fichiers, en se chargeant notamment de leur mise à jour.

Le paramètre donné à la méthode createManagedStore est le nom de notre espace de stockage ; c’est par ce nom que nous le retrouvons d’un chargement de page à l’autre.

A la première exécution de cette portion de code, google gears détectera que l’utilisateur n’a pas encore autorisé votre site à accéder à ses fonctionnalités, et lui affichera une demande d’autorisation, ressemblant à celle-ci :

(Le nom “http://tests” correspondant à celui de ma machine de développement sera naturellement remplacé par celui de votre site)

Vous ne pourrez exploiter les fonctionnalités de Google Gears au sein de votre application que si votre utilisateur a autorisé celle-ci à accéder à l’extension… ce qui signifie qu’il vous faudra former vos utilisateurs, en leur expliquant ce qu’est cette boite de dialogue, et ce qu’elle leur apportera !
(On répète tellement souvent qu’”il ne faut pas cliquer sur „oui j’accepte”” sans savoir de quoi il s’agit que ça commence à être compris… Ici, nous souhaitons justement que l’utilisateur accepte… L’expliquer - et expliquer pourquoi, cette fois, exceptionnellement, il faut dire “Oui” - ne peut être que bénéfique !)

Stocker les fichiers statiques sur le poste client

Alors… Nous avons vu comment indiquer à nos utilisateurs comment installer le plugin google gears ; nous avons vu comment obtenir des instances de classes LocalServer et ManagedStore ; et nous avons vu que, lors de la première utilisation de notre application, l’utilisateur devait autoriser google gears pour notre site.
Voyons maintenant (enfin ? ) comment stocker sur le poste client les fichiers statiques liés à notre application.

ManagedStore et fichier manifest

Pour déterminer quels sont les fichiers à télécharger et à stocker en local, le ManagedStore se base sur un fichier texte, contenant un objet au format JSON, contenant la liste des URLs des fichiers, ainsi qu’un numéro de version.
Ce fichier est dit fichier “manifest”, et souvent nommé “manifest.json”.

Dans le cas de notre application, le fichier manifest serait le suivant :

{
    "betaManifestVersion": 1, 
    "version": "0.1", 
    "entries": 
    [
        {"url": "css/style.css"}, 
        {"url": "js/lib/gears_init.js"}, 
        {"url": "js/lib/prototype.js"}, 
        {"url": "js/lib/scriptaculous/builder.js"}, 
        {"url": "js/lib/scriptaculous/effects.js"}, 
        {"url": "js/lib/scriptaculous/dragdrop.js"}, 
        {"url": "js/lib/scriptaculous/controls.js"}, 
        {"url": "js/application.js"}, 
        {"url": "js/gestion-gears.js"}, 
        {"url": "img/error.png"}, 
        {"url": "img/tick.png"}
    ]
}

Le principe est simple :

betaManifestVersion correspond au numéro de version du format de fichier manifest utilisée ; actuellement, il n’existe qu’une version de format pour ce fichier ; on indique donc toujours 1 comme valeur.
version correspond au numéro de version du fichier en lui-même : pour déterminer si les fichiers stockés localement doivent être mis à jour, c’est sur ce numéro de version que le ManagedStore se basera. Autrement dit, à chaque fois que vous voudrez que les fichiers stockés localement sur les postes de vos utilisateurs soient mis à jour, il faudra modifier ce numéro de version. Attention : si vous ne modifiez pas ce numéro de version, il n’y aura pas de mise à jour effectuée !
Enfin, entries contient la liste de tous les fichiers qui devront être téléchargées, puis stockés sur les postes de vos utilisateurs.

Une fois ce fichier créé et déposé sur votre serveur, vous devez indiquer à l’instance d’objet ManagedStore avec laquelle vous travaillez qu’elle devra utiliser ce fichier.
Pour cela, affectez son chemin à l’attribut manifestUrl de l’instance d’objet ManagedStore :

store.manifestUrl = 'manifest.json';

Et enfin, pour rapatrier en local l’ensemble des fichiers renseignés dans le fichier manifest, il vous faudra utiliser la méthode checkForUpdate de l’instance d’objet ManagedStore :

store.checkForUpdate();

Il est à noter que cette méthode n’est normalement à appeler qu’une seule fois, pour forcer la récupération en local des fichiers au moment où l’utilisateur a activé l’utilisation de gears pour votre application.

A partir de là, votre application ne devrait plus effectuer de requête HTTP pour charger ces fichiers statiques : une fois qu’ils auront été stockés en local, c’est la version locale qui sera utilisée - du moins, tant que le numéro de version dans le fichier manifest n’aura pas été modifié.

Pour rappel, au niveau du code Javascript mis en place, tout tient en quelques lignes :

var localServer = google.gears.factory.create('beta.localserver');
var store = localServer.createManagedStore('test');
store.manifestUrl = 'manifest.json';
store.checkForUpdate();

C’est-à-dire :

Instanciation de la classe LocalServer,
Instanciation de la classe ManagedStore,
Renseignement du chemin vers le fichier manifest contenant la liste des fichiers statiques à stocker en local,
Et lancement de la mise à jour.

Résultat

Nous avions montré un peu plus haut une capture d’écran de l’onglet Réseau de Firebug, montrant les temps chargements respectifs de chacun des éléments de la page.
Une fois les fichiers statiques stockés en local, voici ce que nous obtenons :

Autrement dit, comme nous le souhaitions :

Nous n’avons plus d’autre chargement via le réseau que celui de la page en elle-même (celle-ci étant dynamique, affichant des informations stockées en base de données côté serveur, il sera plus difficile de se passer de ce chargement - ce sera l’objectif du prochain article de cette série, d’ailleurs)
N’ayant plus aucun chargement de fichier statique via le réseau, le temps de chargement total de la page est fortement diminué (je vous laisse comparer avec le même graphique, plus haut, qui incluait les temps de chargements des fichiers JS et CSS)

Suivre la mise à jour d’un ManagedStore

L’objet ManagedStore nous permet de brancher des méthodes qui seront appelées lors de trois types d’évènements :

oncomplete

La fonction branchée sur ce gestionnaire sera appelée lorsque la mise à jour d’un ManagedStore sera terminée.

Elle reçoit en paramètre un objet contenant une propriété newVersion, correspond au nouveau numéro de version indiqué dans le fichier manifest.

onprogress

La fonction branchée ici sera appelée (de manière générale, plusieurs fois : une fois pour chaque fichier mis à jour) pendant le processus de mise à jour du ManagedStore.

Elle reçoit en paramètre un objet porteur de deux attributs :

filesComplete : le nombre de fichiers mis à jour jusqu’à présent.
filesTotal : le nombre total de fichiers à mettre à jour.

onerror

La fonction branchée sur ce gestionnaire sera appelée en cas d’erreur pendant le processus de mise à jour.

Elle reçoit en paramètre un objet contenant la propriété message, contenant un message d’erreur sous forme textuelle.

Utiliser ces gestionnaires

Il est habituel de brancher un gestionnaire sur onprogress et oncomplete, de manière à pouvoir indiquer à l’utilisateur qu’une mise à jour est en cours, et où elle en est.
Typiquement, cela se fait à l’aide d’une portion de code de la forme suivante, placée après le renseignement du chemin vers le fichier manifest :

Pour afficher un message en fin de vérification de présence d’une mise à jour :

store.oncomplete = function(details) {
    if (!details.newVersion.blank()) {
        $('debug').innerHTML += "Mise à jour effectuée ; version : " + details.newVersion + "<br />";
    }
    else {
        $('debug').innerHTML += "Pas de nouvelle version...<br />";
    }
};

(En supposant que vous avez quelque part sur votre page un élément d’identifiant “debug”, et que vous avez, tout comme moi pour mon exemple, inclut le framework prototype, qui met à votre disposition la fonction $ comme alias vers document.getElementById)

Pour la mise à jour en train de s’effectuer, à présent, cette portion affichera la nombre de fichiers mis à jours, et le nombre de fichiers restant à récupérer depuis le serveur :

store.onprogress = function(details){
    $('debug').innerHTML += "Récupération des fichiers : " + details.filesComplete + ' / ' + details.filesTotal + "<br />";
};

Et, finalement, pour afficher un message en cas d’erreur à la récupération d’une mise à jour :

store.onerror = function(error) {
    $('debug').innerHTML += "Erreur : " + error.message + "<br />";
};

Et voici le genre de résultat que ça permet d’obtenir sur notre application de tests :

Bien entendu, à vous d’améliorer l’aspect de tout cela - typiquement, en rajoutant une barre de chargement ; discrète, dans l’idéal : la mise à jour se faisant en arrière-plan, il serait dommage de bloquer tout l’écran pour indiquer que quelque chose se passe ^^

Note : La détection de mise à jour se fait sur le numéro de version du fichier manifest, et non fichier par fichier. Lors d’une mise à jour, c’est donc l’ensemble des fichiers décris par le fichier manifest qui sont re-téléchargés, et non uniquement ceux qui ont réellement été modifiés.

Aller plus loin

Avant de terminer cet article par un rassemblage de tous les morceaux de code présentés jusqu’à présent, allons plus loin sur quelques points spécifiques.

Forcer la détection de mise à jour

Nous avons dit plus haut qu’utiliser un objet de type ManagedStore pour le stockage local permettait de disposer de mises à jour automatiques des fichiers locaux : régulièrement, gears va vérifier si le numéro de version indiqué dans le fichier manifest est différent de celui qui a été mémorisé en local.

Si le numéro de version a changé, les fichiers listés dans le fichier manifest seront téléchargés, et l’utilisateur travaillera avec cette nouvelle version lors du prochain chargement de la page (la mise à jour des fichiers locaux n’est prise en compte que lors d’un rechargement de page : gears ne peut pas “débrancher” l’ancienne version des fichiers, et “re-brancher” la nouvelle version à la place sans recharger la page - on peut comprendre les difficultés et les problèmes que cela pourrait causer).

Le ManagedStore vérifie périodiquement l’existence de mises à jour (en pratique, il semblerait que ce soit fait quelques secondes après chaque chargement de page), et vous n’avez pas à effectuer la vérification de mise à jour vous-même.
Au pire, il peut vous arriver de vouloir forcer la vérification de mise à jour (éventuellement, dans le cas d’une application qui n’entraine aucun rechargement de page, ou si vous tenez vraiment à ce que vos utilisateurs aient une version à jour).

Dans ce cas, il vous suffit d’appeler la méthode checkForUpdate de votre instance de ManagedStore, comme nous l’avions fait plus haut pour forcer le téléchargement des fichiers lors de l’activation du stockage local :

store.checkForUpdate();

Gears se chargera tout seul de vérifier la version indiquée dans le fichier manifest, et de, au besoin, rapatrier les fichiers pour les stocker, en version à jour, en cache local.

Attention : Encore une fois, pour qu’une mise à jour se fasse, il est impératif que le numéro de version indiqué dans le fichier manifest soit différent de celui qui s’y trouvait lors de la vérification précédente !
(Et ce même si vous utilisez manuellement la méthode checkForUpdate ! )

Désactiver (momentanément) l’utilisation du stockage local

Pour je ne sais quelle raison (rappel : c’est vous qui avez une application que vous voulez rendre utilisable hors-ligne ^^ ), vous pouvez vouloir désactiver momentanément l’utilisation du stockage local.

Cela est possible en exploitant la propriété enabled de votre instance de ManagedStore : en la passant à false, au prochain chargement de la page, ce ne seront plus les fichiers stockés en local qui seront utilisés, mais ceux téléchargés depuis le serveur :

store.enabled = false;

Et pour recommencer à utiliser les fichiers stockés localement, il suffit d’inverser la valeur de la même propriété :

store.enabled = true;

Un point intéressant à noter : lorsque vous recommencez à utiliser un stockage local, vous utilisez la version actuellement stockée en local des fichiers : ils ont été conservés par gears.
En particulier, cela signifie qu’ils ne seront pas retéléchargés, et donc, pas mis à jour, si le numéro de version dans le fichier manifest n’a pas été modifié !

Désactiver gears pour votre site

Lors de vos tests, il vous sera certainement nécessaire, un bon nombre de fois, de “repartir de zéro”, comme si vous n’aviez jamais autorisé gears pour votre site…
Hors, nous venons de voir que désactiver un ManagedStore ne le purgeait pas.

Finalement, la meilleure façon de recommencer au tout début est de révoquer l’autorisation que vous aviez donné à gears de fonctionner pour votre site ; de la sorte, à la prochaine tentative d’utilisation d’une des fonctionnalités fournies par cette extension, il vous faudra re-donner votre autorisation, et, entre temps, tout ce qui avait été stocké en local aura été purgé.

Pour cela, rendez-vous dans le menu “options” de votre navigateur (ou équivalent), pour ouvrir la boite de dialogue “Google Gears Settings”.
Celle-ci affiche la liste des sites qui ont le droit d’exploiter les fonctionnalités de gears :

Le votre est forcément dans cette liste, puisque vous l’avez autorisé plus haut.
Cliquez sur le lien “remove” de la ligne correspondant à votre site, validez… Et voila, vous repartez sur des bases vierges : lors de la prochaine utilisation d’une fonctionnalité fournie par gears, l’extension demandera à nouveau votre autorisation.

(Et cette méthode est sans le moindre doute plus rapide que de désinstaller l’extension, redémarrer le navigateur pour que cette désinstallation soit prise en compte, réinstaller l’extension, et redémarrer le navigateur à nouveau pour que la réinstallation soit prise en compte ^^ )

Recollons les morceaux

Nous avons vu les concepts permettant d’exploiter une partie des fonctionnalités offertes par Google Gears, pour stocker en local, sur le poste client, les fichiers statiques de notre application, ce qui était le but de cet article.

Avant de terminer, je pense qu’il serait nécessaire de reprendre quelques portions de code en les regroupant en méthodes utilisables, pour que vous puissiez voir en un seul coup d’oeil comment le tout fonctionne…

Squelette de page HTML

Pour commencer, l’application de test utilisée ici est composée d’une seule page HTML, découpée en plusieurs parties :

liens de contrôle de gears
affichage d’une liste de notes issues de la base de données (côté serveur)
formulaire permettant d’ajouter une note
et enfin, zone de débug

En somme :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <title>Google Gears</title>
    
    <script type="text/javascript" src="js/lib/gears_init.js"></script>
    
    <link href="css/style.css" media="screen" rel="stylesheet" type="text/css" />
    <script type="text/javascript" src="js/lib/prototype.js"></script>
    <script type="text/javascript" src="js/lib/scriptaculous/builder.js"></script>
    <script type="text/javascript" src="js/lib/scriptaculous/effects.js"></script>
    <script type="text/javascript" src="js/lib/scriptaculous/dragdrop.js"></script>
    <script type="text/javascript" src="js/lib/scriptaculous/controls.js"></script>
    <script type="text/javascript" src="js/application.js"></script>
    
    <script type="text/javascript" src="js/gestion-gears.js"></script>
    
</head>
<body>
<?php
    $notes = array();
    // TODO récupérer les notes depuis la DB (PHP)
    // TODO gérer l'ajout d'une nouvelle note en DB depuis les saisies dans le formulaire (PHP)
?>
    
    <div id="control">
        <a href="http://gears.google.com/?action=install&amp;name=<?php 
                echo rawurlencode('Google Gears, Tutorial'); 
            ?>&amp;message=<?php 
                echo rawurlencode('Installez Google Gears pour accélérer le chargement des fichiers statiques de votre application !'); 
            ?>&amp;return=<?php 
                echo rawurlencode('http://' . $_SERVER['HTTP_HOST'] . $_SERVER['SCRIPT_NAME']); 
            ?>&amp;icon_src=<?php echo 
                rawurlencode('http://tests/gears/faster-loading/application/img/icon-install-gears.png'); 
            ?>" 
            id="install" style="display: none;">Installer Gears</a>
        <a href="#" id="activate" onclick="activateGears(); return false;" style="display: none;">Activer Gears</a>
        <a href="#" id="maj" onclick="majGears(); return false;" style="display: none;">Forcer la recherche de MAJ</a>
        <a href="#" id="deactivate" onclick="deactivateGears(); return false;" style="display: none;">Désactiver Gears</a>
    </div>
    
    <?php foreach ($notes as $note) : ?>
    <p class="note">
        Auteur : <?php echo htmlspecialchars($note->auteur); ?>
        <br />Date : <?php echo htmlspecialchars($note->date); ?>
        <br />Texte : <?php echo htmlspecialchars($note->texte); ?>
    </p>
    <?php endforeach ; ?>
    
    <form method="post" action="" onsubmit="return validation();">
        <p>
            Auteur : <input type="text" name="auteur" id="auteur" maxlength="64" value="<?php echo htmlspecialchars($auteur); ?>" />
            <br />Date : <input type="text" name="date" id="date" maxlength="10" value="<?php echo htmlspecialchars($date); ?>" />
            <br />Texte :
            <br /><textarea name="texte" id="texte" rows="5" cols="50"><?php echo htmlspecialchars($texte); ?></textarea>
            <br /><input type="submit" value="Hop !" name="ok" />
        </p>
    </form>
    
    <div id="debugTimer"></div>
    <div id="debug"></div>
    
</body>
</html>

Je passe sur les portions de code PHP : il ne s’agit pas du point important pour cet article… Vous trouverez le tout en pièce jointe à ce billet (Cf en bas de la page)

A noter : les liens en haut de la page, qui sont tous masqués initialement, et que nous rendrons visible à partir du code Javascript, en détectant si gears est installé ou non, autorisé ou non, …

LocalServer et ManagedStore

Pour les besoins de notre application, nous avons besoin de créer une instance de classe LocalServer, et une instance d’objet ManagedStore, comme vu plus haut.

Elles seront mémorisées au sein des deux variables suivantes :

var localServer;
var store;

L’instanciation des classes en question viendra plus tard.

Note : dans un cas réel, vous encapsuleriez peut-être tout ça dans une autre classe, plutôt que de tout fourrer dans l’espace de nom global… A vous de voir : nous ne sommes ici pas dans un cas réel ^^

Actions au chargement de la page

Au chargement de la page, plusieurs actions sont à gérer :

Détecter si l’extension / le plugin Google gears est installé
Si non, afficher le lien menant à la page d’installation
Si oui,
- Détecter si l’utilisateur a donné à gears l’autorisation de fonctionner pour notre site
- Si non, afficher le lien permettant d’activer Gears pour notre site
- Si oui,
  - Détecter si le ManagedStore est actif
  - Si non, afficher le lien permettant de l’activer
  - Si oui… c’est tout : notre application utilise déjà les fichiers stockés localement - ou est en train de les télécharger si c’est le premier affichage de la page depuis l’activation de gears.

Concrètement, tout ceci peut se traduire par la portion de code suivante :

Event.observe(window, 'load', function () {
    if (!window.google || !google.gears) {
        $('install').show();
    } else {
        if (google.gears.factory.hasPermission) {
            $('debug').innerHTML += "Permissions : OK<br />";
            createStore();
            if (store.enabled) {
                $('debug').innerHTML += "Store : actif<br />";
                $('maj').show();
                $('deactivate').show();
            } else {
                $('debug').innerHTML += "Store : non actif<br />";
                $('activate').show();
            }
        } else {
            $('debug').innerHTML += "Permissions : NON OK<br />";
            $('activate').show();
        }
    }
});

Vous noterez que j’ai choisir d’utiliser la méthode Event.observe du Framework prototype sur l’événement “load” pour que ma portion de code soit appelée une fois l’intégralité de la page chargée, afin d’être sûr que tous les éléments du DOM soient présents avant de commencer à exécuter du code.

Un autre point : pour simplifier les choses, la page HTML inclut de base tous les liens, masqués, et nous affichons en Javascript ceux qui nous sont nécessaires. Dans l’idéal, il serait probablement possible de n’inclure aucun lien dans la page, et de les créer à la volée… Ici encore, il y a une différence entre une mini-application de tests, et un cas réel !

Créer une instance de ManagedStore

En local, nos fichiers statiques seront stockés au sein d’un ManagedStore.
Pour pouvoir obtenir une instance de cette classe, comme vu plus haut, il faut passer par une instance de LocalServer :

var createStore = function () {
    localServer = google.gears.factory.create('beta.localserver');
    store = localServer.createManagedStore('test');
    store.manifestUrl = 'manifest.json';
    
    store.oncomplete = function(details) {
        if (!details.newVersion.blank()) {
            $('debug').innerHTML += "Mise à jour effectuée ; version : " + details.newVersion + "<br />";
            $('debug').innerHTML += "=&gt; Recharger la page<br />";
        }
        else {
            $('debug').innerHTML += "Pas de nouvelle version...<br />";
        }
    };
    store.onerror = function(error) {
        $('debug').innerHTML += "Erreur : " + error.message + "<br />";
    };
    store.onprogress = function(details){
        $('debug').innerHTML += "Récupération des fichiers : " + details.filesComplete + ' / ' + details.filesTotal + "<br />";
    };
}; // createStore

Nous profitons de l’instanciation de notre espace de stockage pour brancher nos gestionnaires sur les événements affectant son cycle de vie, notamment pendant les éventuelles mises à jour des fichiers stockés localement.

Activation de gears pour notre site

Lors du clic sur le lien d’activation de gears, nous devons :

créer le ManagedStore qui servira à stocker localement les fichiers distants,
forcer une mise à jour de celui-ci, pour que les fichiers soient récupérés depuis le serveur lors de la première activation de gears.

Nous en profitons pour nous assurer que le store soit bien activé, en passant à true sa propriété enabled :

var activateGears = function () {
    $('debug').innerHTML += "Activation de google gears<br />";
    createStore();
    store.enabled = true;
    majGears();
}; // activateGears

Cette méthode sera appelée lorsque l’utilisateur activera Gears pour notre site (ce qui explique qu’il faille forcer la MAJ), ainsi que lorsque l’utilisateur ré-activera Gears après l’avoir désactivé (ce qui explique qu’il faille nous assurer que l’attribut enabled est à true : il aura été basculé à false lors de la désactivation).

Mise à jour des fichiers stockés localement

La mise à jour des fichiers stockés localement est des plus simple : il suffit de faire appel à la méthode checkForUpdate de notre instance de ManagedStore :

var majGears = function () {
    if (store.enabled) {
        $('debug').innerHTML += "Lancement de la détection de Mises à jour...<br />";
        store.checkForUpdate();
    } else {
        $('debug').innerHTML += "Store désactivé =&gt; Pas de vérification de MAJ...<br />";
    }
}; // activateGears

Encore une (dernière ?) fois, je rappelle que même si des fichiers ont été mis à jours sur le serveur, la mise à jour ne se fera que si le numéro de version dans le fichier manifest a été modifié !

Fichier manifest

En parlant de fichier manifest… Il s’agit bien entendu du même que celui présenté plus haut, mais le reproduire ici ne peut faire de mal à personne :

{
    "betaManifestVersion": 1, 
    "version": "0.1", 
    "entries": 
    [
        {"url": "css/style.css"}, 
        {"url": "js/lib/gears_init.js"}, 
        {"url": "js/lib/prototype.js"}, 
        {"url": "js/lib/scriptaculous/builder.js"}, 
        {"url": "js/lib/scriptaculous/effects.js"}, 
        {"url": "js/lib/scriptaculous/dragdrop.js"}, 
        {"url": "js/lib/scriptaculous/controls.js"}, 
        {"url": "js/application.js"}, 
        {"url": "js/gestion-gears.js"}, 
        {"url": "img/error.png"}, 
        {"url": "img/tick.png"}
    ]
}

Je rappelle :

le numéro de version du format de fichier,
le numéro de version du fichier en lui-même,
et la liste des fichiers que gears doit stocker en local.

Désactiver gears

Après ce que j’ai dit quelques lignes plus haut, la désactivation - temporaire - de gears, pour utiliser à nouveau des fichiers téléchargés depuis le serveur à chaque chargement de page, ne devrait pas poser de problème :

deactivateGears = function () {
    $('debug').innerHTML += "Désactivation de gears...<br />";
    $('debug').innerHTML += "=&gt; Recharger la page<br />";
    store.enabled = false;
}; // deactivateGears

En effet, il s’agit uniquement de mettre à false le flag enabled du ManagedStore utilisé pour stocker localement les fichiers.

Avant de passer à la suite…

Cet article était le premier d’une série ayant pour objectif de vous permettre de développer une application continuant à fonctionner hors-connexion, en utilisant Google gears.
Il nous a permis de découvrir les premiers concepts nécessaires à l’utilisation de Gears ; en particulier, comment installer l’extension, et détecter si l’utilisateur l’a autorisée à fonctionner pour notre site.

Bien entendu, stocker localement, sur le poste client, les fichiers statiques n’est qu’un premier pas : débranchez votre cable réseau, et vous réaliserez vite qu’il reste encore du travail à effectuer !

Avant de vous donner rendez-vous pour le second article de cette série, j’aimerais attirer votre attention sur un point : le concept offert par Gears - pouvoir continuer à travailler hors-ligne avec une application Web - est peut-être “révolutionnaire”… mais il est surtout complexe pour vos utilisateurs : il faut installer une extension / un plugin, il faut autoriser l’utilisation de celle-ci par votre site, il faut comprendre la notion de synchronisation, …
Pour cette raison, j’estime que Gears ne doit pas devenir un pré-requis pour votre site : vous pouvez en utiliser les fonctionnalités, et proposer à vos utilisateurs n’en bénéficier… Mais votre site doit rester fonctionnel pour les utilisateurs n’ayant pas Gears installé !
Dans la même logique, Gears est sûrement plus adapté à un Back-office, réservé à un nombre restreint d’utilisateurs que vous pouvez facilement former, qu’à un Front-office ouvert à des milliers de visiteurs !

Notes

[1] Le travail hors-ligne sous Google Docs étant limité aux documents texte uniquement - du moins pour l’instant

[2] Cf What browsers and operating systems are supported by Google Gears?

[3] Si votre application est mise à jour plus souvent qu’elle n’est utilisée… C’est dommage ^^

[4] J’utiliserai parfois le terme “extension” (dénomination usuelle sous Firefox), et parfois le terme “plugin” (qui est plus habituel sous Internet Explorer). Les deux, pour cet article, sont à considérer comme synonymes.

Optimiser la comparaison de deux listes en PHP

Pascal MARTIN — Sat, 08 Dec 2007 21:00:00 +0100

Vous avez sûrement déjà rencontré une situation de ce genre :

Vous avez deux listes d’entités,
et vous voulez savoir combien des entités présentes dans la première liste sont aussi présentes dans la seconde.

Un exemple typique serait la question suivante :

Combien de mots présents dans une liste A sont aussi présents dans une liste B ?

Pour répondre à cette question, en utilisant une implémentation PHP, vous avez plusieurs solutions, plus ou moins naïves - et dépendant de votre niveau de connaissance du langage et de sa bibliothèque de fonctions.

Certaines de ces solutions sont rapides ; d’autres sont extrêmement lentes !

Au cours de cet article, nous étudierons plusieurs solutions, pour en arriver à la conclusion que la solution naïve, la première à laquelle un débutant penserait peut-être, est loin d’être optimale…

Principe

Je présenterai plusieurs solutions permettant de déterminer combien de mots présents dans une liste A sont aussi présents dans une liste B.

Ensuite, je fournirai les temps d’exécutions obtenus pour chacune de ces solutions, avec un grand nombre d’appels, afin de constater les différences de rapidité entre chaque solution.

Je terminerai par expliquer pour certains types de solutions sont plus rapides que les autres… Et pourquoi certaines implémentations sont à bannir.

Scénarios

Voici le cadre dans lequel les tests menés ci-dessous on été réalisés :

Machine

Tous mes tests ont été réalisés sur la machine suivante :

Core 2 Duo E6600 2.4 GHz
2Go de RAM
Disque dur SATA-2 10.000 rpm
PHP 5.2 utilisé en CLI
Extension Xdebug 2.0.1 utilisée pour le profiling

Jeux de données

Pour ces tests, le jeu de données utilisé est une extraction aléatoire^[1] du flux RSS de ce site.

Pour chaque article du flux, j’ai supprimé le maximum de données inutiles (codes sources, par exemple), afin de ne conserver, globalement, que les textes.

Vous trouverez en pièce jointe à cet article une archive contenant les script utilisés, ainsi que les données de tests.

Deux types de tests

Mon premier scénario de test est le suivant : Recherche du nombre de mots présents à la fois dans un article et un second.

Et le second est une généralisation du premier : Recherche dans N articles de tous les mots présents dans chacun des articles.
Plus précisément : recoupement du premier article avec tous les autres, recoupement du second article avec tous les autres, recoupement du troisième article avec tous les autres, …

Préparation des données

Voici les données utilisées pour mes tests :

Chargement des listes de mots

J’ai sur ma machine une série de fichiers nommées “article-X.txt”, correspondant à chacun à un article de ce blog.

Chaque fichier est constitué de la liste des mots, uniques, du billet correspondant, à raison de un mot par ligne.
Ces fichiers peuvent être chargés à l’aide de la fonction suivante :

function getArticles()
{
    for ($i=0 ; $i<=12 ; $i++)
    {
    	$articles[$i] = file("data/textes-articles/article-$i.txt", 
                                FILE_IGNORE_NEW_LINES | FILE_SKIP_EMPTY_LINES);
    }
    return $articles;
}

La variable $articles, utilisée par la suite pour tous les tests est obtenue de la manière suivante :

$articles = getArticles();

Calcul nombre de mots distincts

Pour information, voici les nombres de mots obtenus, pour chaque article :

$ wc -l textes-articles/*
  683 textes-articles/article-0.txt
  370 textes-articles/article-10.txt
  430 textes-articles/article-11.txt
  163 textes-articles/article-12.txt
  439 textes-articles/article-1.txt
  496 textes-articles/article-2.txt
  542 textes-articles/article-3.txt
  674 textes-articles/article-4.txt
  334 textes-articles/article-5.txt
  584 textes-articles/article-6.txt
  257 textes-articles/article-7.txt
  500 textes-articles/article-8.txt
  478 textes-articles/article-9.txt
 5950 total

(Puisqu’on a stocké un mot par ligne dans chacun des fichiers)

Présentation des différents modes de recherche :

Passons maintenant aux différents “moteurs de recherche” répondant à notre problématique…

Pour faciliter le développement, et, surtout, les tests de performance, chacun de ces moteur de recherche a été implémenté sous forme d’une fonction indépendante, l’idée étant de pouvoir comparer les temps d’exécution de chacune d’entre elles.

Double-parcours manuel

La première solution que nous allons voir est la plus naïve : celle à laquelle un développeur ne connaissant pas du tout PHP aurait probablement tendance à penser, puisqu’elle ne requiert aucune connaissance spécifique à PHP ; juste quelques notions d’algorithmique.

Cette portion de code répond exactement à la problématique : on parcourt tous les mots de la première liste, et, pour chacun de ces mots, on parcourt tous les mots de la seconde liste, en les comparant avec le mot courant issu de la première :

function compare_arrays_our($liste1, $liste2)
{
    $nbr = 0;
    foreach ($liste1 as $mot1)
    {
        foreach ($liste2 as $mot2)
        {
            if ($mot1 == $mot2)
            {
                $nbr++;
            }
        }
    }
    return $nbr;
}

Le gros problème de cette solution : elle est en O(n*m)… Et une double boucle telle que celle-ci, à 100% en PHP… C’est lent !

Le temps d’exécution de cette première solution est de 176 ms pour trouver le nombre de mots présents à la fois dans le premier et dans le second article.

Parcours manuel, et appel à `in_array`

Voici une seconde version de ce principe, mais on la boucle interne a été remplacée par un appel à la fonction php in_array :

function compare_arrays($liste1, $liste2)
{
    $nbr = 0;
    foreach ($liste1 as $mot1)
    {
        if (in_array($mot1, $liste2))
        {
            $nbr++;
        }
    }
    return $nbr;
}

Fondamentalement, en terme d’algo, cette solution est la même que la précédente.

Mais le remplacement d’une boucle 100% PHP par un appel à la fonction interne in_array améliore grandement la rapidité d’exécution : sur notre cas de test, on passe de 176 ms à 34 ms !

Qu’est-ce que cela nous apprend ?

Une boucle codée en PHP est beaucoup plus lente qu’une boucle codée au sein d’une fonction de la bibliothèque (codée en C, et compilée, plutôt qu’interprétée).

Parcours manuel de Hash, et appel à `array_key_exists`

A présent, plutôt que d’effectuer un parcours entier de la seconde liste, voyons si on ne peut pas optimiser cela…

Tous nos mots sont uniques, au sein de ladite liste ; on peut donc “retourner” celle-ci, pour avoir un tableau associatif dont les clefs sont les mots, et les valeurs… peu importe.

L’avantage ? SI PHP se débrouille bien, déterminer si une clef existe dans un tableau est plus rapide que de déterminer si une valeur existe : au sein d’un tableau non trié, il faut faire un O(n) pour trouver si une valeur existe…
Alors que si le tableau est organisé en mémoire sous forme d’un Arbre Binaire de Recherche, nous pouvons statuer sur l’existence d’un élément en O(log(n)) dans le cas moyen.

Avant de passer aux tests en eux-même, voici une petite fonction utilitaire, transformant une liste de mots en un tableau associatif au sein duquel les mots sont les clefs :

function toHash($liste)
{
    $hash = array();
    foreach ($liste as $mot) {$hash[$mot] = 1;}
    return $hash;
}

Et voici une première idée d’implémentation utilisant le principe que je viens de présenter :

function compare_arrays_hash_keys($liste1, $liste2)
{
    $hash2 = toHash($liste2);
    $nbr = 0;
    foreach ($liste1 as $mot1)
    {
        if (array_key_exists($mot1, $hash2))
        {
            $nbr++;
        }
    }
    return $nbr;
}

Nous passons de 34 ms avec la méthode précédente à 13 ms avec celle-ci.

Bien que nous prenions le temps de “retourner” la liste, nous avons donc divisé le temps d’exécution par pas loin de trois !

Tester l’existence d’une clef d’un tableau, avec array_key_exists est plus rapide que de tester la présence d’une valeur dans ce même tableau, avec in_array - même s’il faut retourner le tableau pour cela !

Attention : ici, on peut se permettre cette amélioration parce que chaque mot n’est présent qu’une seule fois dans la liste ; on n’a dont jamais deux mots qui veulent la même place en clef du tableau associatif.

Comptage du nombre d’élément dans la liste d’intersections des deux tableaux : `array_intersect`

Maintenant, par curiosité, voyons ce que nos pourrions faire pour totalement supprimer les parcours de tableaux côté PHP.

Pour rappel, nous voulons compter combien de mots sont présents à la fois dans une liste A et dans une liste B…

En PHP, pour obtenir une liste d’éléments se trouvant simultanément dans deux listes, il convient d’utiliser la fonction array_intersect.
Et, pour compter combien d’éléments sont présents au sein de cette liste d’intersection, on peut utiliser count.

Ce qui nous donne :

function compare_arrays_intersect($liste1, $liste2)
{
    $nbr = 0;
    $nbr = count(array_intersect($liste1, $liste2));
    return $nbr;
}

Et, avec cette solution, on descend à 1.089 ms - soit 13 fois plus rapide que la solution précédente !

Ici, le gain vient du fait que nous n’effectuons plus aucune boucle en PHP : les boucles sont réalisées en interne, par des fonctions de la bibliothèque PHP, qui ne sont pas codées en PHP, mais en langage compilé.

Test de l’existence de clefs dans un Hash construit “à la main” : `isset`

Une autre solution : nous reprenons l’idée utilisée plus haut, à savoir, tenter de travailler sur les clefs d’un tableau associatif, plutôt que sur les valeurs d’une liste, en espérant que PHP gère cela intelligemment.

Par contre, cette fois-ci, plutôt que de faire appel à array_key_exists pour déterminer si un mot est présent dans le tableau associatif (ie, si un mot est présent comme clef de celui-ci), nous allons utiliser la construction de langage isset^[2].

L’idée étant qu’appeler une fonction interne au langage sera peut-être plus rapide qu’appeler une fonction de la bibliothèque PHP - de la même manière qu’appeler une fonction de la bibliothèque PHP était plus rapide qu’appeler une fonction définie par l’utilisateur.

function compare_arrays_hash_isset($liste1, $liste2)
{
    $hash2 = toHash($liste2);
    $nbr = 0;
    foreach ($liste1 as $mot1)
    {
        if (isset($hash2[$mot1]))
        {
            $nbr++;
        }
    }
    return $nbr;
}

Effectivement,nous y gagnons en performances : la version basée sur l’utilisation de array_key_exists durait 13 ms ; celle-ci ne met plus que 0.696 ms !

Tester l’existence d’une clef d’un tableau avec isset est plus rapide que de tester son existence par un appel à array_key_exists

Attention : isset et array_key_exists ne font pas exactement la même chose !
En particulier, isset renverra false si la valeur correspond à la clef demandée existe, mais vaut null !

Test de l’existence de clefs dans un Hash construit via `array_flip`

La solution proposée juste au-dessus commence à nous donner des résultats intéressants en termes de performance… Mais il doit encore être possible de faire mieux…

Elle commence par “retourner” la liste de un tableau associatif, dont les clefs sont les mots de chaque liste… Et ceci était fait via un appel à une fonction développée par nos soins…

Hors, nous avons vu plus haut que ré-inventer la roue n’était pas optimal question performances… Fouillons donc un peu dans la documentation de la bibliothèque PHP, à la recherche d’une fonction qui pourrait effectuer ce “retournement” pour nous…
Et une telle fonction existe : array_flip.

En la mettant en application, voici le code obtenu pour notre fonction de comparaison :

function compare_arrays_hash_flip_isset($liste1, $liste2)
{
    $hash2 = array_flip($liste2);
    $nbr = 0;
    foreach ($liste1 as $mot1)
    {
        if (isset($hash2[$mot1]))
        {
            $nbr++;
        }
    }
    return $nbr;
}

Et là, nous descendons à 0.488 ms ! Soit une fois et demie plus rapide que la version précédente, en écrivant moins de code !

Le gain ici est l’utilisation d’une fonction de la bibliothèque PHP pour “retourner” la liste, plutôt que d’une boucle “à la main”, en PHP. Il s’agit donc encore du même type de gain que déjà rencontré plusieurs fois !

Pour rappel, la première solution proposée demandait 176 ms pour s’exécuter ; celle-ci demande moins d’une demi-milli-seconde !

Résultats des comparaisons

Mettons maintenant côtes-à-côtes les appels à chacune de ces fonctions, pour déterminer lesquelles sont performantes et lesquelles ne le sont pas.

Premier scénario de tests

Code de test

Voici le premier scénario de tests utilisé ; celui dont les résultats ont été utilisés plus haut pour comparer chacune des solutions proposées :

$nbrIterations = 1;

Le principe est simple : on appelle $nbrIterations fois chacune des fonctions pour comparer les deux premiers articles :

$liste1 = $articles[0];
$liste2 = $articles[1];

for ($i=0 ; $i<$nbrIterations ; $i++)
{
    $nbr1 = compare_arrays_our($liste1, $liste2);
    $nbr2 = compare_arrays($liste1, $liste2);
    $nbr3 = compare_arrays_hash_keys($liste1, $liste2);
    $nbr4 = compare_arrays_intersect($liste1, $liste2);
    $nbr5 = compare_arrays_hash_isset($liste1, $liste2);
    $nbr6 = compare_arrays_hash_flip_isset($liste1, $liste2);
}

Et voici les résultats obtenus :

Pour une itération

Les fonctions étant classées, de haut en bas, par durée d’exécution décroissante, je pense que cette capture d’écran parle d’elle-même…

Pour 100 itérations : Callgraph

Et voici, pour les plus visuels d’entre vous, ce que donne le graphe d’appels :

Vous noterez que l’outil que j’utilise ne présent que les fonctions durant plus de 1% du temps d’exécution du test…
Et ici, seules trois des six solutions de recherche proposées sont affichées ! Parlant, n’est-ce pas ?

En supprimant les deux méthodes les plus coûteuses, 100 itérations

En lançant 100 fois le test, en supprimant les deux solutions les plus coûteuses, voici ce que l’on obtient :

Et une autre représentation graphique serait la suivante :

Les tailles de chacun des blocs sont proportionnelles aux temps d’exécution de chaque méthodes dont ils portent les noms…

Voyant ceci, quelle solution adopteriez-vous ? Ou plutôt, quelle solution n’adopteriez-vous pas ?

Second scénario de test

Code de test

Et voici le code du second scénario :

Ici, on compare tous les articles les uns avec les autres - et encore une fois, avec un nombre d’itérations paramétrable.

foreach ($articles as $liste2)
{
    foreach ($articles as $liste1)
    {
        for ($i=0 ; $i<$nbrIterations ; $i++)
        {
            compare_arrays_our($liste1, $liste2);
        }
        
        for ($i=0 ; $i<$nbrIterations ; $i++)
        {
            compare_arrays($liste1, $liste2);
        }
        
        for ($i=0 ; $i<$nbrIterations ; $i++)
        {
            compare_arrays_hash_keys($liste1, $liste2);
        }
        
        for ($i=0 ; $i<$nbrIterations ; $i++)
        {
            compare_arrays_intersect($liste1, $liste2);
        }
        
        for ($i=0 ; $i<$nbrIterations ; $i++)
        {
            compare_arrays_hash_isset($liste1, $liste2);
        }
        
        for ($i=0 ; $i<$nbrIterations ; $i++)
        {
            compare_arrays_hash_flip_isset($liste1, $liste2);
        }
    } // Fin second parcours
} // Fin premier parcours

(Oui, on aurait pu faire plus élégant, notamment sur les boucles d’itérations…)

Notez que, puisque l’on compare tous les articles les uns par rapport aux autres, et qu’il y avait 13 articles dans le jeu de test, le nombre d’itérations est à multiplier par 13*13 = 169 pour obtenir le nombre d’appels à chacune des fonctions testées !

Voici les temps d’exécution obtenus pour 10 itérations (1690 exécutions)

Les résultats obtenus sont proches des précédents : peut-être des variations mineures, mais l’idée globale est proche : ce sont toujours les mêmes implémentations qui sont les plus lentes… Et les autres qui sont les plus rapides.

Et en retournant la liste de mots communs aux deux articles ?

Pour finir, voici une comparaison des mêmes fonctions, mais modifiées pour retourner la liste des mots communs aux deux articles, plutôt que uniquement leur nombre.

Le scénario de test est le suivant :

$liste1 = $articles[0];
$liste2 = $articles[1];

for ($i=0 ; $i<$nbrIterations ; $i++)
{
    $tab1 = compare_arrays_our($liste1, $liste2);
    $tab2 = compare_arrays($liste1, $liste2);
    $tab3 = compare_arrays_hash_keys($liste1, $liste2);
    $tab4 = compare_arrays_intersect($liste1, $liste2);
    $tab5 = compare_arrays_hash_isset($liste1, $liste2);
    $tab6 = compare_arrays_hash_flip_isset($liste1, $liste2);
}

Par sécurité, on vérifie que tous les appels ont retourné la même liste :

var_dump(
    array_diff(
                $tab1, $tab2, $tab3, 
                $tab4, $tab5, $tab6
              )
        );

Et… oui :

array(0) {
}

Et les résultats, sur 100 it”rations, sont les suivants :

Soit le même type de graphe que ceux obtenus précédemment, lorsque nous ne retournions que les nombres de mots en commun.

Avec une différence tout de même : les temps d’exécution sont légèrement supérieurs à ceux obtenus précédemment - mais il fallait s’y attendre : on doit construire la liste à retourner, plutôt que d’effectuer un simple comptage…

Conclusions

Après avoir vu les résultats obtenus pour différents types de méthodes de comparaisons de tableaux en PHP, ou, surtout, après avoir constaté les écarts énormes entre certains types de solutions, que peut-on ajouter en conclusion, qui soit plus parlante que les graphiques présentés plus haut ?

LE point dont il faut se souvenir, je pense, est le suivant : n’effectuez pas de parcours inutiles !

Les deux boucles foreach de notre première solution sont une catastrophe, d’un point de vue performances !
Même si l’idée d’effectuer un double parcours n’est pas fantastique, en utilisant in_array pour remplacer le foreach interne et la comparaison, on a effectué le plus gros gain de tout cet article !

D’où cette première conclusion :

Ne réinventez pas la roue : utilisez à bon escient les fonctions de la bibliothèque PHP.

Considérant qu’elles sont codées en C, et utilisées tous les jours de manière intensives, il est à parier qu’elles seront plus performantes que vos ré-implémentations en PHP.

Le second plus gros gain a été réalisé en testant l’existence de clefs dans un Hash, plutôt qu’en parcourant une liste à la recherche d’une valeur.
Là, il s’agit de savoir que la recherche d’une clef est plus rapide que la recherche d’une valeur^[3].

D’où cette seconde recommandation :

Utilisez au maximum les spécificités du langage avec lequel vous travaillez.

Comment penser à ce genre “d’astuce” ? Souvenez-vous de vos cours d’algorithmique, lorsque vous travaillez sur les arbres binaires et/ou les tables de Hachage…
Même sans savoir comment sont, en interne, implémentés les tableaux associatifs de PHP, il semble probable que ce soit à l’aide d’une solution bien plus optimisée qu’une liste plate !

Notes

[1] J’allais dire “assez ancienne” (ça fait des mois que cet article est dans mes cartons et que je parviens à me décider à le terminer…), mais je suis reparti d’une version à jour avant de le publier ; donc, les données de tests correspondent à une extraction du flux RSS du site, datant de début décembre 2007.

[2] “Construction de langage étant une traduction de “language construct” - quelque chose de directement inclu au langage, autrement dit.

[3] Attention, cela dit, isset n’est pas non plus la solution magique à tous les problèmes ; ne serait-ce parce qu’elle renvoi true quand on l’appelle sur une variable valant null…

Pascal MARTIN (n+1).zéro

Bench PHP 5.2 vs PHP 5.3

Méthodologie

Logiciels testés

Versions de PHP testées

Deux séries de tests

Méthodologie

Résultats obtenus sans APC

Wordpress

Drupal

Quickstart Zend Framework

Résultats obtenus avec APC

Wordpress

Drupal

Quickstart Zend Framework

Conclusion

PHP 5.3 : gain de performances !

Quel intérêt ?

Disclaimer

Aller plus loin ? D’autres tests ?

Notes

Google Gears : accélérer le chargement d'une application en cachant les fichiers statiques

Travailler hors ligne ?

Introduction : accès Internet, ou isolement ?

Google Gears

Une série d’articles sur Google Gears

Application utilisée pour cet article

Une application simple

Des temps de chargement non satisfaisant ?

Premiers pas avec Google gears

Inclusion du fichier gears_init.js

Installation de Gears

Activation de gears

Autorisation pour votre site

Instanciation des composants gears

Stocker les fichiers statiques sur le poste client

ManagedStore et fichier manifest

Résultat

Suivre la mise à jour d’un ManagedStore

oncomplete

onprogress

onerror

Utiliser ces gestionnaires

Aller plus loin

Forcer la détection de mise à jour

Désactiver (momentanément) l’utilisation du stockage local

Désactiver gears pour votre site

Recollons les morceaux

Squelette de page HTML

LocalServer et ManagedStore

Actions au chargement de la page

Créer une instance de ManagedStore

Activation de gears pour notre site

Mise à jour des fichiers stockés localement

Fichier manifest

Désactiver gears

Avant de passer à la suite…

Notes

Optimiser la comparaison de deux listes en PHP

Principe

Scénarios

Machine

Jeux de données

Deux types de tests

Préparation des données

Chargement des listes de mots

Calcul nombre de mots distincts

Présentation des différents modes de recherche :

Double-parcours manuel

Parcours manuel, et appel à in_array

Parcours manuel de Hash, et appel à array_key_exists

Comptage du nombre d’élément dans la liste d’intersections des deux tableaux : array_intersect

Test de l’existence de clefs dans un Hash construit “à la main” : isset

Test de l’existence de clefs dans un Hash construit via array_flip

Résultats des comparaisons

Premier scénario de tests

Code de test

Pour une itération

Pour 100 itérations : Callgraph

En supprimant les deux méthodes les plus coûteuses, 100 itérations

Parcours manuel, et appel à `in_array`

Parcours manuel de Hash, et appel à `array_key_exists`

Comptage du nombre d’élément dans la liste d’intersections des deux tableaux : `array_intersect`

Test de l’existence de clefs dans un Hash construit “à la main” : `isset`

Test de l’existence de clefs dans un Hash construit via `array_flip`