Footnotes*

Bon d’accord, c’est peut-être un peu exagéré mais tout ça pour vous dire qu’on a bien avancé sur les performances en temps de réponse de notre plugin PMB/SPIP.

Merci à la Dream Team (Florent, Erwann, Arnault et autres femmes et hommes de l’ombre) pour leur travail, parfois ingrat.

Alors de quoi s’agit-il ?

Depuis qu’il nous a pris la folle idée d’interfacer SPIP et PMB plutôt que de nous contenter du module OPAC de PMB, on a connu plusieurs versions.

Pour celles et ceux qui n’ont pas suivi les épisodes précédents :

1. première version du plugin début 2007 (avec SPIP 1.9 à l’époque !) : seul le flux RSS généré par PMB était récupéré dans SPIP pour la page des « Nouveautés ». Un début prometteur mais modeste (c’était le bon vieux temps de www.3bm.fr). En effet, l’interrogation catalogue basculait vers l’OPAC de PMB donc une autre fenêtre, pas idéal en terme d’ergonomie et d’identité visuelle, bien que fonctionnel.
2. refonte totale du plugin avec SPIP 2 fin 2008, pour un nouveau site mis en ligne début 2009 et relooké, le nouveau graphisme étant dû à Thomas Rosset (www.risom.fr). Seul hic, les Web Services n’étaient pas encore opérationnels chez PMB donc nous avions privilégié une solution transitoire pour avancer quand même. Cela voulait dire que SPIP relançait une interrogation de l’OPAC et importait les résultats dans son interface graphique. C’était suffisant pour répondre à nos besoins basiques mais on en voyait vite les limites : temps de réponse médiocres, instabilité diverses (souvenez-vous de nos couvertures surprises…), pas d’accès aux critères de recherche détaillée etc.
3. fin septembre 2009, quelques jours avant l’inauguration en grandes pompes des superbes nouveaux locaux de PMB Services (super soirée d’ailleurs, merci), la version de PMB avec les Services Web était libérée et on commençait à s’y attaquer. Chouette, du nouveau, ça avançait bien !
4. depuis on n’arrête pas : y a du mieux mais aussi des bugs qui se révèlent d’où des corrections, des retours en arrière avec des fonctions qui manquent et puis des nouvelles qui arrivent. Bref on ne s’ennuie pas et c’est assez enthousiasmant de bosser en trio avec PMB Services et OpenStudio sur ce projet.

Aujourd’hui, les temps de réponse ont été bien améliorés, même si on continue à s’y pencher.

Voici ce qu’on avait avant l’optimisation, du point de vue d’Arnault chez OpenStudio :

Deux tests (résultats variables, je donne des durées à titre
indicatif):

- rechercher « victor hugo » sur les titres avec
*pmbesOPACAnonymous_simpleSearch()* -> 23 secondes
puis
pmbesOPACAnonymous_fetchSearchRecords($searchId,0,10, »pmb_xml_unimarc », »iso-8859-1″)
-> 21 secondes supplémentaires

- rechercher « victor hugo » sur les titres avec
*pmbesOPACAnonymous_advancedSearch()* -> 19 secondes
puis
pmbesOPACAnonymous_fetchSearchRecords($searchId,0,10, »pmb_xml_unimarc », »iso-8859-1″)
-> 16 secondes supplémentaires

la même recherche sur l’OPAC de PMB : environ 8 secondes.

Et voici ce qu’on a maintenant, testé par Florent chez PMB Services :

A mon tour !! J’ai fait quelques tests et je viens d’optimiser une partie de la gestion du cache PMB. Les temps de réponse on chuté :
Durée de la recherche: 3 secondes
Durée du rapatriement: 2 secondes
Durée totale: 5 secondes

Deuxième appel :
Durée de la recherche:  1 secondes
Durée du rapatriement: 2 secondes
Durée totale: 3 secondes
Durée de la recherche: 4 secondes
Durée du rapatriement: 3 secondes
Durée totale: 7 secondes

Deuxième appel :
Durée de la recherche: 1 secondes
Durée du rapatriement: 1 secondes
Durée totale: 2 secondes

Il y a encore des optimisations possibles je pense !

Comme je vous le disais, on a jamais fini, mais c’est ce qui fait l’intérêt de tout ça, non ?

Bon attention, ça ne règle pas le problème du tri des résultats peu pertinent et qui sera très prochainement corrigé, pour l’instant c’est juste plus rapide. C’est peut-être un détail pour vous mais pour nous …