Récemment, quand je travaillais sur un projet, certaines pages devaient charger beaucoup de données, et parfois, je cliquais sur la page sans attendre qu’elle se termine de charger, puis je cliquais à nouveau sur une autre page
Il y aura un état très lent d’animation suspendue lors du chargement de la page web, alors étudions-le attentivement aujourd’hui.
Au début, je pensais que cette situation se produirait sur de nombreux sites ou que mon problème de vitesse de réseau informatique, mais j’ai constaté que ce site n’avait pas cette situation, parfois je me retrouvais bloqué en postant, mais je cliquais sur d’autres pages de l’onglet pour charger rapidement.
Regardons de plus près aujourd’hui !! Le code testé en premier :
Code Homeview :
Code du contrôleur :
Pour l’analyse du code de test, notre contrôleur dispose de 3 méthodes, l’une est la page d’accueil, et les deux autres sont des méthodes de test
La requête Test1 bloque pendant 5 secondes puis renvoie les données à l’utilisateur
Les requêtes Test2 ne seront pas bloquées et renverront directement les données à l’utilisateur
Notre page d’accueil est composée de deux interfaces pour les requêtes Ajax, qui sont des requêtes asynchrones, donc il n’y a pas de problème de blocage.
Nous constaterons que la méthode Test1 ne produit le contenu qu’après que Test2 en ait produit (Normalement, la page affiche directement le contenu retourné par Test2, puis attend 5 secondes pour produire le contenu retourné par Test1, car js ne bloque pas）
Ensuite, nous accédons directement aux interfaces Test1 et Test2, nous accédons d’abord à Test1, puis immédiatement à Test2, et constatons que Test2 doit attendre que Test1 revienne complet, comme montré dans la figure ci-dessous :
Si une requête de page active un verrou de lecteur, les autres requêtes traitées simultanément dans la même session ne pourront pas mettre à jour l’état de la session, mais au moins elles pourront être lues. Si une page demande un verrouillage d’écriture pour l’état de la session, alors toutes les autres pages sont bloquées, qu’elles souhaitent lire ou écrire du contenu. Par exemple, si deux vues de programme écrivent du contenu dans la même session en même temps, un programme doit attendre que l’autre soit terminé avant de pouvoir être écrit. Dans la programmation AJAX, il est important d’être conscient de ce qui se produit.
Note spéciale : Ce n’est que lors de l’écriture d’une session que Asp.net bloquera la requête, mais tant que vous avez visité la page où la session est écrite, comme l’opération après la connexion au système avec la session (la session est verrouillée jusqu’à son expiration, bien sûr, il n’y a que le cas où l’ID de session reste le même). Il y aura ce problème.
Informations sur les internautes
Tant que le site utilise une session, chaque requête verrouillera la session tout au long de sa durée de vie, de sorte que les requêtes avec le même session id doivent attendre d’être déverrouillées
Cela signifie que si le site web a une page à expiration, il ne peut rien faire, et il faut attendre que la page limitée se charge.
Vous ne pouvez pas non plus, plusieurs requêtes ajax simultanées sur la même page, vous ne pouvez pas le faire, requêtes de sondage par messages.
Pour résumer :Si vous prenez une session à la demande, si vous n’apportez pas de session à la demande, la situation ci-dessus ne se produira pas
Solution:
Ajout de la fonctionnalité SessionState(System.Web.SessionState.SessionStateBehavior.ReadOnly) au contrôleur contrôleur
Note:
Obligatoire signifie que vous demandez un verrouillage exclusif sur Session (c’est-à-dire aucun traitement parallèle des requêtes pour le même Session ID)
ReadOnly signifie que vous demandez un verrouillage non exclusif sur Session (c’est-à-dire que votre demande doit toujours attendre que les requêtes avec un verrouillage exclusif se terminent), mais vous pouvez traiter les demandes avec un verrouillage non exclusif Des verrous en parallèle. Cependant, c’est à vous de vous assurer que votre code n’écrit pas dans Session. Ce n’est pas forcément imposé par le cadre)
ReadOnly signifie que la session que vous demandez est un verrou non exclusif (c’est-à-dire que votre requête doit toujours attendre la complétude, la demande d’un verrou exclusif mais vous pouvez traiter une requête avec un verrou parallèle non exclusif). Mais il faut s’assurer que votre code n’écrit pas de sessions. Il n’est pas nécessaire que ce soit exécuté par le framework)
|
Publié sur 22/09/2017 17:32:59
|
|
|
|
Propriétaire