In diesem Artikel werden hauptsächlich relevante Informationen zur Leistungsoptimierungsmethode von Ajax-Non-Refresh-Paging vorgestellt. Freunde, die sie benötigen, können darauf verweisen
Ajax-Non-Refresh-Paging ist bereits eine Sache, mit der jeder vertraut ist. Wahrscheinlich gibt es auf der Web-Frontend-Seite eine js-Methode, die die serverseitige Paging-Datenschnittstelle über Ajax anfordert. Nach dem Abrufen der Daten wird eine HTML-Struktur auf der Seite erstellt und dem Benutzer angezeigt, ähnlich der folgenden :
<script type=”text/javascript”>
function getPage(pageIndex){
ajax({
url:” RemoteInterface.cgi”,
method:”get”,
data:{pageIndex:pageIndex},
callback:callback
});
}
function callback(datalist){
//todo:根据返回的datalist数据创建html结构展现给用户。
}
</script>Nach dem Login kopieren
Unter diesen ist RemoteInterface.cgi eine serverseitige Schnittstelle. Wir sind hier räumlich begrenzt und die beteiligten Beispielcodes sind möglicherweise nicht vollständig, nur um die Bedeutung klar auszudrücken.
Auf der Benutzeroberfläche gibt es möglicherweise verschiedene Arten von Paging-Steuerelementen, mit denen jeder vertraut ist, wie zum Beispiel:
Aber es ist nichts weiter, als dass der Benutzer auf das Steuerelement klickt, um die Methode getPage(pageIndex) auszulösen. Diese getPage-Methode ist möglicherweise nicht so einfach .
Wenn wir es gemäß Code-Snippet 1 schreiben, können wir uns vorstellen, dass RemoteInterface.cgi jedes Mal, wenn der Benutzer klickt, um die Seite umzublättern, einmal angefordert wird, wobei die mögliche Aktualisierung der Daten außer Acht gelassen wird Beim ersten Mal und später Die von jedem getPage(1), getPage(2), getPage(3) usw. ausgelösten Remote-Schnittstellenanforderungen und der Datenverkehr zum und vom Netzwerk wiederholen sich tatsächlich und sind unnötig. Diese Daten können in irgendeiner Form auf der Seite zwischengespeichert werden, wenn jede Seite zum ersten Mal angefordert wird. Wenn der Benutzer daran interessiert ist, die zuvor aufgerufene Seite noch einmal anzusehen, sollte die Methode getPage zunächst prüfen, ob die Seite im lokalen Cache enthalten ist Wenn ja, werden sie dem Benutzer direkt erneut präsentiert, anstatt die Remote-Schnittstelle aufzurufen. Gemäß dieser Idee können wir das Code-Snippet 1 wie folgt ändern:
<script type=”text/javascript”>
var pageDatalist={};
function getPage(pageIndex){
if(pageDatalist[pageIndex]){ //如果本地的数据列表中包含当前请求页码的数据
showPage(pageDatalist[pageIndex])//直接展现当前数据
}
else
{
ajax({
url:” RemoteInterface.cgi”,
method:”get”,
data:{pageIndex:pageIndex},
callback:callback
});
}
}
function callback(pageIndex,datalist){
pageDatalist[pageIndex]= datalist; //缓存数据
showPage(datalist);//展现数据
}
function showPage(datalist){
//todo:根据返回的datalist数据创建html结构展现给用户。
}
</script>Nach dem Login kopieren
Dies spart die Umlaufzeit von Netzwerkanfragen und mehr Wichtig: Der Zweck besteht darin, wertvollen Netzwerkverkehr einzusparen und die Belastung des Schnittstellenservers zu verringern. In Umgebungen mit geringer Netzwerkgeschwindigkeit oder wenn der Betriebsdruck des Schnittstellenservers bereits relativ hoch ist, kann diese notwendige Verbesserung deutliche Optimierungseffekte zeigen. Die erste der berühmten 34 Yahoo-Regeln besteht darin, die Anzahl der HTTP-Anfragen zu minimieren. Ajax-asynchrone Anfragen fallen zweifellos in den Bereich von http-Anfragen. Webanwendungen mit geringem Datenverkehr mögen unnötig erscheinen, aber stellen Sie sich vor, es gäbe eine Seite wie diese: 10 Millionen Besuche pro Tag, Benutzer blättern durchschnittlich 5 Seiten um und eine Seite wird wiederholt angezeigt. Dann löst eine solche Seite entsprechend der Art und Weise, wie Code-Schnipsel 1 geschrieben wird, durchschnittlich 50 Millionen Datenanfragen pro Tag aus, und entsprechend der Art und Weise, wie Code-Schnipsel 2 geschrieben wird, kann sie durchschnittlich mindestens 10 Millionen Anfragen pro Tag reduzieren . Wenn die jeweils angeforderte Datenmenge 20 KB beträgt, können Sie 10 Millionen * 20 KB = 200.000.000 KB einsparen, was etwa 190 GB Netzwerkverkehr entspricht. Die dadurch eingesparten Ressourcen sind durchaus beträchtlich.
Wenn Sie tiefer eintauchen möchten, ist die Daten-Caching-Methode in Code-Snippet 2 eine Diskussion wert. Bisher gingen wir davon aus, dass die Aktualität von Paging-Daten vernachlässigt werden kann, aber in tatsächlichen Anwendungen ist die Aktualität ein unvermeidbares Problem. Caching wird zweifellos zu einer Verringerung der Aktualität führen. Eine echte Caching-Lösung sollte auch auf der Analyse und den Kompromissen der Aktualitätsanforderungen der Anwendung basieren.
Bei Inhalten, bei denen die Aktualität im Allgemeinen nicht im Vordergrund steht, sollte das Zwischenspeichern auf der Seite dennoch akzeptabel sein. Erstens bleiben Benutzer nicht die ganze Zeit auf einer Seite, wenn es zu einem Sprung zwischen Seiten und Neuladen kommt aktualisierte Daten. Darüber hinaus kann der Benutzer, wenn er die Angewohnheit hat, die Seite zu aktualisieren, die Seite aktualisieren, wenn er insbesondere sehen möchte, ob die Liste aktualisierte Daten enthält. Wenn Sie nach Perfektion streben, können Sie auch einen Zeitbereich festlegen, beispielsweise 5 Minuten. Wenn der Benutzer länger als 5 Minuten auf der aktuellen Seite verweilt, wird beim Umblättern innerhalb von 5 Minuten zunächst der Cache auf der Seite gelesen und beim Umblättern nach 5 Minuten erneut die Serverdaten angefordert.
Wenn wir in einigen Fällen die Häufigkeit der Datenaktualisierung vorhersagen können, z. B. wie viele Tage eine Datenaktualisierung stattfinden wird, können wir sogar in Betracht ziehen, lokalen Speicher zu verwenden, um nach einem bestimmten Zeitraum eine Anfrage nach Serverdaten auszulösen von Zeit, so dass die Anfrage Die Einsparungen bei Daten und Verkehr sind noch gründlicher. Welche Art von Caching-Methode geeignet ist, hängt natürlich letztendlich von den Aktualitätsanforderungen des Produkts ab, aber der Grundsatz besteht darin, Anfragen und Traffic so weit wie möglich einzusparen, insbesondere bei Seiten mit vielen Besuchen.
Ist Caching für einen Datentyp mit hohen Aktualitätsanforderungen völlig ungeeignet? Natürlich nicht, aber die Gesamtidee muss sich ändern. Im Allgemeinen können sogenannte Änderungen hauptsächlich bedeuten, dass die Daten in der Liste erhöht, verringert oder geändert wurden, die überwiegende Mehrheit der Daten jedoch unverändert bleibt. In den meisten Fällen gelten die oben genannten Einstellungen weiterhin für das Caching innerhalb eines bestimmten Zeitraums.
Wenn eine nahezu Echtzeitaktualisierung der Daten erforderlich ist, können Sie leicht an die Verwendung eines Timers denken, z. B. an die Ausführung der getPage(pageIndex)-Methode und das Neuzeichnen der Liste alle 20 Sekunden. Wenn Sie jedoch an die bisherige Annahme von 10 Millionen Seitenaufrufen denken, werden Sie feststellen, dass dies zweifellos eine äußerst beängstigende Sache ist. Bei dieser Anzahl von Besuchen und der Häufigkeit von Wiederholungsversuchen steht der Server unter großem Druck. Was den Umgang mit dieser Situation betrifft, möchte ich alle bitten, einen Blick darauf zu werfen, wie Gmail, 163 Mailbox und Sina Mailbox mit Mailinglistenseiten umgehen. Sie erfüllten fast gleichzeitig unsere bisherigen Annahmen: extrem große tägliche Besuche, Echtzeitaktualisierung der Datenanforderungen usw. Es ist nicht schwer, mit einem Netzwerkpaketerfassungstool zu analysieren und festzustellen, dass keine Anfrage an den Server gestellt wird, wenn der Benutzer wiederholt Daten für dieselbe Seitennummer anfordert. Um sicherzustellen, dass Benutzer rechtzeitig benachrichtigt werden und die Mailingliste aktualisiert wird, wenn es eine Nachrichtenaktualisierung gibt, kann eine geplante und wiederholte asynchrone Anfrage verwendet werden, diese Anfrage führt jedoch nur eine Statusabfrage durch, anstatt die Liste zu aktualisieren. Erst wenn der Status mit Nachrichtenaktualisierungen abgerufen wird, wird eine Anforderung zum Abrufen aktualisierter Daten initiiert, oder die Statusabfrageschnittstelle gibt die aktualisierten Daten direkt zurück, wenn eine Aktualisierung gefunden wird. Tatsächlich ist das reguläre Statusabfrageintervall von 163 Postfächern relativ lang, etwa alle zwei Minuten. Das Intervall von Sina-Postfächern ist länger, etwa alle 5 Minuten. Es ist verständlich, dass sie ihr Bestes geben, um es zu verkürzen die Anzahl der Anfragen. Diese Art der Verarbeitung kann jedoch möglicherweise nicht nur vom Front-End durchgeführt werden. Der Implementierungsplan muss als Ganzes mit der Back-End-Schnittstelle betrachtet werden.
Jetzt schauen wir uns noch einmal die Daten-Caching-Methode in Code-Snippet 2 an. Jetzt diskutieren wir nicht mehr über die Anzahl der Anfragen und Traffic-Einsparungen. Werfen wir einen Blick auf die Front-End-Implementierung, um zu sehen, ob es etwas gibt, das es wert ist, genauer untersucht zu werden. Gemäß der in Codeausschnitt 2 gezeigten Verarbeitungsmethode werden die Originaldaten gespeichert. Bei einem erneuten Aufruf muss showPage(datalist) die HTML-Struktur basierend auf den Daten erneut rekonstruieren, um sie dem Benutzer anzuzeigen. Wir haben diesen Erstellungsprozess jedoch durchgeführt Ist es möglich, die Struktur direkt beim ersten Erstellen der Struktur zu speichern? Dies kann die wiederholten Berechnungen von js reduzieren, insbesondere wenn die Struktur komplexer ist. Denken Sie noch einmal darüber nach, diese Struktur wurde schon einmal auf der Seite erstellt. Das Zerstören und Erstellen einer neuen Struktur beim Umblättern verbraucht auch Ressourcen. Können Sie sie zum ersten Mal erstellen und beim Umblättern nicht zerstören? Steuern Sie den CSS-Stil, um ihn auszublenden, und wenn Sie die Seite wiederholt umblättern, steuern Sie nur die Anzeige oder das Ausblenden der anderen zwischen diesen erstellten Strukturen?
Schließlich ist die hier besprochene Methode möglicherweise nicht auf alle Szenarien anwendbar , aber entweder Es wird einige Inspiration geben, Sie können zu gegebener Zeit ein oder zwei davon ausprobieren. Gleichzeitig können die Ideen, wenn sie verbreitet werden, nicht nur auf aktualisierungsfreies Paging angewendet werden. Lassen Sie uns hier gemeinsam darüber diskutieren.
Ich habe das Obige für Sie zusammengestellt und hoffe, dass es Ihnen in Zukunft hilfreich sein wird.
Verwandte Artikel:
Ajax-Bild-Upload basierend auf Firefox
Ajax-Implementierungsmethode für den Popup-Ebeneneffekt beim Laden externer Seiten
Ajax-domänenübergreifende Methode (gleicher Basisdomänenname) zur Formularübermittlung
Das obige ist der detaillierte Inhalt vonMethode zur Leistungsoptimierung für Ajax-Non-Refresh-Paging. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
