Recherche fulltext aie aie 15 minutes

38 réponses

Page 1 2

Auteur	Message
DarkSquall \| Membre Inscrit le : 27/08/2005	# Le 02/04/2008 à 17:39 Hello, J'ai atteint le record mondial de la requête la plus longue. "Générée en : 888.67506 secondes." J'ai recherché "mot" en fulltext sur une table d'environ 1 500 000 enregistrements. 140 000 enregistrements ont étés retournés... (Je n'utilise pas de cache sur ces requêtes) la table c'est : id primary, titre varchar 255, description(text), blabla... avec fulltext(titre description) Je vais arrêter d'utiliser la méthode fulltext (c'est plus possible d'attendre 15 minutes pour une recherche même si généralement ça tourne aux alentours de 5 minutes! ) mais ça me semble "anormal" même si d'après ce que j'ai lu, fulltext n'est vraiment pas terrible. Vous avez ce genre de soucis avec cette méthode? Sachant que toutes les requêtes sont plutôt longues... Rarement moins de 10 secondes... Sauf quand la requête ne retourne que moins de 1000 enregistrements et encore... Si vous avez un commentaire à faire avant que je change tout ça, que ce soit pour la nouvelle méthode de recherche que je devrais utilisé ou pour un "paramètre" que je devrais vérifier avant de tout modifier, n'hésitez pas. Merci. A++ (Message édité le 02-04-2008 à 18h51 par DarkSquall) Isyweb.com
caaptusss \| Jérémy Membre Inscrit le : 25/09/2007	# Le 02/04/2008 à 17:42 la première chose que je ferais c'est que tes champs titre et description, je les met en VARCHAR(255) ou plus gros (BIGVARCHAR il me semble ?), et tu met un "index" sur les deux champs. Tes requêtes vont devenir beauuuuuucoup plus rapide FirstHeberg.com
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 02/04/2008 à 17:55 caaptusss : les index "fulltext" sont déjà des "index" ;) daevel : infogérance et conseil \|\| moi
MathieuC \| Mathieu Modérateur Inscrit le : 15/07/2005	# Le 02/04/2008 à 18:16 Je fais beaucoup de recherche fulltext sur un site, et j'ai pas de problèmes de perf (requetes executées en 0.0x seconde) Ma recherche se fait sur deux tables de 600 000 enregistrement, avec une jointure entre les deux, et tout se passe sans souci. Ma requete utilise "IN BOOLEAN MODE", ca joue peut etre. Sinon, un truc a savoir, c'est que ton serveur MySQL doit etre configure pour avoir assez de memoire pour mettre TOUTE ta table en memoire, sinon il va passer son temps a lire sur le disque, et ca va ralentir enormement. Si il a la place de tout mettre en memoire, une fois la table chargée, c'est ultra rapide. Pour ca, il faut deja que ton serveur ai assez de memoire libre, et il faut que tu joue sur la conf de ton serveur MySQL.
caaptusss \| Jérémy Membre Inscrit le : 25/09/2007	# Le 02/04/2008 à 18:16 autant pour moi, j'avait mal lu FirstHeberg.com
TomPascal \| Pascal Membre Inscrit le : 08/11/2006	# Le 02/04/2008 à 18:26 Bonjour, Pour des assez grosses tables comme les topics d'un forum de plus de 1.500.000 enregistrements, les performances des Full-Text était aussi catastrophiques arrivé à un moment... Maintenant, je passe par un moteur d'indexation dédié à cela (swish-e en l'occurrence pour ma part), et n'utilise plus de Full-Text MySql (qui ralentissent aussi les insertions / modifications...) J'en parlais en bas de cette page, si cela peut servir... : http://www.webrankinfo.com/forums/topic_page_51110... Archipel Web Conception, réalisation, référencement de sites internet.
Elios \| D Modérateur Inscrit le : 09/05/2005	# Le 02/04/2008 à 18:52 DarkSquall a dit : J'ai atteint le record mondial de la requête la plus longue. "Générée en : 888.67506 secondes." Ca fait 10 jours ca, ouch Weekendo
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 02/04/2008 à 19:09 On doit pas avoir les mêmes secondes Elios :S Sinon si ça peut te rassurer DarkSquall, 15 minutes pour une requête SQL, c'est ridicule comme temps pour un SGBD daevel : infogérance et conseil \|\| moi
DarkSquall \| Membre Inscrit le : 27/08/2005	# Le 02/04/2008 à 19:12 @Tompascal : Merci, je vais essayer d'en lire plus à propos de ce genre de méthode. @Telaxo : Mon serveur n'utilise pas le swap. Je vais regarder cette histoire de boolean mode. Aussi on ne doit pas avoir le même type de serveur, mais je dois tout de même avoir un soucis si pour toi 600 000 enregistrements c'est si rapide... (Ceci même sur des requêtes retournant de nombreux enregistrements? -> Quand ma requête retourne 2 enregistrements ça prend 0,2 seconde.. Pas beau mais moins grave) @caaptusss : Je pense que le bigvarchar est tro limité en nombre de caractères et que je suis obligé de passé en text, mais je vais vérifier. @Elios : Ta calculatrice est défectueuse :p - Le point est une virgule. @Bool : Ca ne me rassure pas plus que ça mais merci d'avoir essayé Isyweb.com
Elios \| D Modérateur Inscrit le : 09/05/2005	# Le 02/04/2008 à 19:14 Bool a dit : On doit pas avoir les mêmes secondes Elios :S Sinon si ça peut te rassurer DarkSquall, 15 minutes pour une requête SQL, c'est ridicule comme temps pour un SGBD Autant pour moi, j'avais lu 888.675,06s Weekendo
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 02/04/2008 à 19:18 C'est pas parce que ça ne swap pas que MySQL utilise la mémoire dont il aurait besoin... A la limite, ce serait presque le contraire. Par défaut MySQL utilise vraiment très peu de mémoire, et a donc forcément des performances "catastrophiques". daevel : infogérance et conseil \|\| moi
MathieuC \| Mathieu Modérateur Inscrit le : 15/07/2005	# Le 02/04/2008 à 19:24 Que ce soit 1 000 ou 50 000 resultats, c'est toujours entre 0.02 et 0.06 (c'est pas celles qui retournent le plus de resultats qui sont les plus lentes) Le serveur est un "simple" EG chez OVH : http://www.ovh.com/fr/particulier/produits/eg.xml, c'est pas non plus une fusée
tonguide \| Jeremy Modérateur Inscrit le : 09/05/2005	# Le 02/04/2008 à 19:24 DarkSquall a dit : (Ceci même sur des requêtes retournant de nombreux enregistrements? -> Quand ma requête retourne 2 enregistrements ça prend 0,2 seconde.. Pas beau mais moins grave) Juste pour être sûr, tu utilises LIMIT x,y ? Parce que forcement, si tu affiches 5 000 résultats sans limite, c'est long.
devtribu \| Olivier Modérateur Inscrit le : 16/06/2005	# Le 02/04/2008 à 19:31 Telaxo > Ca m'interesse rudement aussi ! Tu peux poster ta config my.cnf ? la structure de la table et un exemple de requete ? Merci ! Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f
DarkSquall \| Membre Inscrit le : 27/08/2005	# Le 02/04/2008 à 19:35 Ah oui, alors c'est peut-être là mon problème. Merci Bool, je vais regarder. C'est le paramètre tm_table_size ? Il est a 128mo chez moi. Au passage je vérifie mes paramètres mysql avec un petit script "tuning-primer" (pour ceux qui ne connaissent pas je pense que c'est celui ci : http://www.day32.com/MySQL/ c'est le premier lien) Ceux qui connaissent... Vous en pensez quoi? (C'est presque un peu hors sujet mais bon) ******** Oui tonguide, je n'affiche que 10 résultats. Isyweb.com**
MathieuC \| Mathieu Modérateur Inscrit le : 15/07/2005	# Le 02/04/2008 à 19:58 La section interessante est la : skip-locking skip-name-resolve set-variable = connect_timeout=20 set-variable = max_connections=300 set-variable = max_allowed_packet=32M set-variable = thread_cache_size=25 set-variable = long_query_time=2 #log-queries-not-using-indexes set-variable = ft_min_word_len=3 set-variable = key_buffer_size=1280M set-variable = sort_buffer_size=128M set-variable = read_rnd_buffer_size=128M set-variable = query_cache_type=0 set-variable = tmp_table_size=768M set-variable = max_heap_table_size=768M La table a 15 champs, quaisment que des entier ou des date, deux varchar et un champs text. Un des varchar et le text sont en fulltext (Titre et Description). Un requete type est celle ci : SELECT * FROM Table WHERE MATCH(Titre) AGAINST('truc' IN BOOLEAN MODE) La table est montee jusqu'a 800 000 enregistrements, et ca ramait toujours pas.
MathieuC \| Mathieu Modérateur Inscrit le : 15/07/2005	# Le 02/04/2008 à 19:59 PS : il y a toujours des LIMIT dans mes requetes
DarkSquall \| Membre Inscrit le : 27/08/2005	# Le 02/04/2008 à 20:13 Tu pourrais me dire quelle taille a ta table, pour comparer avec tes paramètres? La mienne fait 700 mo elle ne se met apparemment pas entièrement en cache c'est donc là mon soucis, je vais voir à la diviser en plusieurs tables. ( J'ai regardé un peu mon log de slow-queries il y a eu des requêtes a plus de 6000 secondes ) Isyweb.com
MathieuC \| Mathieu Modérateur Inscrit le : 15/07/2005	# Le 02/04/2008 à 20:21 La mienne fait 450 Mo (190 de donnees, 260 d'index), j'ai énormement d'index dessus. Mais sur le meme serveur, j'ai plusieurs tables de 300 à 500 Mo, et tout se passe bien, aucune requete ne rame.
tonguide \| Jeremy Modérateur Inscrit le : 09/05/2005	# Le 02/04/2008 à 20:57 1.1 Go ... je me suis limité à une recherche classique sur le titre ... Telaxo, tu t'en sers de façon très très régulière (en gros, c'est tes membres qui font les recherches) ? Ou ça reste plutôt rare, du genre 1 fois par minute ... ?

