Lenteurs accès site internet

[mathieu77186]

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

[iberserk]

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.

[aieeeuuuuu]

n'auriez vous pas par hasard des requêtes SQL lancées à l'intérieur de boucles PHP ?

[iberserk]

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...
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

[nox75]

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...

[iberserk]

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.

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.

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?

[nox75]

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ù ?

[mathieu77186]

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

[iberserk]

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...

[iberserk]

Pour infos j'ai quitté la boite depuis... c'est le directeur technique en place qui avait fait l'appli et la "modelisation"....

[SQLpro]

Envoyé par iberserk

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...

Hé bien, je dirais que vous avez la solution sous les yeux...
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 +

[iberserk]

la succession d'appel de fonction que vous avez dans votre code provoque un appel d'AR à chaque donnée

Ce n'était que l'explication du nombre insolent de requête qu'effectuait l'application que j'avais audité...

Peut-être le code de mathieu77186 ne possède pas les même travers...