Réduire activité SQL (Hebergement mutualisé.)
- Auteur de la discussion mustru
- Date de début
-
- Tags
- serveur mutualisé
il va falloir que tu trouves déjà quels scripts sont à l origine de ce problème, et seul toi va pouvoir le faire. après il existe des facons de reduire l activité sql avec un systeme de cache, pour ne pas avoir à chaque affichage de page à la regenerer si elle ne change pas ou peu, mais tout depend du site en question
Merci e-kiwi,
Mon site est un site d'abandonware http://www.abandonware-utopia.com (offline pour l'instant.) les requetes les plus éxécutées sont des liste de jeux a télécharger, il y'en a a peut pres 500 que l'on peut afficher en fonction de plusieurs critères (date ajout, année, hits...) de plus, j'affiche les résultat sur plusieurs pages, donc dés que l'utilisateur change de page la requete est rééxécutée...
Un système de cache est t-il difficile à utiliser ?
J'ai déja supprimer pas mal de requete et j'espere trouver encore des solutions afin de pouvoir tenir quelques mois avant de partir sur un serveur dédié.
Merci de vos conseils.
Mon site est un site d'abandonware http://www.abandonware-utopia.com (offline pour l'instant.) les requetes les plus éxécutées sont des liste de jeux a télécharger, il y'en a a peut pres 500 que l'on peut afficher en fonction de plusieurs critères (date ajout, année, hits...) de plus, j'affiche les résultat sur plusieurs pages, donc dés que l'utilisateur change de page la requete est rééxécutée...
Un système de cache est t-il difficile à utiliser ?
J'ai déja supprimer pas mal de requete et j'espere trouver encore des solutions afin de pouvoir tenir quelques mois avant de partir sur un serveur dédié.
Merci de vos conseils.
voir combien tu as de tables, quels sont tes champs indexés, et quelles requetes tu faisjarweb.. kazhar a entierement raison.. aucun avantage a le faire de la sorte..
il vaut mieux garder la connexion ouverte.. faire des requetes bien choisies, optimisées, optimiser la base et les index, choisir les bons types.. eventuellement vider la memoire dans les scripts tres consommateurs...
puis en 2eme etape, les caches de requetes sql, les caches php et les caches html...
ca c'est mon avis.
et avant tout faire de belles requetes et c'est impressionnant ce qu'on peut y gagner.. !
et ne pas hesiter, a tedter et benchmarker pour savoir si on est sur la bonne voie ou pas
il vaut mieux garder la connexion ouverte.. faire des requetes bien choisies, optimisées, optimiser la base et les index, choisir les bons types.. eventuellement vider la memoire dans les scripts tres consommateurs...
puis en 2eme etape, les caches de requetes sql, les caches php et les caches html...
ca c'est mon avis.
et avant tout faire de belles requetes et c'est impressionnant ce qu'on peut y gagner.. !
et ne pas hesiter, a tedter et benchmarker pour savoir si on est sur la bonne voie ou pas
Si tu n'a pas un trafic enorme (par enorme, j'entends plus de 7k vu/jour), tu peut faire sans cache en optimisant au maximum la base de données.
Cette optimisation passe par ce que je disais plus haut, la mise en place de clés primaires et de clés d'index.
Et la différence se voit surtout si tu a beaucoup de données dans la base.
Une requête de sélection de données sur une table contenant environ 3 millions d'uplets prendra plus de 30 secondes si tu n'a aucune clé.
Tu descendra bien en dessous d'une seconde si tu a une clé primaire (et une clé index si tu ne fait pas la sélection en cherchant sur la clé primaire)
Cette optimisation passe par ce que je disais plus haut, la mise en place de clés primaires et de clés d'index.
Et la différence se voit surtout si tu a beaucoup de données dans la base.
Une requête de sélection de données sur une table contenant environ 3 millions d'uplets prendra plus de 30 secondes si tu n'a aucune clé.
Tu descendra bien en dessous d'une seconde si tu a une clé primaire (et une clé index si tu ne fait pas la sélection en cherchant sur la clé primaire)
Discussions similaires