Auteur

Message

Inscrit le : 27/08/2005

# Le 02/04/2008 à 17:39

Hello,

J'ai atteint le record mondial de la requête la plus longue.
"Générée en : 888.67506 secondes."

J'ai recherché "mot" en fulltext sur une table d'environ 1 500 000 enregistrements. 140 000 enregistrements ont étés retournés... (Je n'utilise pas de cache sur ces requêtes)

la table c'est : id primary, titre varchar 255, description(text), blabla...
avec fulltext(titre description)

Je vais arrêter d'utiliser la méthode fulltext (c'est plus possible d'attendre 15 minutes pour une recherche même si généralement ça tourne aux alentours de 5 minutes! ) mais ça me semble "anormal" même si d'après ce que j'ai lu, fulltext n'est vraiment pas terrible.

Vous avez ce genre de soucis avec cette méthode? Sachant que toutes les requêtes sont plutôt longues... Rarement moins de 10 secondes... Sauf quand la requête ne retourne que moins de 1000 enregistrements et encore...

Si vous avez un commentaire à faire avant que je change tout ça, que ce soit pour la nouvelle méthode de recherche que je devrais utilisé ou pour un "paramètre" que je devrais vérifier avant de tout modifier, n'hésitez pas.

Merci.
A++

(Message édité le 02-04-2008 à 18h51 par DarkSquall)

Isyweb.com

caaptusss | Jérémy
Membre

Inscrit le : 25/09/2007

# Le 02/04/2008 à 17:42

la première chose que je ferais c'est que tes champs titre et description, je les met en VARCHAR(255) ou plus gros (BIGVARCHAR il me semble ?), et tu met un "index" sur les deux champs.

Tes requêtes vont devenir beauuuuuucoup plus rapide

FirstHeberg.com

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 02/04/2008 à 17:55

caaptusss : les index "fulltext" sont déjà des "index" ;)

