Förbered appen för en trafiktopp
Av CodexierPublicerad 4 min läsning
En pushnotis till alla användare, ett nyhetsbrev, ett tv-inslag eller en kampanj som ligger på lönedagen den 25:e kan skicka in fler personer i appen på tio minuter än den brukar se på en vecka. Klarar inte backend det betalar du för uppmärksamheten och visar sedan alla ett felmeddelande. Guiden visar hur du hittar gränserna före den stora dagen, testar dem med liten budget, skapar marginal där det behövs och bygger appen så att den nedgraderas kontrollerat i stället för att krascha.
Känn till dina nuvarande gränser
Börja med en uppskattning. Hur många användare kan öppna appen de första tio minuterna? En push till alla eller ett omnämnande i rikstäckande tv kan ge en stor del av hela användarbasen på en gång. Lista sedan vad varje användare gör när appen öppnas: loggar in, laddar en startskärm, hämtar erbjudanden, kanske betalar. Varje sådant anrop går till backend, och det svagaste sätter gränsen.
- Databasanslutningar: många molndatabaser tillåter ett fast antal, och de tar slut före processorkraften.
- Gränser hos tredje part: sms-leverantörer, betaltjänster och BankID-integrationer har begränsningar och ibland köer.
- Tunga endpoints: en enda ooptimerad fråga på startskärmen kan göra allt annat långsamt.
- Hostingplaner med fast kapacitet, eller serverlösa funktioner med kallstarter och tak för samtidiga anrop.
Lasttesta med liten budget
Lasttester kräver inga dyra verktyg. Verktyg med öppen källkod som k6 eller Artillery kan simulera hundratals eller tusentals användare från en laptop eller en billig molnserver. Det viktiga är att testa realistiskt beteende, inte bara att bombardera en enda adress.
- Testa mot en stagingkopia med produktionslik data, aldrig direkt mot skarpa betalningar.
- Skripta den verkliga användarresan: öppna appen, logga in, ladda startskärmen, gör kampanjhandlingen.
- Öka lasten gradvis och notera vid vilken nivå svarstiderna börjar stiga.
- Titta på databasens och tredjepartstjänsternas instrumentpaneler under testet, inte bara på testverktyget.
- Åtgärda första flaskhalsen och testa igen. Det finns alltid en till.
Marginal i backend och databas
| Åtgärd | Vad den gör | När den passar |
|---|---|---|
| Cachning | Ger samma svar till många användare utan att fråga databasen | Startskärmar, produktlistor, kampanjinnehåll |
| CDN för bilder och filer | Levererar statiskt innehåll från servrar nära användaren | Alltid, för bilder och appresurser |
| Anslutningspoolning | Delar databasanslutningar mellan anrop | När anslutningarna tar slut före processorkraften |
| Tillfällig uppskalning | Mer kapacitet under kampanjperioden | Molndatabaser och hosting som tillåter det |
| Köer för långsamt arbete | Hanterar mejl, kvitton och synk i bakgrunden | Allt som användaren inte behöver vänta på |
Säg till dina leverantörer i förväg. Sms- och betalleverantörer kan ofta höja gränserna tillfälligt om du frågar, men inte mitt i toppen.
Kontrollerad nedgradering
Kontrollerad nedgradering innebär att appen behåller sin viktigaste funktion när delar är överbelastade. I stället för en tom felskärm ser användarna cachat innehåll, ett vänligt meddelande eller en kö. Bestäm i förväg vad som är viktigast den dagen.
Funktionsflaggor
Stäng av funktioner som inte är nödvändiga, som rekommendationer eller chatt, från en panel utan att släppa en ny appversion.
Cachad reserv
Om den aktuella erbjudandelistan inte kan laddas, visa senast kända version i stället för ett fel.
Väntrum
Vid biljettsläpp eller begränsade erbjudanden är en kö bättre än att alla går till kassan samtidigt.
Tydliga meddelanden
Berätta för användarna vad som händer och när de kan försöka igen, på enkel svenska.
Sprid ut pushnotiserna i stället för att skicka till alla samma sekund. Att skicka i omgångar under en kvart eller en halvtimme fördelar lasten nästan utan kostnad för kampanjen.
Bevakning under dagen
- En namngiven person som bevakar fel, svarstider och databaslast.
- Larm som når en telefon, inte bara en inkorg.
- En kort körbok: vilka flaggor som ska stängas av, hur man skalar upp, vem man ringer hos varje leverantör.
- Inga nya releaser den dagen. Frys appen och backend några dagar innan.
Vår tjänst för appunderhåll och skalning täcker lasttester, marginal och övervakning för befintliga appar, och vår prissida visar månadspriset. När du inte behöver det här: om kampanjen når några hundra användare utspridda över en dag klarar en välbyggd app på molnhosting det utan särskilda förberedelser. Läs vår säkerhetschecklista för mobilappar för andra sidan av beredskapen, eller boka ett samtal om en stor dag närmar sig.
Vanliga frågor
Hur långt före en kampanj bör vi lasttesta?
Minst två till tre veckor, så att det finns tid att åtgärda flaskhalsar och testa igen. Ett test dagen innan berättar bara att du har ett problem.
Löser en flytt till molnet skalningen automatiskt?
Nej. Molnhosting kan snabbt ge mer kapacitet, men databaser, gränser hos tredje part och långsam kod sätter fortfarande taket.
Är det säkert att lasttesta i produktion?
Sällan. Använd en stagingkopia, och kör aldrig lasttester mot skarpa betalningar eller BankID-flöden.
Vilken förbättring är billigast?
Att cacha innehåll som inte skiljer sig mellan användare och att sprida ut pushnotiserna. Båda kostar lite och tar bort en stor del av toppen.
Närmar sig en stor dag?
Boka 15 minuter. Berätta om kampanjen och appen, så säger vi var riskerna finns och vad du bör testa före dagen.
Boka ett kostnadsfritt 15-minuterssamtal