WordPress-benchmark: Reproducerbar test af hosting-ydeevne

Hvad en WordPress-benchmark giver svar på

En WordPress-benchmark begynder med et konkret spørgsmål: Indlæses en bestemt side hurtigt under fastlagte betingelser? For at gøre dette indlæser en browser HTML, billeder, scripts og andre ressourcer og viser siden. Resultatet beskriver samspillet mellem disse komponenter, ikke blot hastigheden på hostingserveren.

Et andet spørgsmål vedrører Reaktionsadfærd under belastning: Hvordan ændrer responstider og fejl sig, når der modtages forespørgsler, der følger en bestemt profil? Et enkelt sidebesøg giver ikke svaret på dette. Omvendt viser en HTTP-belastningstest ikke umiddelbart, hvor hurtigt en browser indlæser hele siden, så den bliver synlig.

I en offentlig blogartikel kan en sidecache levere færdig HTML; et CDN kan stille ressourcer eller svar til rådighed tættere på måleplaceringen. Samtidig påvirker tema, plugins, billeder og eksterne scripts resultatet. Hvilke andre årsager der kan gøre en side langsommere, forklares i artiklen om Skjulte faktorer, der nedsætter ydeevnen i WordPress.

To sammenlignende spørgsmål kan hjælpe med at vurdere hostingens indflydelse. Ved Sammenligning af stakke Du tilpasser hjemmesiden og indstillingerne så vidt muligt og dokumenterer de resterende forskelle. Ved sammenligning af pakker gennemgår du de tilbudte konfigurationer, herunder deres respektive cacher og tjenester. Dette er praktisk i forbindelse med en købsbeslutning, men isolerer ikke den rene serverydelse.

Notér derfor, hvilken side, hvilken takst og hvilket miljø der hører til et resultat. En fordel ved den testede blogartikel kan se anderledes ud, når den vises fra en indlogget konto. Målingen gælder for de dokumenterede betingelser og den angivne periode; den udgør hverken en generel testvinder eller en ydeevnegaranti.

At forstå browsermålinger og feltdata

En WordPress-hastighedstest med Lighthouse giver et Laboratorieoptagelse siden under bestemte målebetingelser. Browserprofil, enhed eller emulering, netværksprofil, måleplacering og værktøjsversion skal derfor medtages i protokollen. Kun på den måde kan man senere vurdere, om to målekørsler rent faktisk er sammenlignelige.

Lighthouse-Performance-Score er en vægtet sammenfatning af flere måleparametre. Den kan svinge som følge af ændringer i indhold og målebetingelser og skjuler, hvilken enkeltmåling der har ændret sig. Gentag målingen med den samme profil, og dokumenter de enkelte værdier for alle gennemløb i stedet for blot at vælge den bedste score.

Blandt de vigtige måleparametre er LCP: Den beskriver, hvornår det største relevante indholdselement er synligt indlæst. CLS registrerer uventede layoutforskydninger under brugen. INP beskriver reaktionsevnen på interaktioner; den kræver faktisk registrerede interaktioner og bestemmes ikke alene af en simpel sideindlæsning.

Chrome UX Report, også kaldet CrUX, leverer derimod de tilgængelige Feltdata fra besøg af deltagende virkelige brugere. Disse oplevelser afhænger blandt andet af deres enheder og netværk. De er ikke tilgængelige for alle sider og besvarer et andet spørgsmål end en laboratorietest udført under kontrollerede forhold.

Angiv for hver værdi, om den stammer fra laboratoriet eller fra feltet. En ren HTTP-forespørgsel kan f.eks. registrere status og svartid, men udfører ikke automatisk browserens rendering og interaktioner. Derfor kan LCP, CLS og INP ikke aflæses som en browseroplevelse ud fra denne forespørgsel.

At skelne korrekt mellem cache-niveauer

En Side-cache kan gemme færdig HTML til gentagne forespørgsler. En objektcache gemmer derimod applikationsdata, som WordPress har brug for under behandlingen. Derudover kan browseren genbruge allerede indlæste ressourcer lokalt; et CDN kan cache indhold på et yderligere niveau uden for den oprindelige server.

Ved en »warm« sidecache henter du en offentlig side gentagne gange efter en dokumenteret opvarmningsfase. Dette er relevant for indhold, der besøges ofte, men siger ikke meget om, hvor dyrt det er at generere det dynamisk. Notér, hvilken URL der er blevet opvarmet, og hvilke cache-regler og CDN-indstillinger der gjaldt.

