Belastningstestning för tjänstgörande slutpunkter

Den här artikeln vägleder dig genom den viktiga processen för belastningstestning av dina Mosaic AI Model Serving-slutpunkter för att säkerställa att de kan hantera produktionsarbetsbelastningar effektivt. Den innehåller också praktiska exempel, verkliga analogier och stegvisa instruktioner med hjälp av locust-belastningstestningsramverket, för att visa hur du mäter viktiga prestandamått som begäranden per sekund och samtidighetsgränser, så att du kan storleksanpassa dina slutpunkter korrekt och säkert distribuera modeller för dina affärsbehov.

Vad är ett belastningstest?

Ett belastningstest är ett test som simulerar verklig användning av Mosaic AI-modell som betjänar slutpunkter som säkerställer att de uppfyller dina produktionsbehov, till exempel svarstid eller begäranden per sekund. Ett belastningstest mäter slutpunktens prestanda under olika trafiknivåer, vilket hjälper dig att storleksanpassa slutpunkten korrekt för att inte orsaka fördröjningar.

Föreställ dig detta: Klockan är 08:00 på en vardag, och ett populärt kafé i hjärtat av staden har just öppnat. Doften av färskt kaffe fyller luften. Baristan är förberedd, maskinerna är uppvärmda och raden av koffeinutsvultna kunder bildas redan.

Till en början går det smidigt. Ett par kunder kliver fram, lägger sina beställningar och baristan börjar förbereda sina drycker. Vissa drycker tar 30 sekunder, andra tar en minut - beroende på komplexiteten. Barista jonglerar flera beställningar med övad effektivitet.

Men snart kommer fler människor. Fem kunder förvandlas till tio, sedan tjugo. Var och en gör en beställning, väntar på sin drink och kanske chattar lite vid disken. Baristan är nu pressad. Även när en andra barista hoppar in börjar systemet bli ansträngt — linjen växer, beställningar staplas upp och kunderna börjar vänta längre.

Föreställ dig nu att du försöker mäta hur många drycker kaféet kan servera per minut innan kunderna börjar lämna frustrerade. Det är belastningstestning.

I den här analogi:

• Varje kund är en klient som skickar en begäran.
• Barista/baristor representerar servern som bearbetar modellinferenser en efter en eller parallellt.
• Tiden för att ta en beställning och servera drycken är modellimplementeringstiden .
• Fördröjningar i samtal, betalning eller att hitta beställningen är dina nätverkskostnader.
• Fler kunder som anländer samtidigt är klientkonkurrens.
• Att lägga till fler baristor eller fler datorer är som att öka serverns samtidighet.

Som i alla bra caféer finns det en gräns för hur mycket personalen kan hantera på en gång. Om du inte planerar i förväg - säg genom att ta in fler baristas under rusningstid - blir folk missnöjda. Samma sak gäller för dina system under belastning. Belastningstestning hjälper dig att identifiera var flaskhalsarna finns, hur mycket trafik systemet kan hantera och vilka ändringar du behöver göra för en smidigare tjänst.

Innan du kör ett belastningstest på slutpunkten måste du:

• Förstå komponenter och begrepp som rör belastningstestning.
• Bestäm och definiera dina produktionskrav.
• Hitta en representativ nyttolast för det belastningstestningsramverk som ska användas vid benchmarking av slutpunkten.

Begrepp och definitioner för belastningstestning

I följande tabell definieras belastningstestningsrelaterade begrepp:

Krav på svarstid

Baserat på dina affärs- och kundkrav definierar du systemets ideala prestanda. På en modell som betjänar slutpunkten inkluderar svarstiden den tur och retur-tid som en klient upplever när data skickas för slutsatsdragning. Detta omfattar svarstid för nätverk samt inferenstid. Det är viktigt att se till att dina krav är realistiska. Om din modell till exempel tar 15 ms för att utföra slutsatsdragning när den läses in i minnet måste du ge ytterligare tid för nätverksfördröjning när den hanteras på en modell som betjänar slutpunkten.

Hur relaterar RPS, svarstid och samtidighet?

Ett företag har vissa definierade kriterier för att deras system ska lyckas. För ML-system är affärskriterier i allmänhet högkvalitativa resultat, låg svarstid och högt dataflöde. Resultatkvaliteten är specifikt relaterad till själva modellen, medan svarstid från slutpunkt till slutpunkt och dataflöde är egenskaper hos serveringssystemet. Fördröjningen från slutpunkt till slutpunkt består av modellens körningstid och nätverksöverförbelastning. Dataflöde (eller begäranden eller frågor per sekund) är omvänt relaterat till svarstid och är direkt relaterat till samtidighet.

• Ju mer samtidighet desto högre dataflöde.
• Ju högre svarstid, desto lägre genomströmning.