daevel : infogérance et conseil || moi

MathieuC | Mathieu
Modérateur

Inscrit le : 15/07/2005

# Le 02/04/2008 à 18:16

Je fais beaucoup de recherche fulltext sur un site, et j'ai pas de problèmes de perf (requetes executées en 0.0x seconde)

Ma recherche se fait sur deux tables de 600 000 enregistrement, avec une jointure entre les deux, et tout se passe sans souci.

Ma requete utilise "IN BOOLEAN MODE", ca joue peut etre.

Sinon, un truc a savoir, c'est que ton serveur MySQL doit etre configure pour avoir assez de memoire pour mettre TOUTE ta table en memoire, sinon il va passer son temps a lire sur le disque, et ca va ralentir enormement. Si il a la place de tout mettre en memoire, une fois la table chargée, c'est ultra rapide. Pour ca, il faut deja que ton serveur ai assez de memoire libre, et il faut que tu joue sur la conf de ton serveur MySQL.

caaptusss | Jérémy
Membre

Inscrit le : 25/09/2007

# Le 02/04/2008 à 18:16

autant pour moi, j'avait mal lu

FirstHeberg.com

TomPascal | Pascal
Membre

Inscrit le : 08/11/2006

# Le 02/04/2008 à 18:26

Bonjour,

