SPEC släpper testsvit för JMS

08 November 2007 // Niklas Gustavsson

Prestandamätning är ett minerat område. Eftersom många testramverk riktar in sig mot vissa delar i det system det ska mäta ger det leverantören en möjlighet att optimera för testet. Förutom att kunna optimera de kodvägar som används av testet så är det också vanligt förekommande att offra best practices för design och utveckling för att klämma ut den sista prestandan. Och eftersom leverantören som gör testerna känner till hur man bäst optimerar sitt eget system, men kanske inte sina konkurrenters, så blir det ofta en diskussion om hur tuningen har gått till.

Om man sen ovanpå detta lägger att resultaten av denna typ av testning ofta publiseras via marknadsavdelningarnas pressreleaser så är det inte att undra på att jämförande prestandatestning ses som hart när omöjligt att genomföra.

Organisationen SPEC är känd för att ha de bästa testsviterna för prestandamätning inom flera områden. Där vi känner dem bäst är för deras mångåriga historia av att testa Java EE applikationsservrar.

SPECJ löser till stor del ovanstående problem genom en rad principer. SPECJ är själva leverantörsneutrala och står fast vid sina Fair Use Rules vilket gör dem till en trovärdig röst.

Deras testsviter mycket omfattande vilket leder till att de optimeringar som oundvikligen görs för testerna även får stora positiva effekter på prestandan för verkliga applikationer. Man tillåter inte heller den som kör testet att modifiera testsviten (mer än delar som krävs för kunna köra testet på systemet, sk Provider Modules) vilket minimerar propäritära optimeringar.

Dessutom tar man bort ansvaret för att jämföra testresultaten från leverantörerna. Istället får den som genomfört ett test (leverantören eller tredje part) skicka in sitt resultat till SPEC som sedan låter en kommitté granska resultaten innan de publiseras. Ideen är sådeles att leverantören själv tunar och testar sitt system och vi och oberoende analytiker själva kan göra jämförelser.

Viktigt att komma ihåg är att inte extrapolera resultaten av benchmarks till din egen applikation. Att en leverantör klarar ett visst antal transaktioner per sekund innebär inte att du kommer uppnå det samma. Dels för att du troligen inte har tid och pengar att i så stor detalj optimera prestandan hos applikationen och runtime, dels för att din affärslogik eller utvecklingskonventioner ställer krav som innebär avkall på prestandan.

Som rubriken antyder har SPEC nyligen släppt en ny testsvit för prestandatestning av Java Message Service, JMS. Detta innebär en kraftig utökning av de JMS relterade tester som redan finns med i SPECjAppServer2004.

Testramverket är indelat i två huvudsaktliga delar, vertikala och horisontella topologier. Dessa skilljer sig genom att man i de horisontella testerna skalar upp genom att öka antalet destinationer (köer och topics), potentiellt genom att öka antalet noder. I det vertikala testerna mäter man istället hur man kan skala trafiken genom en enda destination.

Testerna körs genom en controller och ett antal agenter, detta för att kunna erbjuda tillräcklig last för att pressa JMS servern.

Notera att testsviten endast riktar sig mot JMS. Meddelande-orienterade system behöver ofta fungera på många plattformar och för många språk, tex för integration mot legacysystem. Resultaten kommer alltså inte säga något om de övergripande prestandabilden om dina målplattform är mer än Java.

Det finns ännu inte några resultat publiserade, men en gissning är att vi kan förvänta oss de första under början av nästa år. Med tanke på att flertalet av de stora leverantörerna har deltagit i utvecklandet av sviten så kan vi förvänta oss omfattande rapportering av resultat.

Vad innebär då detta för oss som utvecklare och kunder av JMS system? För det första innebär det att vi för första gången kan göra oberoende jämförelsen av prestandan hos JMS providers. För en meddelandeintensiv applikation kan detta göra avsevärd skillnad. Speciellt gäller detta Enterprise Service Bus implementationer där en meddelandehanterare ofta tjänar som en viktig transport.

Som en följd av detta kan man anta att det på samma sätt som för applikationsservrar kommer ske vidare prestandaoptimering av JMS implementationerna. Även om de flesta implementationer redan idag uppnår mycket hög prestanda så finns här en hel del jobb kvar att göra.

Detta innebär också en hjälp att veta hur man bäst ska designa en lösning för maximal prestanda och skalbarhet. Om vi jämför med SPECjAppServer2004 så har det tex lärt oss mycket kring JVM optimering för höga transaktionslaster (ffa kring garbage collection och trådhantering). För JMS är detta ännu en vit fläck på kartan där mycket få har en djup kunskap. Genom att studera hur leverantörerna valt att konfigurering sina system för testningen kan vi lära oss mycket.