Kortlæg en komplet anmodning gennem Helsinki
Tegn stien for en repræsentativ handling, såsom at logge ind eller gemme et dokument. Hvor bruges databasen, cachen og eksterne API af den handling? Mål hvert trin, så en tilsyneladende langsom finsk server ikke forveksles med en fjern afhængighed eller applikationsflaskehals.
Placer de travleste afhængigheder bevidst
Husk hyppigt gentagne applikation-til-database-kald, når du vælger placering. En cache kan reducere gentagne læsninger, men den kræver også en plan for invalidering og gendannelse. Hvilke data skal være aktuelle, og hvilke svar kan sikkert genbruges? Bekræft den tilgængelige private forbindelse, før du designer ud fra den.
Test et cache-miss og en utilgængelig API
En varm cache kan skjule omkostningen ved den første rigtige anmodning. Test efter en genstart, med en tom cache og med en ekstern tjeneste, der får timeout. Angiv begrænsede genforsøg, og kontroller, at en gentagen anmodning ikke opretter en dublet handling. Disse tilfælde gør det lettere at dimensionere Helsinki-implementeringen realistisk.
Gør placeringen af sikkerhedskopier til en del af gendannelsestesten
En anden maskine i samme facilitet er ikke en geografisk gendannelsesplan. Registrer den faktiske sikkerhedskopidestination, og gendan en prøve uden for den primære fejlgrænse. Efter gendannelsen skal du kontrollere databaseforbindelser, applikationshemmeligheder og genopbygning af cachen, før du sender brugere til den gendannede tjeneste.