BDD surchargée, latence de l'hebergeur

Statut
La discussion n'est pas ouverte à d'autres réponses

Sod

Membre
Bonsoir ! je fais appel aux codeurs PHP/SQL présent sur OCPC pour un problème assez génant, j'ai récemment développé un petit projet SQL/PHP/VB.NET que l'ont peut comparer à une boite de messagerie en ligne. J'ai donc mon programme qui sert à envoyer des mails sur une page de mon site, cette dernière récupère les données et les attribue au compte du destinataire sur mon site pour enfin afficher sur une page d'un coté les adresses mail des expéditeurs et de l'autre le contenu du mail. Jusqu'à présent je n'avais aucun soucis au niveau de la rapidité du traitement des requêtes SQL étant le seul utilisateur pour mes tests personnel mais ayant désormais rendu le site public je me retrouve ce soir avec ~9000 lignes dans ma table SQL et là c'est le drame, environ 3 minutes pour ouvrir un mail c'est juste inutilisable. Le plus long étant apparemment le traitement des adresses expéditeur puis ce que ma requête doit à chaque fois chercher parmi les 9000 lignes quel expéditeur à pour destinataire tel compte pour ensuite les afficher. Je ne connais pas les causes exactes étant mon premier projet de ce type, si cela vient de l’hébergeur (allo-heberge :x) ou si c'est normal qu'une requête mouline à ce point pour 9000 petites lignes (j'imagine que c'est vraiment peu par rapport à d'autre). Enfin bref assez cataclysmique pour un lancement, je compte sur vous !
clin.png

Quelques infos supplémentaire sur la fonction qui serait la cause de cet énorme ralentissement, je fais un SELECT mail_expediteur WHERE id = Id du compte client ORDER BY date DESC, à savoir également que le reste de mon site est ralenti sans pour autant faire appel à cette requête (mais ça provient bien de la BDD puis ce qu'en la vidant tout rentre dans l'ordre)


En vous remerciant d'avance, très bonne soirée.
 
Dernière édition:
Salut, Desoler je ne pourrais pas t'aider sur ton probleme...
Mais quelqu'un de plus expérimenté passera surement par là :)
 
effectivement 9000 lignes c'est vraiment peu et tu ne devrais pas être ralenti, je bosse sur une BDD avec certaines tables comprenant plus de 100k enregistrements et les traitements sont hyper rapides. Je ne bosse pas sur du SQL mais pour moi tu as surement un problème d'index ou ta requête est mal écrite.

Les index sont hyper importants dans le temps de traitement. Après faut voir aussi ce que ton hébergeur t'offre comme ressources. Si tu tournes sur un P3 avec 128Mo de RAM ou sur un XEON avec 32Go tu n'aura pas les mêmes perf.
 
bonjour,

je ne pense pas que le problème vienne de sa requête (si c'est la même qu'il a écrit) ni un problème d'index, 9K lignes, on ne crée même pas d'index.
Le problème est ailleurs, serveur, hébergeur, etc...
 
bonjour,

je ne pense pas que le problème vienne de sa requête (si c'est la même qu'il a écrit) ni un problème d'index, 9K lignes, on ne crée même pas d'index.
Le problème est ailleurs, serveur, hébergeur, etc...

Il faut toujours créer un index. Surtout si 9k lignes ce n'est qu'un début. Dans tous les cas s'est gratuit et utile donc pourquoi se priver.
 
ce n'est pas gratuit, cela consomme de l'espace, et puis sur quels champs ?
des fois, des index mal crées ralentis la requête
 
Sur quel champs ?

Je dirai sur l'id puisqu'il y a un where.

ça consomme de l'espace.

oui mais bon pas non plus énormément au vu du gain apporté au final.

Maintenant je te rejoins sur le fait que pour parcourir 9k lignes ça ne doit pas mettre 3 min, d'où ma demande concernant les ressources fournies par l'hébergeur :icon_wink-221e:
 
Salut ! merci pour vos réponses, je me pencherai sur les index ce week end je vais retravailler sur l'optimisation de mon code cela dit je pense aussi que l’hébergeur joue un rôle important dans mon problème. Bizarrement je trouve aucune info sur les perfs de leur serveurs mutualisés, je pense me prendre un VPS chez 1&1 ou ex2hosting et je vous tiendrai au courant ! ;)
 
Salut ! Bon j'ai eu quelques petits soucis pour avoir mon dédié mais c'est chose faite. Je viens de terminer le dump de la BDD et les modifs afin de rendre le site opérationnel chez mon nouvel hébergeur, bilan même problème. Le site en lui même est beaucoup plus fluide mais la requête de récupération des mails expéditeur est toujours aussi lente.. J'avais un peu simplifié ma requête dans mon précédent post, la syntaxe exacte est la suivante :

Code:
<!--?php //Récuperation des Mails Expediteur //
 
