A Chrome kérés azt mondja: "Ideiglenes fejlécek láthatók":
Amikor a böngésző először küldi ezt a kérést, a kérés blokkolódik, és nem érkezik válasz. Amikor a böngészőt újra kérik, hogy küldje el ezt a kérést, akkor a böngésző figyelmeztetést jelent, ha az előző kérésre nem válaszoltak, szóval hol lesz a probléma?
Többször is találkoztam vele a projekt során, és különböző helyzeteket mutatok be:
1. Az ideiglenes fejlécek jelennek meg, amikor minden kliens böngészőjét elérjük:
Hogyan kezeld ezt: Nézd meg azt az oldalt, ahol a kérés aktiválódott, hogy egyszerre aktiválódik-e az űrlap beküldése és az ajax kérés.
Például definiáljunk egy gombot, írjuk be a submit, és határozzuk meg az ajax eseményt a gombhoz;
Ez a forgatókönyv az egyik olyan jelenet, amely a korábbi fejlesztési folyamatunkban is felmerült
2. Néhány kliens böngésző jelenik meg
Hogyan kezeld ezt: Hívd fel a Chrome chrome://net-internals/#events-jét, majd indítsd újra a kérést, majd ellenőrizd a kérések naplóját, ahol a Provisional fejlécek láthatók;
Nézd meg, léteznek-e delegate_blocked_by kulcsszavak; Ez általában azért van, mert a böngészőbővítmény vagy az ügyfél szoftvere elfogja a kérést; A helyzetet a WebSense Endpoint fogja el;
Ha ez így van, akkor gyakorlatilag figyelmen kívül hagyható, az ügyfél saját problémája; Fontolóra veheted, hogy eltávolítod a bővítményt vagy a szoftvert, és újra megpróbálhatod, hogy még mindig megjelenik-e; Ha mégis előfordul, kérjük, nézze meg, hogy a következő feltételek alá esik-e
3. Minden kliens véletlenszerűen és alkalmanként tapasztalta ezt a hibát, és ha ez így van, akkor gyakran szerveroldali probléma
Kezelési módszer: Hibakeresés a telepítési architektúra alapján. Például néhány kulcsfontosságú folyamat a telepítési architektúránkban: nginx----> gateway application----> F5 terheléselosztó----> application server (docker).
Rétegről rétegre lehet hibakeresést végezni, az egyszerű mód, hogy közvetlenül írsz for loop curl kérést a szerver shell parancsával, és először hívod a legalacsonyabb alkalmazásszervert (ha attól tartsz, hogy a nyomás nem elég, több szállal is lenyomhatod); Felfelé nyomd fel; A stressztesztelés során valós időben láthatod, hogy a kérés elakad-e; Ha megtalálják, nagyon valószínű, hogy ez a probléma:
Jelenleg két helyzettel találkoztunk: az egyik az F5 szinten, néhány kérés sikertelenül elosztott terhelést az alkalmazásszerverre; Van egy olyan helyzet is, amikor az nginx szinten ragad;
Megoldás: Az F5 szintű terheléskiegyenlítő stratégiát átalakították a teljesítmény L4-ről szabványosra.
nginx szintű beraszkodott helyzetkezelési terv: Valójában nem vettem részt ebben a helyzetben, és értem, hogy sok nginx konfiguráció módosítása nem hatásos, végül csak kikapcsolni és újratelepíteni, így nem találtam meg a kulcspontot
Az én saját megoldásom, mert a Fiddler 4, amit használok, nem zárva normálisan, ezért újranyitottam a Fiddler 4-et, megpróbáltam kérni a weboldalt, de visszatért a normális állapotba, ekkor ismét bezártam a Fiddler 4-et.
|
Közzétéve 2018. 05. 22. 22:57:55
|
|
|
|
