[spip-dev] rapidite moteur de recherche

Dev
1

Je migre le moteur de recherche du diplo (en anglais, dans un premier
temps), de ht://dig vers spip. C'est l'occasion d'un comparatif
performances. Pour ce qui est de la présentation, "y'a pas photo", c'est
bien mieux sous spip. (cf. URLs ci-dessous).

En terme de vitesse, en revanche, on est 5 fois plus lents que htdig, que ce
soit (comme ci-dessous) avec un mot qui donne pas mal de résultats qu'avec
un mot qui donne un résultat vide.

Le squelette (basé sur http://rezo.net/spip-dev/contrib/Adrien/) contient
deux boucles {recherche} : la première boucle servant à calculer le nombre
total de documents trouvés, la seconde à présenter une page de ces
résultats.

En commentant la première boucle, on ne descend qu'à 160ms, soit 24ms
de moins (seulement) qu'avec deux boucles. La lenteur (toute relative)
constatée est donc ailleurs.

fil@miel~> /usr/sbin/ab ‘http://MondeDiplo.com/search?s=jerusalem’ -n10
...
Concurrency Level: 1
Time taken for tests: 1.839 seconds
Requests per second: 5.44 [#/sec] (mean)
Time per request: 183.90 [ms] (mean)
Time per request: 183.90 [ms] (mean, across all concurrent requests)
Transfer rate: 54.00 [Kbytes/sec] received

Connnection Times (ms)
              min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 127 183 19.7 190 196
Waiting: 127 183 19.6 190 195
Total: 127 183 19.7 190 196

Percentage of the requests served within a certain time (ms)
  50% 190
  66% 190
  75% 190
  80% 191
  90% 196
  95% 196
  98% 196
  99% 196
100% 196 (last request)

fil@miel~> /usr/sbin/ab ‘http://www.monde-diplomatique.fr/cgi-bin/htsearch?config=htdigen&words=jerusalem’ -n10
...
Concurrency Level: 1
Time taken for tests: 0.428 seconds
Complete requests: 10
Failed requests: 0
Broken pipe errors: 0
Total transferred: 181210 bytes
HTML transferred: 179310 bytes
Requests per second: 23.36 [#/sec] (mean)
Time per request: 42.80 [ms] (mean)
Time per request: 42.80 [ms] (mean, across all concurrent requests)
Transfer rate: 423.39 [Kbytes/sec] received

Connnection Times (ms)
              min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 41 42 0.7 42 44
Waiting: 41 42 0.7 42 44
Total: 41 42 0.7 42 44

Percentage of the requests served within a certain time (ms)
  50% 42
  66% 42
  75% 43
  80% 43
  90% 44
  95% 44
  98% 44
  99% 44
100% 44 (last request)

-- Fil

2

Hello,

En commentant la première boucle, on ne descend qu'à 160ms, soit 24ms
de moins (seulement) qu'avec deux boucles. La lenteur (toute relative)
constatée est donc ailleurs.

J'étais en train de tester ça hier, par curiosité. La requête MySQL elle-même
prend environ 0.05 s. Le reste provient certainement du calcul de la page
(squelette, etc.).
Une page basique (du type http://rezo.net/~antoine/spip/breve.php3?id_breve=535)
prend 110 ms à calculer, ce qui confirme tes résultats.

Amicalement

Antoine.

3

le Mon, 11 Mar 2002 19:04:15 +0100
Fil <fil@rezo.net> écrivait :

En commentant la première boucle, on ne descend qu'à 160ms, soit 24ms
de moins (seulement) qu'avec deux boucles. La lenteur (toute relative)
constatée est donc ailleurs.

htdig utilise mifluz comme indexeur, écrit par Loïc Dachary. C'est
écrit en C et franchement très optimisé. Loïc m'avait décrit, il y a
longtemps, son algo et sa structure de donnée... ce dont je me
souvient c'est que c'étaitbastucieux et TRES efficace.

Bref ... si tu veux accélerer les choses sur le moteur de recherche de
spip, je te conseille d'utiliser la librairie mifluz ; une lib php
l'utilisant existe. Je sais que Fabien (linuxfr) l'utilisait .. je lui
demanderais où elle se trouve.

4

@ Antoine Pitrou <antoine@rezo.net> :

Vu les résultats obtenus directement sous mysql, ce n'est pas trop le
facteur limitant (en tout cas pas avec le corpus du diplo anglais : mille
documents déclenchant 600 000 entrées dans l'index)

Autre élément de comparaison entre les deux systèmes : la taille occupée par
les données d'indexation.

Sous ht://dig, ces données occupent 63M de disque dur ; sous spip, en
intégrant spip_index_articles + spip_index_dico, seulement 12.3M
(spip_articles fait 14M).

-- Fil

5

le Tue, 12 Mar 2002 00:01:24 +0100
Fil <fil@rezo.net> écrivait :

Sous ht://dig, ces données occupent 63M de disque dur ; sous spip, en
intégrant spip_index_articles + spip_index_dico, seulement 12.3M
(spip_articles fait 14M).

Ca, c'est normal .. En terme d'algorithmie, le choix est toujours
entre le temps et l'espace. Dans le cas d'htdig et de mifluz qui est
derrière, c'est clairement le choix du meilleur temps par rapport à
l'espace occupé qui a été fait.

Dans le cas de spip, il y a peut-être un problème d'index.
Quelques EXPLAIN sur les requètes correspondant au moteur de recherche
t'indiqueront les index utilisés ainsi que de précieuses indication
sur les colonnes qui profiteraient d'un index.

Sinon, pour les champs de type BLOB/TEXT, as tu essayé d'utiliser
l'indexeur full text de mysql avec des requètes utilisant MATCH ?

Au fil des versions, il devient vraiment performant.

6

Bonjour,

Je viens d'installer le dernier spip CVS et upgrader ma base.

Et j'ai le message d'erreur suivant dans article_edit.php3
Warning: Supplied argument is not a valid MySQL result resource in
/home/e-smith/files/ibays/spiptest/html/ecrire/inc_documents.php3 on
line 285

Apparament, la requete SQL de la fonction pave_documents

SELECT type.extension AS extension, COUNT(doc.id_document) AS cnt
    FROM spip_types_documents AS type, spip_documents AS
doc, spip_documents_articles AS lien
    WHERE lien.id_article=$id_article AND doc.id_document =
lien.id_document AND doc.id_type = type.id_type
    GROUP BY doc.id_type

Recherche une colonne ID_TYPE qui n'existe pas dans la table
SPIP_DOCUMENTS.

Manquerait-il quelque chose dans l'upgrade des tables ?

Pierre