$reponse = $db->query('select t1.mail_expe, t1.number, lu
from mails t1
where t1.number = (select max(t2.number) from mails t2 where t2.mail_expe=t1.mail_expe) AND ID = \'' .$id. '\'
ORDER BY number DESC');
while ($donnees = $reponse->fetch())

J'utilise cette syntaxe pour afficher le statut du mail (lu/non lu)

ex: si la colonne "lu" de la dernière entrée de mail_expe est égale à 1, alors le dernier mail à déjà été ouvert on affiche donc mail_expe avec une couleur grisée, sinon on affiche mail_expe en blanc avec un soulignement.

J'ai trouvé cette syntaxe sur internet après plusieurs essais perso non fructueux, elle fonctionne mais serai donc la cause du ralentissement.

Je me retrouve donc au point de départ et suis ouvert à toute propositions :)

- - - - - - - - - - -Fusion. Pas bien de faire du flood - - - - - - - - - - -

Salut ! Bon j'ai eu quelques petits soucis pour avoir mon dédié mais c'est chose faite. Je viens de terminer le dump de la BDD et les modifs afin de rendre le site opérationnel chez mon nouvel hébergeur, bilan même problème. Le site en lui même est beaucoup plus fluide mais la requête de récupération des mails expéditeur est toujours aussi lente.. J'avais un peu simplifié ma requête dans mon précédent post, la syntaxe exacte est la suivante :


$reponse = $db->query('select t1.mail_expe, t1.number, lu
from mails t1
where t1.number = (select max(t2.number) from mails t2 where t2.mail_expe=t1.mail_expe) AND ID = \'' .$id. '\'
ORDER BY number DESC');
while ($donnees = $reponse->fetch())

J'utilise cette syntaxe pour afficher le statut du mail (lu/non lu)

ex: si la colonne "lu" de la dernière entrée de mail_expe est égale à 1, alors le dernier mail à déjà été ouvert on affiche donc mail_expe avec une couleur grisée, sinon on affiche mail_expe en blanc avec un soulignement.

J'ai trouvé cette syntaxe sur internet après plusieurs essais perso non fructueux, elle fonctionne mais serai donc la cause du ralentissement.

Je me retrouve donc au point de départ et suis ouvert à toute propositions :)

- - - - - - - - - - -Fusion. Pas bien de faire du flood - - - - - - - - - - -

EDIT : Ma balise CODE n'a apparemment pas plus, je ne peux meme plus modifier mon message précédent je le reposte donc sans balise cette fois

Salut ! Bon j'ai eu quelques petits soucis pour avoir mon dédié mais c'est chose faite. Je viens de terminer le dump de la BDD et les modifs afin de rendre le site opérationnel chez mon nouvel hébergeur, bilan même problème. Le site en lui même est beaucoup plus fluide mais la requête de récupération des mails expéditeur est toujours aussi lente.. J'avais un peu simplifié ma requête dans mon précédent post, la syntaxe exacte est la suivante :


$reponse = $db->query('select t1.mail_expe, t1.number, lu
from mails t1
where t1.number = (select max(t2.number) from mails t2 where t2.mail_expe=t1.mail_expe) AND ID = \'' .$id. '\'
ORDER BY number DESC');
while ($donnees = $reponse->fetch())

J'utilise cette syntaxe pour afficher le statut du mail (lu/non lu)

ex: si la colonne "lu" de la dernière entrée de mail_expe est égale à 1, alors le dernier mail à déjà été ouvert on affiche donc mail_expe avec une couleur grisée, sinon on affiche mail_expe en blanc avec un soulignement.

J'ai trouvé cette syntaxe sur internet après plusieurs essais perso non fructueux, elle fonctionne mais serai donc la cause du ralentissement.

Je me retrouve donc au point de départ et suis ouvert à toute propositions :)

- - - - - - - - - - -Fusion. Pas bien de faire du flood - - - - - - - - - - -

Salut ! Bon j'ai eu quelques petits soucis pour avoir mon dédié mais c'est chose faite. Je viens de terminer le dump de la BDD et les modifs afin de rendre le site opérationnel chez mon nouvel hébergeur, bilan même problème. Le site en lui même est beaucoup plus fluide mais la requête de récupération des mails expéditeur est toujours aussi lente.. J'avais un peu simplifié ma requête dans mon précédent post, la syntaxe exacte est la suivante :


$reponse = $db->query('select t1.mail_expe, t1.number, lu
from mails t1
where t1.number = (select max(t2.number) from mails t2 where t2.mail_expe=t1.mail_expe) AND ID = \'' .$id. '\'
ORDER BY number DESC');
while ($donnees = $reponse->fetch())

J'utilise cette syntaxe pour afficher le statut du mail (lu/non lu)

ex: si la colonne "lu" de la dernière entrée de mail_expe est égale à 1, alors le dernier mail à déjà été ouvert on affiche donc mail_expe avec une couleur grisée, sinon on affiche mail_expe en blanc avec un soulignement.

J'ai trouvé cette syntaxe sur internet après plusieurs essais perso non fructueux, elle fonctionne mais serai donc la cause du ralentissement.

Je me retrouve donc au point de départ et suis ouvert à toute propositions :)



EDIT : le message precedent a completement bugué à cause de ma balise CODE.. je reposte donc à la suite
 
Statut
La discussion n'est pas ouverte à d'autres réponses
Retour
Haut