Pour des assez grosses tables comme les topics d'un forum de plus de 1.500.000 enregistrements, les performances des Full-Text était aussi catastrophiques arrivé à un moment...

Maintenant, je passe par un moteur d'indexation dédié à cela (swish-e en l'occurrence pour ma part), et n'utilise plus de Full-Text MySql (qui ralentissent aussi les insertions / modifications...)

J'en parlais en bas de cette page, si cela peut servir... :
http://www.webrankinfo.com/forums/topic_page_51110...

Archipel Web Conception, réalisation, référencement de sites internet.

Elios | D
Modérateur

Inscrit le : 09/05/2005

# Le 02/04/2008 à 18:52

DarkSquall a dit :

J'ai atteint le record mondial de la requête la plus longue.
"Générée en : 888.67506 secondes."

Ca fait 10 jours ca, ouch

Weekendo

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 02/04/2008 à 19:09

On doit pas avoir les mêmes secondes Elios :S

Sinon si ça peut te rassurer DarkSquall, 15 minutes pour une requête SQL, c'est ridicule comme temps pour un SGBD

daevel : infogérance et conseil || moi

DarkSquall |
Membre

Inscrit le : 27/08/2005

# Le 02/04/2008 à 19:12

@Tompascal : Merci, je vais essayer d'en lire plus à propos de ce genre de méthode.

@Telaxo : Mon serveur n'utilise pas le swap. Je vais regarder cette histoire de boolean mode. Aussi on ne doit pas avoir le même type de serveur, mais je dois tout de même avoir un soucis si pour toi 600 000 enregistrements c'est si rapide... (Ceci même sur des requêtes retournant de nombreux enregistrements? -> Quand ma requête retourne 2 enregistrements ça prend 0,2 seconde.. Pas beau mais moins grave)

@caaptusss : Je pense que le bigvarchar est tro limité en nombre de caractères et que je suis obligé de passé en text, mais je vais vérifier.

@Elios : Ta calculatrice est défectueuse :p - Le point est une virgule.

@Bool : Ca ne me rassure pas plus que ça mais merci d'avoir essayé

Isyweb.com

Elios | D
Modérateur

Inscrit le : 09/05/2005

# Le 02/04/2008 à 19:14

Bool a dit :
On doit pas avoir les mêmes secondes Elios :S

Sinon si ça peut te rassurer DarkSquall, 15 minutes pour une requête SQL, c'est ridicule comme temps pour un SGBD

Autant pour moi, j'avais lu 888.675,06s

Weekendo

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 02/04/2008 à 19:18

C'est pas parce que ça ne swap pas que MySQL utilise la mémoire dont il aurait besoin... A la limite, ce serait presque le contraire.

Par défaut MySQL utilise vraiment très peu de mémoire, et a donc forcément des performances "catastrophiques".

daevel : infogérance et conseil || moi

MathieuC | Mathieu
Modérateur

Inscrit le : 15/07/2005

# Le 02/04/2008 à 19:24

Que ce soit 1 000 ou 50 000 resultats, c'est toujours entre 0.02 et 0.06 (c'est pas celles qui retournent le plus de resultats qui sont les plus lentes)

Le serveur est un "simple" EG chez OVH : http://www.ovh.com/fr/particulier/produits/eg.xml, c'est pas non plus une fusée

