Quelle est la bonne information à cacher? Qu'est-ce qu'un bon temps de chargement de page?

Question

Je suis en train de développer un site de réseau social.

Et je pensais à l’évolutivité dès le premier jour du projet, j’ai peaufiné le site et les requêtes au mieux de mes capacités.

Cependant; Certaines pages sont très chargées en données et je ne sais pas trop si elles se chargent aussi vite que possible, alors je pensais mettre en œuvre une solution de mise en cache distribuée.

Mais je ne sais pas trop ce que je devrais mettre en cache et non pas en cache. Ou si le temps de chargement actuel d'une page est bon ou mauvais.

La requête la plus lourde consiste à récupérer les informations sur les membres. Cette requête obtient toutes les informations relatives aux membres, telles que les objectifs, les entrées de type blog, les encouragements, les photos, les mises à jour de statut (comme Twitter), les infos de blog (pour poster leurs entrées) etc etc.

Quoi qu'il en soit, devrais-je mettre cette information en cache? Et pensez-vous que les temps de chargement d'une page sont d'une rapidité raisonnable? Certaines pages durent moins d'une seconde entre 4 et 10 dixièmes de seconde.

Answer 1

Dans la mesure du possible, je mettrais en œuvre la mise en cache à chaque couche de votre application.

Vous pouvez mettre en cache les pages au niveau le plus élevé et les objets au niveau du code et vous assurer que votre base de données met en cache correctement les requêtes et les données de clé au niveau le plus bas.

En termes de QUOI vous devez mettre en cache, tous les objets auxquels on aura accès de manière répétée doivent être mis en cache, en particulier ceux qui ne risquent pas de changer très souvent. Vous pouvez alors réinitialiser le cache de cet objet uniquement lorsqu'il est modifié. (Veillez à ne pas mettre en cache des objets qui sont fréquemment mis à jour car un cycle constant de remplacement du cache à presque chaque chargement dégraderait les performances au lieu de l’améliorer.)

Pour mesurer les performances, je n’examinerais pas le temps nécessaire au chargement d’une page, mais à Google pour certains outils de mesure des performances, car vous devez vraiment tester la rapidité avec laquelle chaque page fonctionne sous pression. Votre page d'informations utilisateur peut ne pas être la plus grande cible de mise en cache si elle est rarement utilisée, par exemple. Vous devriez vous concentrer sur les pages les plus utilisées.

Answer 2

La réponse typique est:

• Informations de cache rarement mises à jour.
• Ne mettez pas en cache ce qui change fréquemment.

Dans votre cas, vous pouvez tout mettre en cache dans des fichiers plats (un fichier par utilisateur, par exemple) et détruire un fichier cache utilisateur chaque fois que quelque chose est mis à jour par le correspondant. Si le fichier cache n’existe pas, vous le créez avant d’afficher le contenu associé.

Maintenant, à propos du temps de chargement (qui peut être très différent selon l’emplacement de l’utilisateur), voici quelques chiffres informatifs tirés du forum PHP d’un site de jeu:

• Temps de chargement JS: 0.274
• Nombre de requêtes: 15
• Temps de chargement PHP: 0.0524
• Utilisation de la mémoire: 1,013 Mo

Et ceci est considéré par la communauté comme une bonne expérience. Mais c’est terriblement subjectif.

Answer 3

La question de chargement de page a déjà été posée:

Qu'est-ce qui est considéré comme un bon temps de réponse pour une application Web dynamique et personnalisée?

En termes de mise en cache, vous devez mesurer le temps que vous consacreriez au chargement des données à chaque fois par rapport au chargement à partir du cache. Plus la cache est grande, moins elle devient efficace. Donc, vous ne voulez pas charger trop de données dans le cache. Nous utilisons ici un cache dynamique, les données les moins récemment utilisées étant supprimées dès que nous atteignons la limite de taille du cache. Vous réglez ensuite la limite en fonction des résultats réels.

Answer 4

Pour les données spécifiques au profil utilisateur, enregistrez autant que vous le pouvez dans un ticket / cookie FormsAuth. La mise en cache (HttpContext.Current.Cache) des éléments spécifiques à l'utilisateur nécessitera X ressources sur votre serveur par utilisateur, comme le ferait une session (mais avec moins de maux de tête). Si vous pouvez décharger autant que possible le ticket ou le cookie de l'utilisateur (c'est comme 4K), vous aiderez réellement les performances de vos serveurs lors de la mise à l'échelle.

Vous ne devriez récupérer que les informations dont la page a besoin. Par exemple, si vous chargez des données de blog, NE CHARGEZ PAS les photos. C'est plus de travail, oui, mais si vous souhaitez faire évoluer votre système, vous devrez analyser les besoins de chaque page.

Assurez-vous de bien comprendre qu'il existe des différences entre la mise en cache de requêtes de base de données (réutilisation du plan d'exécution), la mise en cache d'objets (Httpcontext.Cache) et la mise en cache de pages (Response.Headers [Expires]).

Answer 5

Le gourou de la conception de sites Web Vincent Flanders suggère qu'un délai supérieur à 4 secondes est trop long pour charger une page Web. . Je pense que c'est une très bonne règle de base.

En ce qui concerne la mise en cache ou toute autre optimisation des performances, je vous recommanderais de procéder à des tests de performances. Il existe un certain nombre de kits de test de performance disponibles sur le marché. Les tests montreront où sont les problèmes. Il est inutile d'ajouter une logique de mise en cache à quelque chose qui fonctionne déjà bien. D’autre part, des problèmes de performances peuvent se produire et vous risquez de ne pas vous y attendre, impliquant des données que vous n’avez peut-être pas envisagées de mettre en cache.

Les tests de performances ont également permis de détecter des points dans votre code où des blocages sont en cours ou des optimisations simples pourraient vous aider. Peut-être qu’ajouter un index à une table accélérera une page au lieu d’ajouter un tas de logique de cache.

Je voudrais garder les choses simples et refactoriser les performances uniquement là où vous en avez besoin.

De plus, testez tôt et testez souvent. Je sais que beaucoup de gens disent de considérer les performances en dernier lieu, mais vous pouvez vraiment vous frayer un chemin si vous ne commencez pas au moins à les prendre en considération tôt dans le cycle de développement.

Answer 6

Certaines recherches suggèrent que les applications interactives doivent fournir un retour d’information dans un délai de 250 ms pour ne pas laisser l’utilisateur penser qu’il est bloqué ou que l’opération a échoué. Le niveau d'acceptation sur le Web est cependant un peu plus élevé, et le navigateur Web indique généralement qu'une nouvelle page est en cours de chargement. Avec AJAX, vous devez cependant veiller à donner votre avis, car le navigateur ne vous montrera pas ce qui se passe.