For en forespørgsel uden cache skal du Cache-bypass Kontroller det grundigt, i stedet for blot at acceptere det. Et tilmeldt møde kan følge andre regler og levere personaliseret indhold. Kontroller det faktiske svar: En hurtig hentning er ikke meget værd, hvis den leverer forkert eller forældet indhold.

Et første besøg i en ny browsertilstand betyder ikke nødvendigvis, at server- eller CDN-cachen er tom. Ligeledes betyder en CDN-fejl ikke automatisk, at applikationscachen er tømt. Cache-headere kan give en indikation, men afhængigt af udbyderen beviser de ikke tilstanden på hvert enkelt involveret niveau; dokumentér derfor også de tilgængelige indstillinger og kontrolmetoder.

WordPress-objektcachen er som udgangspunkt begrænset til den pågældende anmodning, hvis der ikke er en passende persistent udvidelse. Konstanten WP_CACHE Dette aktiverer hverken Redis eller en automatisk caching-løsning. Hvilken rolle Redis og Memcached kan spille som en persistent objektcache, forklares i artiklen om Redis og Memcached i WordPress-hosting.

Forberedelse af sammenligning og godkendelser

For at sammenligne hostingudbydere skal du først have en et tilsvarende webstedsniveau. Opret en renset kopi med samme indhold, samme datamængde, samme tema og de samme plugins, herunder deres versioner. Fjern eller udskift personoplysninger og produktive adgangsoplysninger, så testversionen stadig afspejler det ønskede anvendelsestilfælde.

Brug så vidt muligt de samme PHP- og databaseversioner samt relevante indstillinger. Notér forskelle, der ikke kan fjernes, eller som er en del af den bestilte pakke. En sammenligning af de respektive standardpakker besvarer et andet spørgsmål end en sammenligning af stakke, der er tilpasset hinanden så meget som muligt: Resultatet kan ikke uden videre tilskrives serverydelsen alene.

Udarbejd en måleplan inden den første testkørsel. Den skal være så konkret, at en anden person kan forstå opsætningen og opdage afvigelser, hvis testen gentages. Den følgende tjekliste skelner mellem egenskaberne ved hosting-tilbuddet, hjemmesiden og målingen.

• Pris, ressourcebegrænsninger, serverplacering og softwareversioner for begge miljøer.
• Test-URL'er og sidetyper, loginstatus, cookies samt anvendte testkonti.
• CDN, sidecache og objektcache, herunder regler, opvarmningsfase og planlagt bypass.
• Målested, værktøjsversion, browser- og enhedsprofil, netværksforhold, tidspunkter og gentagelser.
• Belastningsprofil, ansvarsområder, aftalt testvindue og konkrete afbrydelsesgrænser.

Til belastningstests aftaler du Udgivelse med alle ansvarlige og eventuelt hostingudbyderen, inden du skaber belastning. Afklar kontaktpersoner, ressourcebegrænsninger og fremgangsmåden ved forstyrrelser. Udeluk eksterne tjenester uden deres samtykke; forhindr især reelle betalinger, bestillinger og meddelelser. Kontroller på forhånd, om testkopien rent faktisk forhindrer sådanne handlinger.

Målekoncept for typiske sider

Vælg værktøjet ud fra spørgsmålet, ikke ud fra den bedst mulige enkeltværdi. Et Målekoncept tildeler hver række en sidetype og en cache-tilstand. Tabellen viser, hvilke resultater der kan opnås med de respektive tilgange, og hvor deres gyldighed slutter.

I forbindelse med en offentlig blogartikel måler du den samme repræsentative URL flere gange ved hjælp af en fast browser- og netværksprofil. Notér, om CDN og sidecache er aktiveret, og hvordan siden blev »opvarmet« før målingerne. På den måde kan du vurdere indlæsningsoplevelsen for denne offentlige side, ikke nødvendigvis den for en indlogget session.

En dynamisk søgning eller kontooversigt tildeles sin egen måleserie med frigivne testdata og, hvis nødvendigt, en testkonto. Kontroller ikke kun statuskoden: Svaret skal stemme overens med søgeforespørgslen eller den pågældende konto og være opdateret. Kontroller desuden, om en planlagt Cache-bypass faktisk virker; en cookie i sig selv er ikke bevis nok.

