Je suis perplexe. J'ai regardé la trace d'un pagecall qui était "lente" à charger selon mon patron, ce qui entraîne la chargement partiellement de la page, puis "sauter" à l'endroit de défilement mémorisé sur un post-plan.
J'ai découvert éventuellement, en utilisant ma trace, que tout mon chargement, du début préinit à la fin du rendu, a pris 1,94 seconde, dont 1,5 dépensé entre le pré-pré-préertif et la fin du prélendeur.
Une idée de ce qui pourrait causer cela? Le prochain plus gros temps de chargement est de 0,14 seconde, pour la fin du prélendeur.
Le problème pourrait provenir de mes questions à SQL Server ou une quantité trop vaste de commandes sur la page, même si la plupart sont "cachés"?
[EDIT:] Il semble que ma charge de page soit très longue lorsque je montre une certaine forme. Ma taille de rendu totale est de 91537 octets, dont 44483 sont dédiées à cette forme spécifique. Mon point de vue semble énorme. En outre: Un fichier JS 404 peut-il causer ce type de retard sur la charge?
[MISE À JOUR:] J'ai donc trouvé la requête la plus longue et il semble que même s'il semble assez chunky, il est terminé de fonctionner longtemps avant même que la page soit même chargée. Comme information ajoutée: J'utilise un peu de SqldataSources Thoughout les commandes, pour remplir mes listes déroulantes et autres choses intéressantes de similaires. Est-ce que c'est encombrer mon application?
5 Réponses :
Afin d'identifier la cause d'un goulot d'étranglement, vous devez vraiment profiler votre code avec un outil tel que Profileur de fourmis ou quelque chose de similaire.
Un profileur vous permettra d'identifier la zone problématique en vous indiquant quelles lignes de code sont plus lentes que d'autres.
Tout ce que je n'ai pas à dépenser 400 dollars pour trouver un seul problème dans cette application? : P
Je pensais que vous pouvez essayer des fourmis de profileur en le téléchargeant simplement :). De même, vous pouvez télécharger gratuitement le procès Visual Studio et donner le profileur VS gratuitement.
J'ai utilisé un essai de profileur de fourmis ainsi que l'assistant de performance de Visual Studio et les a trouvés comparables à bien des égards.
Les fourmis étaient simplement une suggestion - il existe de nombreuses alternatives. Ce site a de nombreuses questions concernant .NET Profilers.
Dans mon expérience (même problème que vous), il s'agit de 90% d'un problème SQL.
Mettez certains chronomètres autour de la requête que vous appelez pour savoir quelle requête fonctionne lentement.
Le contrôle ASP.NET Rendu ne peut pas prendre si longtemps ....
Le rendu des contrôles ASP.NET peut prendre longtemps à considérer qu'un contrôle peut être assez compliqué (penser à certains des composants Telerik Ajax, etc.).
Je suis d'accord avec ça. Surtout si vous utilisez l'un des contrôles de source de données. Exécutez le profileur SQL lors de l'exécution de l'application.
Oh, alors sqldatasource! = Bonne idée?
Je pense que cela dépend du volume de données que vous récupérez. Si vos requêtes retournent juste un groupe (jusqu'à des centaines), Sqldatasource est toujours bon. Ajustez votre requête avec le profileur et veillez à ne récupérer que les données que vous affichez sur la page. Si vous êtes sûr à 100% que votre requête fonctionne rapidement, regardez ailleurs.
Enfin trouvé le coupable: c'est une requête. Merci pour ça: p
J'utiliserais Yslow pour déterminer si c'est de quelque chose du côté client ou du serveur. Nous ajoutons parfois des minuteries à certaines requêtes, puis sortions le temps d'exécuter dans un commentaire HTML ... bien sûr les supprimer lorsque le test est terminé.
La page appelle-t-elle quelque chose hébergé sur un site externe?
Si le problème peut être attribué à quelque part entre le préinit et l'endurler, il n'y a probablement pas beaucoup de Yslow peut faire dans ce cas particulier. Mais je vais second que c'est toujours un bon outil et une réponse pertinente à la question plus générique dans le titre
Votre meilleur pari est d'utiliser le Assistant de performance dans Visual Studio et regardez l'arborescence d'appel de votre page. Cela vous donnera plus de détails sur le goulot d'étranglement de la performance exacte.
J'ai vu ce type de performance lorsqu'il y a trop de contrôles complexes déclarés sur la page. Bien que cela puisse facilement être associé à SQL. Pour savoir pour certains que vous devez regarder l'arborescence d'appel et savoir quel est l'appel le plus coûteux.
Bien sûr, si elle est liée à SQL, autant de personnes ont noté, "SQL Server Profiler" est l'outil à utiliser (étant donné que vous utilisez MSSQL). MySQL a "JetProfiler" (.com) que je n'ai pas essayé. Une fois que vous avez trouvé la requête lente, ce n'est pas rarement un problème d'indexation.
Après avoir lu votre mise à jour, je pense toujours que vous devez examiner cela dans un profileur pour savoir avec certitude.