tonguide | Jeremy
Modérateur

Inscrit le : 09/05/2005

# Le 02/04/2008 à 19:24

DarkSquall a dit :
(Ceci même sur des requêtes retournant de nombreux enregistrements? -> Quand ma requête retourne 2 enregistrements ça prend 0,2 seconde.. Pas beau mais moins grave)

Juste pour être sûr, tu utilises LIMIT x,y ?
Parce que forcement, si tu affiches 5 000 résultats sans limite, c'est long.

devtribu | Olivier
Modérateur

Inscrit le : 16/06/2005

# Le 02/04/2008 à 19:31

Telaxo > Ca m'interesse rudement aussi !
Tu peux poster ta config my.cnf ? la structure de la table et un exemple de requete ?

Merci !

Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f

DarkSquall |
Membre

Inscrit le : 27/08/2005

# Le 02/04/2008 à 19:35

Ah oui, alors c'est peut-être là mon problème. Merci Bool, je vais regarder.
C'est le paramètre tm_table_size ? Il est a 128mo chez moi.

Au passage je vérifie mes paramètres mysql avec un petit script "tuning-primer" (pour ceux qui ne connaissent pas je pense que c'est celui ci : http://www.day32.com/MySQL/ c'est le premier lien)
Ceux qui connaissent... Vous en pensez quoi?
(C'est presque un peu hors sujet mais bon)

**********
Oui tonguide, je n'affiche que 10 résultats.

Isyweb.com

MathieuC | Mathieu
Modérateur

Inscrit le : 15/07/2005

# Le 02/04/2008 à 19:58

La section interessante est la :

skip-locking
skip-name-resolve

set-variable = connect_timeout=20
set-variable = max_connections=300
set-variable = max_allowed_packet=32M
set-variable = thread_cache_size=25

set-variable = long_query_time=2
#log-queries-not-using-indexes

set-variable = ft_min_word_len=3

set-variable = key_buffer_size=1280M
set-variable = sort_buffer_size=128M
set-variable = read_rnd_buffer_size=128M

set-variable = query_cache_type=0

set-variable = tmp_table_size=768M
set-variable = max_heap_table_size=768M

La table a 15 champs, quaisment que des entier ou des date, deux varchar et un champs text.

Un des varchar et le text sont en fulltext (Titre et Description).

Un requete type est celle ci :
SELECT * FROM Table WHERE MATCH(Titre) AGAINST('truc' IN BOOLEAN MODE)

La table est montee jusqu'a 800 000 enregistrements, et ca ramait toujours pas.

MathieuC | Mathieu
Modérateur

Inscrit le : 15/07/2005

# Le 02/04/2008 à 19:59

PS : il y a toujours des LIMIT dans mes requetes

DarkSquall |
Membre

Inscrit le : 27/08/2005

# Le 02/04/2008 à 20:13

Tu pourrais me dire quelle taille a ta table, pour comparer avec tes paramètres?

La mienne fait 700 mo elle ne se met apparemment pas entièrement en cache c'est donc là mon soucis, je vais voir à la diviser en plusieurs tables.

( J'ai regardé un peu mon log de slow-queries il y a eu des requêtes a plus de 6000 secondes )

Isyweb.com

MathieuC | Mathieu
Modérateur

Inscrit le : 15/07/2005

# Le 02/04/2008 à 20:21

La mienne fait 450 Mo (190 de donnees, 260 d'index), j'ai énormement d'index dessus.

Mais sur le meme serveur, j'ai plusieurs tables de 300 à 500 Mo, et tout se passe bien, aucune requete ne rame.

tonguide | Jeremy
Modérateur

Inscrit le : 09/05/2005

# Le 02/04/2008 à 20:57

1.1 Go ... je me suis limité à une recherche classique sur le titre ...

Telaxo, tu t'en sers de façon très très régulière (en gros, c'est tes membres qui font les recherches) ? Ou ça reste plutôt rare, du genre 1 fois par minute ... ?

Page 1 2

Répondre

Vous ne pouvez pas participer au forum, car votre inscription n'a pas été validée. Pour vous faire valider en tant que Membre, cliquez ici.