Test de l'indexation sous altern :
sur les petits articles, l'indexation double au moins le temps
de calcul de la page (de 4 à 9 secondes par exemple).
sur les gros articles, il n'y arrive tout simplement pas
(ça n'a pas l'air d'un timeout, peut-être un dépassement de
ressources côté PHP... ?).
a+
@ Antoine Pitrou (pitrou@free.fr) :
Test de l'indexation sous altern :
sur les petits articles, l'indexation double au moins le temps
de calcul de la page (de 4 à 9 secondes par exemple).sur les gros articles, il n'y arrive tout simplement pas
(ça n'a pas l'air d'un timeout, peut-être un dépassement de
ressources côté PHP... ?).
J'ajouterai une couche de doute : si le moteur de recherche est restreint
aux petits sites, pourquoi ne pas utiliser tout bêtement la requete
select id_article from spip_articles where texte like '%mot%'
???
A chacun son boulot, et celui de mysql est d'indexer, justement...
-- Fil
Salut,
Je viens d'installer une nouvelle version de spip-index.php3. Elle devrait être notablement plus rapide:
- j'ai sucré le propre();
- plutôt que de tester sur une tripotée de caractères à chaque ereg, je commence par remplacer une fois tous les caractères "non-texte" par un espace blanc, du coup ça me fait des tests d'ereg beaucoup plus simples.
- chaque mot n'est plus indexé qu'une fois par rapport à sa situation dans le texte (si on utilise 10 fois "kosovo" dans le corps de l'article, c'est pondéré une seule fois - ce qui d'ailleurs est plus logique).
J'ajouterai une couche de doute : si le moteur de recherche est restreint
aux petits sites, pourquoi ne pas utiliser tout bêtement la requeteselect id_article from spip_articles where texte like '%mot%'
C'est ce que je fais dans uZine (sauf que c'est beaucoup plus hardu que ça, car il faut ajouter un test énorme derrière pour classer les résultats par pertinence). Cependant, là c'est sûr, cette méthode surcharge énormément la machine (recherche dans l'intégralité de la base).
Au contraire, là c'est la phase d'indexation qui charge, et je crois qu'on peut espérer l'optimiser très largement. Et, dans ce cas, l'indexation doit permettre de tourner même sur un gros site, parce que la recherche s'effectue en une unique requête mySQL dans des tables totalement indexées, et sans aucun calcul supplémentaire (le "poids" de chaque mot est calculé lors de l'indexation).
J'ai ajouté la mention "pas pour les gros sites" dans l'immédiat. Mais si on arrive à optimiser suffisamment la phase d'indexation, ça n'a pas de raison de ne pas tourner sur un gros site (sauf dépassement des limites de taille autorisée de la base).
ARNO* wrote:
- chaque mot n'est plus indexé qu'une fois par rapport à sa situation
dans le texte (si on utilise 10 fois "kosovo" dans le corps de
l'article, c'est pondéré une seule fois - ce qui d'ailleurs est plus
logique).
Heu, non, c'est bcp - logique à mon avis : dans tous les moteurs de
recherche, la pertinence du résultat dépend du nbre d'occurences.
Je viens d'installer une nouvelle version de spip-index.php3. Elle
devrait être notablement plus rapide:
Bon, ça rame tjs pas mal. J'ai en ai mis une plus rapide (utilisant
split()). Pas génial. 4-5 secondes pour indexer un gros texte (50 ko)
sur altern. La solution, comme je le disais dans un autre mail :
indexer lors des modifs depuis l'espace privé, et dans l'espace public
seulement quand l'article n'est pas déjà indexé.
a+
Salut,
Comme ça commence à faire une tripotée de trucs par rapport à la beta 6, je passe à la beta 7, même s'il n'y a pas de modification de la base. Tout porte ici sur l'interface.
Attention avant de crier au crime: un bon nombre de liens en mode texte seront remplacés bientôt par des petites icones, ce qui devrait alléger la présentation. De même, la gestion de la largeur des colonnes, pour l'instant c'est à la "va comme je te pousse": c'est pas le plus joli, m'enfin ça fonctionne sous Netscape sans problème.
L'idée, ici, c'est d'unifier la présentation des listes, et de changer leur fonctionnement: jusqu'ici, un certain nombre de liste n'étaient destinées qu'à l'information, avec éventuellement pour les admins un bouton "modifier". Désormais, il s'agit d'avoir des listes utiles à la navigation, et cela pour les rédacteurs également.
Vous aviez peut-être noté que les fiches des mots-clés permettaient de passer d'un article à un autre article, car ces fiches contenaient la liste des articles liés. Désormais, les auteurs offrent la même possibilité.
Le boulot délicat de cette nuit, ça a donc été de modifier complètement l'affichage des auteurs (voir par exemple la page "Les rédacteurs", entièrement redessinée. Notez que je l'ai conçue dans l'optique d'un site comme uZine, qui a tellement de rédacteurs que la page complète n'était plus utilisable... D'où les découpages. Au fait, les entêtes de colonnes sont cliquables.)
Vous constaterez que les "fiches" des auteurs sont désormais accessibles à tous (y compris aux rédacteurs) et qu'elles présentent une liste des articles de l'auteur concerné. Bien entendu (comme pour les fiches des mots-clés), seuls les admins disposent du formulaire permettant de modifier les informations.
Là où ça devient plutôt amusant: si vous naviguez dans les mêmes pages avec deux accès différents, un en admin, l'autre en rédacteur (faut 2 butineurs), vous verrez que le décompte des articles pour les auteurs et les mots-clés sont différents selon l'autorisation d'accès; en effet, pour les rédacteurs, seuls les articles publiés ou proposés à la publication étant accessibles, le nombre d'articles est inférieur à celui des admins.
En mode rédacteur, l'effet recherché est beaucoup plus clair: les listes d'auteurs et de mots-clés servent uniquement de passerelles entre les articles; donc les fiches des auteurs et des mots-clés reliés à aucun article ne sont pas acessibles.