Värdet av benchmarkingtester – så presterade Python och WebSocket i laddningssystem för elbilar
Optimal applikationsprestanda är en viktig aspekt i det dagliga arbetet för Etteplans utvecklare. Ibland kan perfektion bli en verklig utforskning av programmeringsspråk, bibliotek, kommunikationer och protokoll. Ett exempel på detta inträffade för lösningsarkitekten Ville Kärkkäinen och hans team, som utvecklar en lösning för laddningsstationer för elbilar.
”I vårt kunduppdrag har vi ett Open Charge Point Protocol (OCPP) system där det centrala systemet och laddningsstationerna kommunicerar med varandra via WebSocket”, säger Kärkkäinen, som är AWS- och Python-specialist.
WebSocket är ett protokoll som möjliggör en dubbelriktad och prisvärd kommunikationskanal mellan klient och server. Det används i olika lösningar där permanent regelbunden eller oregelbunden kommunikation är nödvändig och där backendsystem behöver skicka data till kunder utan att vänta på kundförfrågningar. Detta kan jämföras med http-protokollet, som är bekant för alla som använder en webbläsare och alltid kräver en kundförfrågan.
I OCPP-systemet använder vi Python-språk både i vårt molnbaserade system som körs i AWS och i vårt inbyggda system”, förklarar Kärkkäinen. ”Python är snabb i utvecklingen, men inte nödvändigtvis att använda. Tack vare dess rena kodsyntax, snabba applikationsutveckling och rika ekosystem av bibliotek och utvecklare är Python otroligt populärt och omtyckt”, säger Kärkkäinen.
Hur väl presterar Python i ett benchmarkingtest med WebSocket?
Ville Kärkkäinen ville ta reda på hur bra Python verkligen presterar genom att göra ett benchmarkingtest med WebSocket. Det kan ge en ny inblick i hur optimal kommunikationen i laddningsstationerna för elbilar och i det centrala systemet kommer att bli.
”Jag jämförde några Python WebSocket-bibliotek med utvalda Node.js-, Java- och Rust-bibliotek som en del av ett större stresstestarbete. Dessutom var jag intresserad av att se om ASGI-servern med WebSocket-biblioteket skulle vara ett bra alternativ för att möjliggöra skalning av arbetsbelastning både lokalt och i molnmiljön”, berättar Kärkkäinen.
Han påpekar att det är ganska svårt att avgöra hur mycket benchmarktestet testade prestandan för den aktuella WebSocket-servern och hur mycket som beror på det aktuella språkets funktioner.
”Det är definitivt orättvist att jämföra sammanställda och tolkade språk vad beträffar ren exekveringshastighet. Detsamma gäller när man jämför servrar som kör flera processer med den som utför allt arbete inom samma tråd. Men sånt är livet. Konkurrensen är sällan rättvis och inom givna ramar är det bara resultaten som räknas”, förklarar Ville Kärkkäinen.
Benchmarkingtester är lärorika
Kärkkäinen påpekar att värdet av att jämföra en enskild teknik, som WebSocket-bibliotek, inte bara ligger i det konkreta slutresultatet med fina mätvärden och grafer. Det ger också en bättre förståelse för grova tröskelvärden avseende hur långt man kan driva en komponent. Baserat på denna insikt bör en utvecklare försöka anpassa arkitekturen och säkerställa att dessa trösklar inte överskrids.
”Men benchmarkingtester är också en intressant och lärorik upplevelse. Det som mäts kan uppföra sig oväntat och tvärtemot ens förväntningar när det utsätts för stress, vilket får en att ställa meningsfulla frågor. Kan jag lita på den här tekniken? Ska jag förbereda mig på att optimera, och i så fall var och hur? Eller är resultatet så dåligt att det är dags att leta efter andra alternativ? Och gissa hur man hittar de andra alternativen? Precis, genom benchmarkingtest!” säger Kärkkäinen.
Så hur gick hans benchmarkingtest och vilka slutsatser drog han? Eftersom han är ett stort fan av Python var han mycket glad över att få veta att Python med uWebSocket-bibliotek var snabbast.
”Det var i genomsnitt 67 % snabbare än WebSocket-bibliotek, som vi för närvarande använder i vårt OCPP-system. WebSocket-biblioteket uppvisade dock tillförlitlig prestanda och med tanke på AWS-arkitekturen där vi kör vårt OCPP-system väckte resultaten inte någon omedelbar oro. Även om snabbhet är viktigt är det fortfarande bara en aspekt av kvalitet”, understryker Kärkkäinen.
När det gäller systemet med laddningsstationer för elbilar är WebSocket-bibliotekets prestanda viktig. Trots detta är det av flera skäl inte den första och mest troliga flaskhalsen. Först reagerar det centrala OCPP-systemet på meddelanden som skickas från laddningsstationen. Därefter utför det viss affärslogik i backendsystemet, vilket vanligtvis involverar databasåtkomst eller åtkomst till andra AWS-tjänster, och svarar sedan klienten.
”Denna meddelandeprocess sker relativt sällan och transaktionsnoggrannhet är mycket viktigare än svarstiden. Vi använder AWS-infrastruktur både för att säkerställa att vårt system är tillgängligt och att det kan skalas upp och ner baserat på den faktiska belastningen”, avslutar Ville Kärkkäinen.