I allmänhet finns det ett optimalt förhållande mellan samtidighet på klientsidan och samtidighet på serversidan för ett visst program. Till exempel "hur många hamburgare kan en linjekock arbeta med samtidigt". Eftersom det kan finnas många delade steg i tillagningsprocessen kan linjekocken kanske mer optimalt laga fyra hamburgare samtidigt snarare än att bara laga mat en i taget. Det finns en gräns för denna parallellisering, vid en viss punkt tillför utförandet av många parallella handlingar för mycket latens, som när kocken behöver lägga till ost till 1000 hamburgare.

Ett av de centrala målen med ett belastningstest är att fastställa det optimala förhållandet för ditt program. Det optimala förhållandet maximerar RPS, uppfyller dina svarstidskrav och undviker köer. Det här förhållandet kan användas för att korrekt storleksanpassa slutpunkten för att uppfylla dina mest krävande belastningar.

Om slutpunkten inte kan bearbeta begäranden tillräckligt snabbt börjar en rad att bildas. Detta kallas för en kö. Att skapa en kö resulterar vanligtvis i mycket längre svarstid från slutpunkt till slutpunkt eftersom det nu finns ytterligare tid då varje begäran väntar innan den bearbetas. Om begäranden fortsätter att tas emot snabbare än vad begäranden kan bearbetas växer kön, vilket ytterligare ökar svarstiden. Därför är det viktigt att förstå vilken typ av toppbehov slutpunkten kan uppleva och se till att den har rätt storlek med ett belastningstest.

Exempel på belastningstestscenario

Vid belastningstestning, samt verkliga system, är relationen mellan klientkonkurrency, serverkonkurrency och svarstid dynamisk och beroende av varandra. Låt oss se den här relationen med ett enkelt exempel:

Scenario 1: Enkel konfiguration

I den här konfigurationen skickar en enda klient begäranden sekventiellt – den väntar på ett svar innan nästa begäran utfärdas. Eftersom den totala tiden per begäran är summan av modellkörningen och överliggande latens (40 ms + 10 ms) är den uppmätta totala svarstiden 50 ms.

• Antal klienter: 1
• Provisionerad samtidighet: 1
• Overhead-svarstid: 10 ms
• Modellkörningstid 40 ms

Därför slutför klienten en begäran var 50:e ms, vilket motsvarar 20 begäranden per sekund eller frågor per sekund.

Scenario 2: Öka provisionerad samtidighet

I det här fallet har du dubbla den etablerade samtidigheten och en enda klient som gör begäranden sekventiellt. Det innebär att den totala svarstiden fortfarande är 50 ms (40 ms + 10 ms) och att systemet bara ser 20 begäranden per sekund (QPS).

• Antal klienter: 1
• Etablerad samtidighet: 1–> 2
• Overhead-svarstid: 10 ms
• Modellkörningstid 40 ms

Scenario 3: Lägg till en annan klient i systemet.

Nu har du två klienter som skickar begäranden till en slutpunkt med två etablerade samtidigheter. I det här fallet kan varje klients begäran bearbetas separat av slutpunkten samtidigt (förutsatt perfekt belastningsutjämning). Så även om den totala svarstiden fortfarande är 50 ms (40 ms + 10 ms), observerar systemet 40 begäranden per sekund, eftersom varje klient skickar 20 qps.

• Antal klienter: 1–> 2
• Förkonfigurerad samtidighet: 2
• Overhead-svarstid: 10 ms
• Modellkörningstid 40 ms

Om du ökar den tilldelade samtidigheten och antalet klienter som gör begäranden ökar det totala QPS som observeras i systemet, utan att påverka svarstiden.

Scenario 4: Låt oss minska den tilldelade samtidigheten

I det här sista scenariot är antalet klienter större än den etablerade samtidigheten. Den här konfigurationen introducerar en annan variabel, köer, i systemet och dess effekt på QPS och svarstid.

• Antal klienter: 2
• Etablerad samtidighet: 2–> 1
• Overhead-svarstid: 10 ms
• Modellkörningstid: 40 ms

Här har du två klienter som gör begäranden samtidigt. Slutpunkten kan dock bara bearbeta en enskild begäran i taget. Detta tvingar den andra begäran att vänta innan den första begäran har bearbetats. Att vänta, eller mer korrekt, köhantering av den andra begäran kan försämra svarstiden i systemet. Förutsatt att servern tillåter köer (aktiverad som standard i Databricks Model Serving) ser den andra klienten en svarstid på 90 ms: 10 ms (nätverkskostnader) + 40 ms (köväntetid) + 40 ms (modellkörningstid). Detta är betydligt värre än de 50 ms som setts tidigare.