À quelle vitesse faut-il créer une page Web générée dynamiquement?

Question

J'ai un certain nombre d'applications Web pilotées par les données qui s'adressent à la fois aux utilisateurs internes et aux utilisateurs publics et je voudrais évaluer la vitesse à laquelle une page devrait être créée (en millisecondes) afin de préserver la satisfaction et l'évolutivité des utilisateurs.

Alors, à quelle vitesse une page doit-elle être créée pour conserver un site rapide?

Les sites sont développés en ASP classic, avec un serveur SQL Server générant des jeux d'enregistrements XML que je rend à l'aide de XSLT. La technique n'est pas la plus efficace et les pages prennent entre 7 ms et 120 ms pour créer (c'est-à-dire un intervalle de temps entre la première ligne de code et le 'Response.Write') en fonction de la complexité de la page. Les pages plus lentes sont dues à la base de données exécutant des requêtes plus grandes et plus complexes. Même si je réécrivais tout le classique ASP en ASP.NET, il n'y aurait pas d'amélioration significative de la vitesse de rendu de la page.

J'ai souvent entendu Jeff dire qu'il voulait que SO soit le le site le plus rapide , et ses blogs ont discuté de l’optimisation de son code et de sa base de données, mais jusqu'o faut-il aller dans l'optimisation de votre code? Réduire les millisecondes en utilisant StringBuffer au lieu de String + String est-il une bonne utilisation de mon temps?

[Précision]

À quel moment commencez-vous à penser & "Cette page est trop longue à créer? &"; Est-ce plus de 20 ms, plus de 200 ms ou est-il acceptable qu'une page prenne une seconde à créer? Quels sont vos & Quot; temps cibles? & Quot;

Answer 1

Cela dépend entièrement de votre public cible et de vos cibles - j'ai travaillé sur des applications avec un événement 'onload' cible à & 4; il est prévu, ainsi que sur des applications où l'heure sur le serveur est supposée être < 1ms Cela peut aller dans les deux sens - mais quoi que vous fassiez, vous devez savoir que les optimisations de performances que vous faites au niveau du serveur risquent d'être dépassées par la performance du réseau, le principal goulot d'étranglement avec le Web et les temps de chargement perceptibles.

Yahoo possède des recommandations de qualité pour les performances générales d'un site Web, en particulier dans la zone de chargement perspicace. .

J'espère que vous êtes déjà assez intelligent pour mettre en cache ce que vous pouvez et faire les petites choses comme d'éviter les chaînes massives de Response.Writes ...

Answer 2

Les utilisateurs ne se soucient pas de la rapidité avec laquelle vous préparez vos données, ils ne se préoccupent que du temps de chargement réel de la page.

Si le rendu de votre travail est très lent, vos utilisateurs verront que votre site est lent. En ce qui concerne l’ASP classique, la concaténation de chaînes est considérée comme une très mauvaise pratique car elle sera très lente lorsque vous atteindrez la longueur de chaîne critique, ce qui deviendra un fardeau pour le serveur.

L'utilisation d'un tableau (jScript) ou d'un StringBuffer .NET peut améliorer considérablement le temps de rendu. En plus de réduire le temps d’utilisation du processeur qui permettrait à votre serveur de gérer plus de trafic, je dirais que ce genre d’optimisation évidente est très utile.

Answer 3

Un screencast très intéressant sur ce sujet peut être trouvé ici: texte du lien .

Bien que fabriqué par un gars de Rails, il s’applique parfaitement à d’autres frameworks.

Answer 4

Si vous pouvez gagner des millisecondes en changeant une chose, foncez!

Vous pouvez également consulter la mise en cache des requêtes de base de données.

Answer 5

La fréquence à laquelle il demande une nouvelle page est un facteur qui influe sur le temps de réponse du serveur au moment de répondre. Si vous présentez (par exemple) une page contenant de nombreuses informations que l'utilisateur va passer du temps à lire, un & Quot; rendu plus long & Quot; le temps est bon. En revanche, si la personne navigue rapidement dans les pages, elle voudra une réponse quasi instantanée.

Par exemple, si vous êtes sur un site d'actualités, vous serez probablement satisfait s'il vous faut une seconde ou deux secondes pour la page suivante, car vous allez passer 30 secondes pour la lire.

Par contre, si vous parcourez une carte interactive, vous souhaitez probablement que la réponse soit inférieure à une seconde.