En serveropgradering kræver en påvist flaskehals

En langsom portal gør en større maskine til en tænkelig løsning. Om den ekstra kapacitet forbedrer forløbet, afhænger dog af, hvad det venter på. En kapacitetsbeslutning skal derfor knyttes til den observerede flaskehals.

Prøv to forklaringer på samme ventetid

Følgende sammenligning er helt hypotetisk. Den indeholder ingen fund fra et kundeprojekt eller målte ydelsesgevinster.

Begge årsager kan optræde samtidig. Applikation, netværk eller en ekstern tjeneste kan også bidrage til ventetiden. Én CPU-værdi forklarer derfor ikke hele forløbet.

Beskriv formålet med en ændring

Viser det konkrete forløb unødige små datakald, ville vi først undersøge deres struktur. Mere processorkraft fjerner ikke automatisk antallet af kald eller omkostningen ved hver datavej. En målrettet sammenligning kan vise, om færre ture frem og tilbage hjælper opgaven.

Det begrunder ikke, at maskinen altid skal forblive uændret. Ved påvist kapacitetsmangel kan mere kapacitet være fornuftig, eksempelvis når arbejdet overstiger de tilgængelige ressourcer. Beslutningen bør angive, hvilken grænse den flytter, og hvordan nytten kan ses.

Opgave, tilladte data og forventet resultat skal være sammenlignelige. Færre felter, en fyldt cache eller lavere samtidig belastning kan ellers forklare forskellen. Et hurtigere svar med manglende poster er ikke et tilsvarende resultat.

Spørgsmålet til et forslag er derfor: Hvilken observeret årsag skal det påvirke, og hvordan testes netop den effekt? Det gælder en ny server såvel som en ændring af dataadgangen.

Kilder

• Microsoft — Chatty I/O antipattern

• Microsoft — Architecture strategies for defining performance targets