Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Lenteurs accès site internet
Bonsoir,
J'utilise SQL Serveur + IIS + PHP pour un site internet.
Jusqu'a très récemment, SQL SRV était installé sur la meme machine que IIS.
Par soucis de sécurité, nous avons déplacé la base de donnée sur un autre serveur.
Le problème est que lorsque j'accède maintenant à mon site celui-ci est très lent alors qu'avant ca fonctionnait ...
Je ne sais pas d'ou cela peut provenir, avez-vous une idée ?
Merci d'avance
Mathieu
Très bonne démarche, SQL SERVER doit être installé sur un serveur qui lui est entièrement dédié...
Essayez d'analyser vos lenteurs, temps d’exécution des requêtes (sql profiler...)
Latence réseau intervenant désormais lors des allez retour IIS->SQL SERVER puis SQL SERVER->IIS.
n'auriez vous pas par hasard des requêtes SQL lancées à l'intérieur de boucles PHP ?
Typique des problèmes de performances des applications actuelles...n'auriez vous pas par hasard des requêtes SQL lancées à l'intérieur de boucles PHP ?
30 petites requetes envoyées au server alors qu'une seule plus grosse suffirait..
Résultat: on prend trente fois la latence du réseau... au lieu d'une
Vos problèmes apparaissent précisement car maintenant que vos serveurs sont séparés, les données transitant entre SQL SERVER et IIS subissent les latences du réseau d'ou l'interet de faire le moins d'appel possible en rationnalisant ces appels et en limitant au maximum le volume des informations échangées...
Pour celà les ORM sont une catastrophe: texte de requetes enormes, allez retour incessants pour instancier des objets enormes seulement pour afficher le nom et le prenom de l'utilisateur+ ce satané lazy loading.
J'entends encore l' "architecte .NET" d'une grande SSII avec LINQ : "c'est génial avec le lazy loading plus besoin de gérer ce que l'on doit appeler... on ne demande les données que si on en a besoin..." oui mais bonjour le résultat!
Sur ce... excusez moi ce long monologue...
Et pardon Mathieur ne le prends pas pour toi
Hm, en théorie, entre le serveur web et le serveur BDD, c'est du très haut débit.
Oui avoir une requête au lieu de 30, c'est mieux, mais pour moi, sauf réseau pourri, ça ne peut pas vraiment avoir un impact lourd sur les perfs du site.
Pour ma part, autant je suis extrêmement attentif aux flux client-serveur, autant pour les flux serveur web-serveur BDD, je me "contente" de ne pas faire de superflu niveau requêtes, sans chercher l'optimisation maximale.
Bon après, les appels serveur BDD dans des boucles, je suis ok pour dire que c'est à proscrire autant que possible (et dans 99,99% des cas c'est possible)
En l'occurrence je pense que plusieurs questions s'imposent :
- qu'en est-il du réseau entre tes deux serveurs ?
- les lenteurs sont-elles systématiques : sur toutes les pages, toutes les requêtes, quelque soit la configuration du poste client etc...
Certes mais vous sous-estimez, je crois, le nbr de requetes que peuvent générer les développeurs pour l'affichage d'une seule page.Hm, en théorie, entre le serveur web et le serveur BDD, c'est du très haut débit.
Oui avoir une requête au lieu de 30, c'est mieux, mais pour moi, sauf réseau pourri, ça ne peut pas vraiment avoir un impact lourd sur les perfs du site.
Pour ma part, le record est de 6500 requetes pour une page...
Je vous accorde c'est de la bêtise pure mais ne serait ce que 200/300 requete/pages ce n'est pas rare or même avec une latence très faible, avouez qu'il est difficile d'afficher la page en moins de 3/4 de secondes...
Ceci dis nous parlons dans le vide est c'est ma faute...
Attendons les réponses de l'initiateur de ce 'topic'.
J'ajouterais: qu'entendez vous pas lent?
C'est vrai que là je bosse avec du LINQ (2 Entity, en 3.5 c'est pas glop...) et ça génère un grand nombre de requêtes.
Mais effectivement, ça n'est pas parce que c'est moins sensible que les flux client-serveur qu'il faut bâcler cette partie. Je suis bien d'accord.
L'objet de mon message était plutôt (et nous sommes donc encore une fois d'accord) de dire qu'il nous faut plus d'indications, et préciser le problème avant de commencer à fouiller le code PHP pour diminuer les appels en base.
PS : pour info, à combien avez-vous pu réduire les 6500 ? Ca venait d'où ?
Merci beaucoup pour toutes vos réponses, quel beau débat !
Toutes les pages sont très longues à atteindre, et certaines pages ont très peu de requêtes ...
Juste une beau petit "SELECT" qui va aller chercher une liste d'enregistrement dans une table avec 1 ou 2 jointures...
Je continue de chercher ...
Merci encore,
mathieu
Tracer la longueur des fonction dans lesquelles vous faites vos requêtes vous serez fixé....
Pour les 6500...de mémoire j'etais tombé à 6...
Pages affichant des résultats médicaux pour un patient le long de la journée...
Table html générée dans des foreach imbriqués dans des foreach imbriqués dans des foreach avec des SQLCONNEction.open()dans les foreach...
A oui j'oubliais le code "propre" avec des fonctions dans les couches prenant en entrée la PK d'une table:
GetImageOFClient(idclient integer)
GetNomOFClient(idclient integer)
GetPrenomOFClient(idclient integer)
etc...
Pour infos j'ai quitté la boite depuis... c'est le directeur technique en place qui avait fait l'appli et la "modelisation"....
Hé bien, je dirais que vous avez la solution sous les yeux...Envoyé par iberserk
A la différence d'une requête SQL ramenant toutes les données en un seul aller retour entre client et serveur, la succession d'appel de fonction que vous avez dans votre code provoque un appel d'AR à chaque donnée.
Sachant que les round-trip, c'est ce qu'il y a de plus couteux dans une solution distribuée (par ce que Ethernet n'est pas un protocole déterministe), vous avez devant vous un développement des plus stupide !
A +
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
* * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *
Ce n'était que l'explication du nombre insolent de requête qu'effectuait l'application que j'avais audité...la succession d'appel de fonction que vous avez dans votre code provoque un appel d'AR à chaque donnée
Peut-être le code de mathieu77186 ne possède pas les même travers...
Répondre avec citation
Partager