Cache, belastning och uppvärmning i edge

Varje anrop till en apps värdnamn passerar edge. Tre saker där håller realmen snabb och stabil under belastning: en cache framför apparna, en kontroll som avvisar trafik rättvist när edge är överbelastad, och uppvärmning som håller en kall kopia av en app borta från besökare tills den är redo.

Cachen i edge

Cachen är ett steg i middleware-kedjan i kanten, Svarscache i kanten. Realmens kedja sätter standardvärdena; en organisation eller en app kan göra undantag. I steget lägger du till cachehinkar: en Öppen cache eller en Privat cache (per användare), var och en med ett valfritt sökvägsfilter (/static/*, *.js) och en Standard-TTL i kant. Kantregler och kantskript kan sätta egna tider.

Det här sparar edge:

• svar på GET och HEAD med status 200 och en tid att spara dem;
• aldrig ett svar med Set-Cookie, Cache-Control: no-store eller private i en öppen cache;
• aldrig ett svar vars Vary anger något annat än Accept-Encoding, så att ingen klient får någon annans variant.

Så beter den sig:

• En hämtning för en kall sida. När många anrop ber om en sida som cachen saknar går ett till appen och de andra väntar på dess svar. En rusning mot en ny sida når appen en gång. Misslyckas den hämtningen, eller får svaret inte sparas, hämtar de andra själva.
• Gamla svar, om webbplatsen vill: Svara med gammal kopia under förnyelse svarar med den gamla kopian så många sekunder efter att den gått ut, medan ett anrop hämtar en ny; Svara med gammal kopia vid appfel svarar med den gamla kopian när appen fallerar eller svarar 5xx. Appens egna stale-while-revalidate och stale-if-error gäller först, och dess must-revalidate eller no-cache stänger av dem för det svaret.
• Tömning. Varje ändring av en webbplats, dess regler eller dess steg tömmer webbplatsens cache.

Cachen finns i edges minne och delas av alla webbplatser: 32 MiB som standard, och inget enskilt svar över 2 MiB sparas (större strömmar igenom). De svar som använts minst nyligen försvinner först. Det här är inställningar för edge i deploy.json (settings.edge.ingress.cacheBytes, cacheObjectBytes); höj gränsen på en edge med minne över.

Kontroll av belastning

När edge har mer att göra än den hinner med svarar den direkt på en del anrop med 503 och Retry-After, i stället för att svara sent på alla. Den bestämmer sig direkt efter att ha läst ett anrops huvud, före allt annat arbete, utifrån två signaler: hur många anrop som pågår, och hur långt efter dess egen schemaläggning ligger.

Ordningen är rättvis:

1. Under gränsen går alla anrop igenom.
2. Över den avvisas de mest belastade webbplatserna först: en webbplats som har mer än sin andel av de pågående anropen, och namn som ingen webbplats har.
3. Längre över den avvisas alla kunders webbplatser.
4. Realmens egen trafik (skrivbordet, API:t, inloggningen) avvisas sist, så att du fortfarande når Manager medan dina webbplatser översvämmas.

Gränserna är inställningar för edge (settings.edge.admission): kneeInFlight (4 096 pågående anrop), siteKneeInFlight (1 024 för en webbplats), tenantInFlight (8 192), realmInFlight (16 384) och fördröjningsgränserna lagKneeMs (10 ms) och lagLimitMs (50 ms). Standardvärdena passar en edge med en arbetstråd per processorkärna; justera dem per installation.

Gränser för anrop per webbplats och per adress

Två hinkar med polletter begränsar hur fort anrop får komma:

En IPv6-klient räknas som sitt /64. Varje hink sparar två sekunder av sin takt till toppar. Båda är policyer under Policyer: sätt dem för realmen eller för en organisation eller ett projekt. Under realmen kan ett värde bara vara lägre än det ovanför, aldrig högre.

Långsamma klienter

En klient som skickar eller läser för långsamt förlorar sin anslutning i stället för att hålla upp resurser: ett anrops huvud måste komma inom 30 sekunder, en anropskropp får göra uppehåll i 60 sekunder, och en klient som inte läser något på 60 sekunder medan edge har data till den kopplas bort. Varje gräns gäller tid utan trafik, aldrig en hel överföring, så en stor uppladdning eller nedladdning som rör sig kopplas aldrig bort. Inställningarna heter clientHeadTimeoutMs, clientBodyIdleMs och clientWriteStallMs; 0 stänger av en.

Uppvärmning av nya kopior

En app kan lista uppvärmningssökvägar: sidor som edge frågar en ny kopia efter, med vart och ett av appens värdnamn, efter att dess hälsokontroll klarats och innan den får någon besökare. Ett ramverk som renderar en sida vid första anropet har den då klar innan den första riktiga besökaren kommer.

• Ange dem under appens Värdnamn, i Uppvärmningssökvägar, eller i appens velrix.json som deploy.warmPaths (högst 32 sökvägar, var och en börjar med /). När velrix.json anger dem visas de skrivskyddade i fliken.
• En kopia värms upp en gång, när den först startar eller kommer tillbaka efter ett fel. En kopia som är uppe värms inte upp igen.
• Uppvärmningen hör till att vara frisk. En sökväg som svarar något annat än 2xx eller 3xx, eller en uppvärmning som tar mer än 30 sekunder sammanlagt, håller kopian utanför drift. Vid en driftsättning klarar den nya revisionen då inte sin hälsokontroll och rullas tillbaka, så att en trasig sida aldrig når en besökare.
• Uppvärmningen fyller appens egna cachar. Cachen i edge fylls vid första riktiga anropet.

Nästa steg

• Publik adress och värdnamn
• Appar
• Policyer