Alléger le trafic du à un autocomplete

[xdeslandes]

Bonjour,

J'utilise un système d'autocomplétion d'un input. Rappel: lorsqu'on saisit quelques caractères, une requete va chercher les résultats qui contiennent ces caractères: la liste se réduit au fur et à mesure de la saisie. C'est en ajax bien sûr.
Oui, mais voilà: la base contient plus de 4000 enregistrements (ce qui n'est pas beaucoup malgré tout, non ?). Et: une requete à chaque lettre tapée + on saisit rapidement = "engorgement". Des fois plantage du navigateur.
Question: peut-on réduire ces aller-retours client-serveur tout en conservant au mximum la souplesse de la saisie.
J'ai penséà
- ne déclencher le script qu'au bout de 5 caractères (au lieu de 2 actuellement)
- limiter le nombre de résultats retournés (à 10 par exemple)

Y a-t-il d'autres combines genre mieux régler un pare-feu ou un équipement réseau ? Ou sur la bdd ? sur le serveur de bdd ?

Merci pour vos futurs conseils.
Xavier.

 

[M&B Multimédia]

Bonjour,


Moi je verrais bien le déclenchement du script que toutes les deux lettres... Tu divises par deux les requêtes, et si l'internaute tape vite, tu divises par deux les risques de plantage...

Ou alors, déclenchement du script qu'au bout de 1 seconde sans action dans le champ input. Ceux qui tapent vite ne voient pas l'autocomplétion sauf à la fin de leur saisie, ceux qui tapent moins vite bénéficient d'une autocomplétion afin de les aider à remplir correctement le champ input.

 

[CodingPapa]

Selon la fréquence de mise à jour de ton contenu, tu peux aussi mettre en place un système de cache statique qui t'épargne les requêtes à la base de donnée (si c'est bien là le point faible ?).

Par contre dans ton message, tu parles de plantage du navigateur ? Dans ce cas c'est peut-être que tu retournes trop d'éléments et du coup limite toi en effet aux 10 ou 20 premiers; de toutes façon un auto-complete avec 500 lignes affichées a peu d'intérêt pour le visiteur :wink:

 

[e-kiwi]

400 = ridicule. à 4.000.000 déjà ca peut devenir problématique. as tu bien optimisé ta requête ?

 

[xdeslandes]

Merci pour vos réponses !
Non, je n'ai sans doute pas optimisé suffisamment ma requête.
Merci B&B Multimedia: ce sont effectivement des pistes à creuser.
Pour le cache, que dois-je enregistrer en local ? Sur quels critères mettre à jour ? Cette piste m'intéresse depuis longtemps, mais je ne vois pas comment la mettre en oeuvre...

 

[Julia41]

Sur un même système on est passé de 1000 de requêtes (SQL) par seconde et une charge "un peu" élevé à "presque rien" en utilisant memcache.
On stock aussi les résultats les plus "tappés" pour les precacher quand on purge le cache.
Pour les "event" de completion, on le fait bien sur le "inverse de keypress" (quand on relache la touche).

Autre solution qu'on a testé qui marchait vraiment vraiment pas mal, c'était avec sphinx. Là déjà gros avantage, c'est en dehors de MySQL, donc ça tappe "ailleurs". Et ça fait des suggestions sympa.

Les retours ajax (et appel) doivent aussi être compressé au maximum:

<p>blabla suggéré</p>

On peut "préafficher" le <p> </p> et ne retourner que "blabla suggéré". Ca fait déjà gagner pas mal.

Si avec 4000 tu commences à avoir des soucis, il y a quand même un problème.
Aussi si ta recherche est en :
WHERE name LIKE '%blabla%';
tu peux généralement la faire en:
WHERE name LIKE 'blabla%';
ou utiliser RLIKE.

 

[spout]

+1 avec Julia41

Pour les retours AJAX, par expérience, je préfère nettement mieux un retour JSON qu'un retour en XML/XHTML.
Le X de AJAX n'étant plus là que pour XMLHTTPRequest effectué.
Le JSON est super facile à traiter dans la plupart des langages de programmation (c'est fait pour), un simple json_decode/encode en PHP pr le transformer en objet ou en array.

De plus une bonne partie des API propose ce format par défaut.

 

[xdeslandes]

Je ne te comprends pas julia41, là:

Pour les "event" de completion, on le fait bien sur le "inverse de keypress" (quand on relache la touche).

 

[Julia41]

@xdeslandes : j'ai retrouvé le nom :
il faut bien utiliser "uniquement" le "onkeyup" et pas le "onkeydown" ni "onkeypress" (pas trop sûr des noms).
En clair :
je press A
Je relache A
Si tu fais ta requête sur les 2, tu as une requête inutile (et identique).

@spout: carrément, il n'y a qu'à voir la facilité de la graph API de facebook qui est vraiment géniale.

Sur un de mes sites on a d'abord développé pour "nous" un truc en interne, voyant que les retours json était pas mal, on a publié une "petite" API (sans doc par contre la flaime) pour les users, eux-même nous on fait des plugins et modules de malades tout simple

 

[xdeslandes]

Oui, je ne déclenche le script que sur onkeyup.
Pour moi, les résultats sont plutôt rapides, mais c'est le client qui souffre, même avec plusieurs navigateurs testés: c'est pourquoi je recherche plutôt des pistes vers le réseau. Peut-il y avoir des restriction chez le fournisseur d'accès ? Un pare-feu un peu trop limitant ?

 

[Julia41]

Oui, je ne déclenche le script que sur onkeyup.
Pour moi, les résultats sont plutôt rapides, mais c'est le client qui souffre, même avec plusieurs navigateurs testés: c'est pourquoi je recherche plutôt des pistes vers le réseau. Peut-il y avoir des restriction chez le fournisseur d'accès ? Un pare-feu un peu trop limitant ?

Les parefeu ne bloquent pas encore le html

Aucune restriction normalement.
Bon, je vois pas pourquoi ça serait le réseau car l'autocomplete c'est du texte (autrement dit : "rien niveau poids"). A moins que tu fasses sortir des trucs complets de 2 à 3Mo et que ça soit traité en js par le navigateur mais là ça serait moche.

 

[Leonick]

as-tu vérifié la taille des infos renvoyées ?

 

[poulpe]

Je pencherais pour le SQL.
as tu un index sur le champ demande par la base ? et effectivement il faut faire un like 'requete%' pour pouvoir en tirer partie (de memoire).