Selv hvis responstiderne varierer, er årsagen dermed ikke nødvendigvis fundet. Applikationslogik, databaseadgang, en persistent objektcache og hostingmiljøet kan alle bidrage til resultatet. Dokumenter forskellene i strukturen og undersøg dem derefter målrettet, i stedet for at betragte en enkelt langsom forespørgsel som bevis på en bestemt flaskehals.

Gradvist opbygning af belastningstest

Start på en udtrykkeligt godkendt testside med nogle få enkelte opkald. Kontroller status og indhold, og sørg for, at der ikke opstår uønskede bivirkninger. Først derefter følger en separat aftalt belastningstest, f.eks. for godkendte produktvisninger i en webshop. Ægte bestillinger, betalinger og meddelelser er udelukket.

Planlæg en trinvis belastning med startniveau, varighed og stigninger. Aftal på forhånd målbare grænseværdier for afbrydelse i forbindelse med fejl, svartider eller andre tilgængelige driftsværdier samt en kontaktperson i tilfælde af afbrydelse. Hold dig til de udtrykkeligt tilladte forløb; en produktvisning giver ingen oplysninger om en ikke-testet checkout.

I den lukkede belastningsmodel afventer en virtuel brugerinstans afslutningen af sin aktuelle iteration, før den påbegynder den næste. Hvis applikationen bliver langsommere, kan den tilbudte belastning dermed falde. Modellen er velegnet til processer, hvor netop denne ventetid er en del af problemstillingen; den opretholder dog ikke en fast ankomstfrekvens.

En åben lastmodel planlægger derimod nye iterationer, uanset om de foregående er afsluttet. Til dette formål skal belastningsgeneratoren have tilstrækkelig kapacitet og tilgængelige virtuelle brugerinstanser. Hvis den ikke kan starte iterationerne, når testen ikke den planlagte profil; dokumenter derfor også disse iterationer, der ikke er startet.

Notér både den indstillede og den faktisk opnåede hastighed. Iterationer pr. sekund svarer kun til anmodninger pr. sekund, hvis hver iteration genererer nøjagtigt én anmodning. Registrer desuden fordelingen af svartider, fejl og timeouts samt kontrollen af korrekt indhold: En høj gennemstrømning med fejlbehæftede svar er ikke en vellykket belastningstest.

Gennemføre en gennemsigtig analyse af måleserier

En måleserie er kun meningsfuld, når den ses i sammenhæng med sit omfang. Notér derfor for hver testet side og hvert belastningstrin antallet af evaluerede forespørgsler samt antallet af fejl og timeouts. Skel mellem vellykkede svar og mislykkede svar, uden at udelade fejl fra rapporten: En lav svartid med mange fejl er ikke udtryk for en pålidelig og hurtig tjeneste.

Der Median beskriver middelværdien af de sorterede vellykkede målinger. Den 95. percentil, forkortet p95, angiver desuden en tærskel, under hvilken ca. 95 procent af disse måleværdier ligger. Ved få forespørgsler afhænger p95 i høj grad af enkelte observationer; angiv derfor altid stikprøvestørrelsen, og fortolk forskelle med forsigtighed.

Notér også belastningsmodellen og den faktisk opnåede hastighed for hvert kørsel. En konfigureret hastighed alene viser ikke, om generatoren har kunnet starte alle planlagte iterationer. Følgende skabelon forbliver tom indtil målingen; flere kørsler får hver deres egen log.

Gem rådata, testskript og konfiguration sammen med logfilen. På den måde kan man senere kontrollere, hvilke forespørgsler der indgik i en analyse, og om to serier overhovedet er sammenlignelige. Vælg ikke efterfølgende kun den hurtigste kørsel: Hvis resultaterne overlapper hinanden i høj grad, kan den observerede forskel ligge inden for svingningerne.

Ud over nøgletal skal du også angive afvigelser i indholdet, f.eks. en uventet login-side i stedet for den forventede kontooversigt. En teknisk vellykket status beviser ikke i sig selv, at den rigtige side blev leveret. Sådanne afvigelser skal beskrives separat i fejlbeskrivelsen og kan gøre en måleserie ubrugelig i forbindelse med den planlagte beslutning.

Indsnævre årsagerne og foretage en ny måling

