Lenteurs + erreur 500 avec le bloc Recherche v1.0

[jean-charles]

Bonjour,
Nous sommes en 1.3.2.3 et rencontrons énormément d'erreur 500 lorsqu'on lance une recherche.

Liste de ce qui a été fait:

- Désactivation dans Position sur la page de recherche de tous les modules qui envoient des requêtes PHP ou qui sont remis en cause dans les forums (Fabricants, Promotions, Meilleures ventes, Catégories, Nouveaux produits)
- Désactivation du SEO avec regénération du .htaccess (.htaccess automaticaly generated by PrestaShop e-commerce open-source solution)
- Vider le cache dans /tools/smarty/compile
- smarty.config.inc.php : $smarty->force_compile = false;
- bug_tracker/view/5783/ search.tpl has changed and search variables assigned too. query => search_query and tag => search_tag but in search.tpl some variable names are wrong:
- bug_tracker/view/6000/ W3c validation of search result page, error in link.php Edit: instead ‘&’ there should be ‘&’

Le type de requête en question qui plante le serveur :
SELECT p.*, pl.`description`, pl.`description_short`, pl.`link_rewrite`, pl.`meta_description`, pl.`meta_keywords`, pl.`meta_title`, pl.`name`, p.`ean13`, i.`id_image`, il.`legend`, t.`rate` FROM `ps_product` p LEFT JOIN `ps_product_lang` pl ON (p.`id_product` = pl.`id_product` AND pl.`id_lang` = 1) LEFT JOIN `ps_image` i ON (i.`id_product` = p.`id_product` AND i.`cover` = 1) LEFT JOIN `ps_image_lang` il ON (i.`id_image` = il.`id_image` AND il.`id_lang` = 1) LEFT JOIN `ps_tax` t ON t.`id_tax` = p.`id_tax` WHERE (`reduction_price` > 0 OR `reduction_percent` > 0) AND (`reduction_from` = `reduction_to` OR (`reduction_from` <= '2010-11-16 11:11:42' AND `reduction_to` >= '2010-11-16 11:11:42')) AND p.`active` = 1 AND p.`id_product` IN ( SELECT cp.`id_product` FROM `ps_category_group` cg LEFT JOIN `ps_category_product` cp ON (cp.`id_category` = cg.`id_category`) WHERE cg.`id_group` = 1 ) ORDER BY RAND() LIMIT 1

Cette requête a été lancée directement en phpmyadmin en commande sql et ca répond en 0,0651 sec.

Le site contient 17000 produits (X2 en anglais), il y a rarement plus de 10 visiteurs en ligne, nous sommes sur un serveur dédié et l'indexage des produits a été correctement reconstruit, à priori.
Pourquoi la recherche en admin donne des résultats immédiats et le bloc recherche ne trouve rien ou plante ?
Pourquoi la recherche donne t'elle de bons résultats sur le champ Résumé et rien sur le Nom du produit ?
Est-ce que l'achat d'un module de recherche sur Prestastore changerait la donne ?
Quelqu'un rencontre ce type de problèmes ??

[Patric]

Merci de réécrire ton titre en minuscules, conformément aux règles du forum.

[abmag]

En fait le problème ne vient pas de la requête en générale mais de l'indexation des mots clés

Si dans le moteur de recherche la requête commence par un mot de deux lettres (la, le, les, un etc.....) le moteur de recherche ne retourne aucune donnée si ce mot n'est pas exclu de l'indexation.
Par defaut PS exclu

le|les|de|et|en|des|les|une|

mais pas

la|un|au|

par exemple

Je m'explique

lumière de la ville renverra une réponse
les lumières de la ville renverra une réponse
la lumière dans la ville ne renverra rien

Il faut donc renseigner de manière exhaustive le champs mots exclus

La taille des mot à indexer doit avoir également son importance pour affiner l'optimisation

Un tel comportement s'apparente quand même à un bug

En cas d'absence de réponse un serveur apache bien réglé devrait afficher une page ne comportant aucun produit et un message d'excuse.

L'erreur 500 (time out) quand il n'y as pas de réponse à afficher et la mise à la rue du serveur est une autre histoire

à voir certainement du côté du httpd.conf ou php.ini

Ceci dit l'architecture du moteur de recherche de PS et son mode d'indexation ne sont pas sans reproche. Les tables générées sont d'une lourdeur excessive

Pour une base de 17000 produits (sans déclinaisons) dont les descriptions et le tagage n'est pas complet les deux tables concernées pèsent déjà 43 Mo

Pour les boutiques avec de très nombreux articles et qui nécessitent un vocabulaire très riche dans la description des produits, il faut mieux prévoir un gros moteur sous le capot pour ne pas mettre à plat le serveur

[abmag]

J'en rajoute une petite couche côté bug

Le dysfonctionnement est reproductible sur le site de démo

http://www.prestashop.com/demo/

tapez

la liberté
le liberté
liberté

la liberté rien
mais pour les deux autres (même le liberté), c'est OK

[Patric]

Si c'est bien un bug, merci de le signaler dans le bug tracker.

[abmag]

C'est fait

http://www.prestashop.com/bug_tracker/view/6076/

[abmag]

Le bug a été répertorié comme mineur dans le bug tracker
Un bug similaire signalé dans la version 1.4.x semble avoir été rectifié
http://www.prestashop.com/bug_tracker/view/6035/ (Exclude short word from the search)
A quand une rev pour la branche 1.3.x ? >

[Bruno Leveque]

Bonsoir,

Les deux bugs ont été marqués comme résolus.

Pouvez-vous télécharger la dernière version SVN et nous confirmer que tout est ok ?

Cordialement,

[mathieu2]

et pour la question de lenteur ? que dois-t-on faire ? ce script plante régulièrement mon serveur mysql !

[Bruno Leveque]

Bonsoir,

Le script exécute ses requêtes par vague, donc à priori pas de plantage avec cette nouvelle version.

Si tel est le cas, nous serons ravis (la dev team) de régler cela, il faudra poster un bug avec un maximum de détails sur le bug tracker et nous transmettre des codes en MP.

Merci par avance,