Kürzlich, als ich an einem Projekt gearbeitet habe, mussten einige Seiten viele Daten laden, und manchmal klickte ich auf die Seite, ohne auf das Laden zu warten, und klickte dann erneut auf eine andere Seite
Beim Laden der Webseite wird es einen sehr langsamen Zustand der Suspendierung geben, also lassen Sie uns das heute genau untersuchen.
Zuerst dachte ich, dass diese Situation auf vielen Webseiten auftreten würde oder ein Problem mit der Geschwindigkeit meines Computernetzwerks, aber ich stellte fest, dass diese Seite dieses Problem nicht hatte, manchmal blieb ich beim Posten hängen, aber ich klickte auf andere Seiten im Tab, um schnell zu laden.
Schauen wir uns heute genauer an!! Der zuerst getestete Code:
Homeview-Code:
Controller-Code:
Für die Testcode-Analyse hat unser Controller drei Methoden: eine ist die Startseite, die anderen beiden sind Testmethoden
Die Test1-Anfrage blockiert für 5 Sekunden und gibt dann Daten an den Benutzer zurück
Test2-Anfragen blockieren nicht und geben Daten direkt an den Benutzer zurück
Unsere Startseite zeigt zwei Schnittstellen für Ajax-Anfragen, also asynchrone Anfragen, sodass es kein Blockierungsproblem gibt.
Wir werden feststellen, dass die Test1-Methode Inhalte erst ausgibt, nachdem Test2 Inhalte ausgegeben hat (Normalerweise gibt die Seite den von Test2 zurückgegebenen Inhalt direkt aus und wartet dann 5 Sekunden, um den von Test1 zurückgegebenen Inhalt auszugeben, da js nicht blockiert)
Dann greifen wir direkt auf die Test1- und Test2-Schnittstellen zu, zuerst auf Test1 und dann sofort auf Test2, und stellen fest, dass Test2 warten muss, bis Test1 zum Vollständigen zurückkehrt, wie in der untenstehenden Abbildung gezeigt:
Wenn eine Seitenanfrage eine Lesersperre setzt, können andere Anfragen, die gleichzeitig in derselben Sitzung verarbeitet werden, den Sitzungszustand nicht aktualisieren, aber zumindest können sie gelesen werden. Wenn eine Seite eine Schreibsperre für den Sitzungszustand anfordert, werden alle anderen Seiten blockiert, unabhängig davon, ob sie Inhalte lesen oder schreiben möchten. Wenn zum Beispiel zwei Programmansichten gleichzeitig Inhalte in derselben Sitzung schreiben, muss ein Programm warten, bis das andere Programm fertig ist, bevor es geschrieben werden kann. In der AJAX-Programmierung ist es wichtig, sich dessen bewusst zu sein.
Besonderer Hinweis: Nur beim Schreiben einer Sitzung blockieren Asp.net die Anfrage, aber solange du die Seite besucht hast, auf der die Sitzung geschrieben wurde, zum Beispiel die Operation nach dem Einloggen im System mit der Sitzung (die Sitzung ist natürlich bis zum Ablauf gesperrt, es ist nur so, dass die SessionID gleich ist). Es wird dieses Problem geben.
Informationen zum Internetnutzer
Solange die Website eine Sitzung verwendet, sperrt jede Anfrage die Sitzung während ihrer gesamten Lebensdauer, sodass Anfragen mit derselben Sessionid warten müssen, um freigeschaltet zu werden
Das bedeutet, dass die Website, wenn sie eine zeitgesteuerte Seite hat, nichts tun kann und man warten muss, bis die zeitgesteuerte Seite geladen ist.
Du kannst es auch nicht machen, mehrere Ajax-Gleichzeitanfragen auf derselben Seite, du kannst es nicht, Nachrichten-Polling-Anfragen.
Zusammengefasst:Wenn Sie eine Sitzung zur Anfrage führen, wenn Sie keine Sitzung zur Anfrage bringen, wird die oben genannte Situation nicht eintreten
Lösung:
Die Funktion SessionState(System.Web.SessionState.SessionStateBehavior.ReadOnly) wurde dem Controller-Controller hinzugefügt
Anmerkung:
Erforderlich bedeutet, dass Sie eine exklusive Sperre für die Sitzung anfordern (d. h. keine parallele Verarbeitung von Anfragen für dieselbe SessionID) ReadOnly bedeutet, dass du eine nicht-exklusive Sperre für die Sitzung anfragst (d. h. deine Anfrage muss noch warten, bis Anfragen mit exklusiver Sperre abgeschlossen sind, aber du kannst Anfragen mit nicht-exklusiven bearbeiten Parallele Schlösser eingebaut. Es liegt jedoch an dir, sicherzustellen, dass dein Code nicht in Session geschrieben wird. Es wird nicht unbedingt vom Rahmen durchgesetzt) Required bedeutet den von dir angeforderten Session-Mutex (d. h. es besteht keine Verpflichtung, dieselbe SessionID parallel zu verarbeiten).
ReadOnly bedeutet, dass die von dir angeforderte Sitzung eine nicht-exklusive Sperre ist (d. h. deine Anfrage muss noch auf den Abschluss warten, die Anfrage für eine exklusive Sperre, aber du kannst eine Anfrage mit einer parallelen nicht-exklusiven Sperre bearbeiten). Aber du solltest sicherstellen, dass dein Code keine Sitzungen schreibt. Es muss nicht vom Framework ausgeführt werden)
|