Start fejlsøgningen med det leverede svar: Stemmer indholdet, loginstatus og den testede URL overens? Kontroller derefter den dokumenterede Cache-tilstand og målemiljøet. Forskellige cookies, et andet målepunkt eller en ændret CDN-regel kan medføre, at to kørsler ikke er ens, selvom ydeevnen i selve applikationsstakken ikke har ændret sig.

Først derefter kan de tilgængelige driftsdata hjælpe med at indsnævre problemet: Ressourceudnyttelse og køer kan tyde på flaskehalse, mens oplysninger om applikationer eller databaser kan tyde på ressourcekrævende databehandling. En enkelt langsom HTTP-værdi angiver ikke årsagen. WordPress nævner ud over hosting også software, konfiguration og indhold som faktorer, der har indflydelse.

For at kunne foretage en før-efter-sammenligning skal du bevidst kun ændre én indstilling, f.eks. implementeringen af en persistent objektcache. Webstedets tilstand, testside, belastningsprofil og måleplacering skal så vidt muligt forblive uændrede; dokumenter også den respektive cache-opvarmning. WordPress-objektcachen er uden en passende persistent implementering begrænset til den enkelte anmodning, hvorfor dens faktiske integration skal kontrolleres.

Udfør flere testkørsler før og efter ændringen, og fordel dem over tid. På den måde kan du bedre se, om en forskel optræder gentagne gange, eller om den kan skyldes normale udsving. Sammenlign ikke kun medianen og p95, men også fejl, svarindhold og opnået succesrate; ellers kan en tilsyneladende acceleration skyldes ændrede testbetingelser.

Selv en omhyggelig sammenligning tager ikke højde for alle påvirkningsfaktorer. Ved shared hosting kan andre brugere og infrastruktur, som man ikke har indsigt i, være med til at påvirke resultatet. Hvis du mangler data om ressourcer eller køer, skal du udtrykkeligt notere dette hul og formulere en formodet årsag som en hypotese i stedet for som et påvist resultat.

At vurdere hostingresultatet korrekt

Basér din beslutning om hosting på de sider og processer, der er vigtige for din hjemmeside. Et offentligt blogindlæg med en varm sidecache kan skabe en anden belastning end visningen af en konto, hvor brugeren er logget ind. Gode cache-hits på offentlige sider er derfor hverken tegn på hurtige, personaliserede svar eller en robust betalingsproces.

Før sammenligningen skal du definere, hvilke responstider, fejlprocenter og hvilket belastningsprofil der er acceptable for den pågældende proces. Kontroller derefter, om de dokumenterede måleserier opfylder disse krav under de aftalte betingelser. Dette omfatter også korrekt indhold og en stabil afvikling; en høj forespørgselsfrekvens er i sig selv ikke et tilstrækkeligt grundlag for en beslutning.

Sæt virtuelle brugere kan ikke sidestilles med reelle besøgende, der er til stede på samme tid. Deres adfærd følger af testskriptet og belastningsmodellen: I den lukkede model venter en instans på, at dens iteration er afsluttet, før den påbegynder den næste. Uden en passende adfærdsmodel kan man derfor ikke udlede et reelt besøgstal ud fra antallet af disse instanser.

Rapporter resultatet sammen med takst, webstedets status, de testede URL’er, cache- og CDN-regler, måleplacering samt tidsperiode. Angiv desuden, om du har sammenlignet så ensartede stakke som muligt eller de respektive tilbudte samlede pakker. I en pakkesammenligning kan konfigurationsforskelle påvirke resultatet; den isolerer ikke automatisk den rene serverydelse.

Hvis rækkerne overlapper hinanden i høj grad, eller hvis omgivelserne ikke kan kontrolleres tilstrækkeligt, er „der er ikke påvist nogen pålidelig forskel“ en mulig og nyttig konklusion. Det betyder ikke, at begge løsninger er lige hurtige under alle forhold. Det betyder blot, at den foreliggende test ikke kan påvise den ønskede forskel.

Til driftskontrol skal du gemme måleprofilen og gentage udvalgte browser- og belastningsmålinger efter større ændringer eller med aftalte intervaller. Sammenlign kun nye resultater med relevante tidligere dataserier, og dokumenter ændringer i indhold, versioner og cache-regler. Belastningstests kræver fortsat et godkendt tidsvindue og aftalte afbrydelsesgrænser.