Requete de selection très lente

[mikaweb2011]

Bonjour,

Est ce que c'est possible comment il fait le site webrankinfo pour gérer et selectionner rapidement toutes les messages postés.

Je veux faire sur mon site de ce genre d'astuce utilisé par webrankinfo.
J'utilise un requête de sélection composé par plusieurs jointures (9 jointures) dont un table contient 700000 enregistrements et occupe 150Mo d'espace .
J'utilise les index et le cache des requêtes.Je crois que tout est bien optimisé sachant que j'ai un serveur kimsufi 250g .

J'ai remarqué toujours que le premier accès à la page est très lent mais avec un deuxième et ième accès la page sera rapide.

Je suis sur que le requête qui ralentit le chargement de la page.

Y'a t'il d'astuce pour rendre la page rapide ou sinon il faut changer un serveur plus puissant dans ce cas.

pour le test voila un lien :http://www.pubaffiliation.com/voyage/voyage-tunisie/


merci d'avance.

 

[MarvinLeRouge]

Salut,

Si ça utilise 9 jointures, et si les données en question ne changent pas tout le temps, il vaudrait peut-être mieux approvisionner une temporaire lorsqu'il y a des modifs sur une des tables mères, et sélectionner sur cette table temporaire (qui est du coup une sorte de vue approvisionnée uniquement lorsque la modif de données a lieu).

 

[JulienV]

Salut

Pourquoi ne pas gérer tes caches directement lors de la modification des contenus ?

Exemple : tu mets à jour un article, et bien cela génère directement le fichier cache.

Ainsi, les utilisateurs qui passent sur ta page n'ont pas à patienter le temps que le script fasse son boulot.

Sinon, pour te répondre de manière plus précise, il faudrait que nous ayons un aperçu de tes tables, pour voir le type de jointure que tu fais, et les types de données que tu gères.

A + !!

 

[mikaweb2011]

Bonjour,

merci pour vos réponse.

j'ai utilisé avant les caches des pages mais ce n'est pas pratique parce que le contenu des pages changent chaque jour.

cdt.

 

[JulienV]

Alors je pense que le mieux est, comme ça a été dit plus haut, d'utiliser des tables temporaires.

En gros, tu mets en place des tâches crons qui s'occupent de générer ton contenu en fonction de ce dont tu as besoin. Et ensuite, tes pages vont chercher tout ce contenu de manière très rapide, sur une seule table.

Inconvénient : la mise à jour des pages n'est pas en temps réel, mais si tu optimises bien tes crons, ils peuvent travailler rapidement

 

[mikaweb2011]

Alors je pense que le mieux est, comme ça a été dit plus haut, d'utiliser des tables temporaires.

En gros, tu mets en place des tâches crons qui s'occupent de générer ton contenu en fonction de ce dont tu as besoin. Et ensuite, tes pages vont chercher tout ce contenu de manière très rapide, sur une seule table.

Inconvénient : la mise à jour des pages n'est pas en temps réel, mais si tu optimises bien tes crons, ils peuvent travailler rapidement

Merci.

Bon, je vois que ce n'est pas possible , j'explique:

1- J'utilise les requêtes préparés avec aussi le cache SGBD ( donc ça peut remplacer l'utilisation des VIEW - MySQL).
2- L'internaute peut chercher plusieurs résultat c'est à dire il peut rechercher les offres d'aujourd'hui est des prochains dates aussi. Donc combien de view il faut créer sinon on charge la base.

Pensez vous que je change un serveur plus puissant? Sinon comment font les grands sites pour gérer leurs bases rapidement.Il me manque vraiment ce genre d'astuce.

cdt.

 

[MarvinLeRouge]

Le fait que tu utilises le cache SGBD stocke le résultat d'une requête, alors que là on te propose de stocker tous les résulats possibles d'une requête dans une seule table. Et tu peux aussi faire des requêtes préparées et du cache sgbd en plus, d'ailleurs.

"Chercher les offres des prochains jours" : C'est pas très clair ton histoire; si tu parles d'un système d'alerte sur de futures offres, ce n'est pas du tout incompatible, puisque les tables temporaires sont peuplées avec les bonnes données au moment où la requête est faite.