Skalbarhet i webbsystem M I K A E L E R I K S S O N

Skalbarhet i webbsystem M I K A E L E R I K S S O N Examensarbete Stockholm, Sverige 2008

Skalbarhet i webbsystem M I K A E L E R I K S S O N Examensarbete i datalogi om 30 högskolepoäng vid Programmet för datateknik Kungliga Tekniska Högskolan år 2008 Handledare på CSC var Serafim Dahl Examinator var Karl Meinke TRITA-CSC-E 2008:029 ISRN-KTH/CSC/E--08/029--SE ISSN-1653-5715 Kungliga tekniska högskolan Skolan för datavetenskap och kommunikation KTH CSC 100 44 Stockholm URL: www.csc.kth.se

Skalbarhet i webbsystem Sammanfattning Denna rapport beskriver ett tillvägagångssätt för att göra ett system skalbart. För att ett system skall kunna hantera stora mängder trafik måste det vara skalbart. Ett viktigt redskap för att lyckas är att ta fram en testplan och att hela tiden göra återkommande belastningstester under hela utvecklingen. Resultatet från testerna ger en bra inblick i var eventuella brister och flaskhalsar finns i systemet. Under arbetets gång visade det sig att testerna var värdefulla och nödvändiga för att kunna hitta vissa problem som annars inte kunnat upptäckas i förtid. Rapporten beskriver också det publika gränssnittet som systemet bygger på samt ett antal olika kommunikationsparadigm som kan bli aktuella i framtiden. De kommer att bli aktuella när integration med andra system blir aktuellt och om funktionalitet bryts ur till separata moduler. Developing scalable web applications Abstract This report describes a process for making a web system scalable. To be able to handle large amounts of requests it is a must that the system is scalable. A tool for succeeding is to develop a test plan to follow during the development of the system. Load testing is an ongoing process that should be a part of the whole development cycle. The results will give an indication where bottlenecks can be located. During this thesis the tests proved to be very useful for detecting problems that could not have been spotted otherwise. The report will also describe the public interface that the system is using for communication with content providers. It also covers a number of communication techniques that might become actuality later on when communicating with other systems is going to be an issue or if functionality is extracted to separate modules.

Innehållsförteckning 1. Introduktion... 1 1.1 Bakgrund... 1 1.2 Problemdefinition... 2 1.2.1 Kommunikation... 2 1.2.2 Prestandamätningar... 2 1.2.3 Skalbar modell... 3 1.3 Metod... 3 1.4 Förkortningar... 4 1.5 Avgränsning... 4 2. Tekniker... 5 2.1 Klient/Server... 5 2.1.1 Web-Tier-arkitektur... 5 2.1.2 J2EE... 7 2.2 Applikationsservrar... 8 2.3 Servlets... 9 2.4 Servletcontainers... 10 2.5 Distribuerade teknologier... 10 2.5.1 TCP/IP Sockets... 11 2.5.2 Remote Method Invocation (RMI)... 11 2.5.3 CORBA... 12 2.5.4 XML-RPC... 12 2.5.6 Webbservices... 12 3. Prestanda... 15 3.1 Testplan... 17 3.2 Belastningstest... 18 3.3 Skalbarhet... 24 3.3.1 Systemarkitektur... 24 3.3.2 Analysverktyg... 26 3.3.3 Klustring av applikationsservrar... 27 3.3.4 Lastbalansering... 28 4. Genomförande... 29 4.1 Kommunikation... 29 4.1.1 Extern kommunikation... 29

4.1.2 Intern kommunikation... 33 4.2 Testning... 34 4.2.1 Testplan... 34 4.2.2 Belastningstestet...37 4.3 Skalning av systemet... 39 5. Resultat och Slutsatser... 40 5.1 Kommunikation... 40 5.2 Testning... 41 5.3 Skalbarhet... 42 5.4 Framtiden... 45 Referenser... 46 Bilagor... 48 A. Transaktionsmöntret... 48 B. SquaceML... 49 C. JProfiler dump av minnesallokeringen... 50 D. JProfiler Call tree för CPU-användning... 51

1. Introduktion I detta kapitel beskrivs bakgrunden och problemet till detta examensarbete, samt de metoder som jag har använt för att lösa problemen. Här beskrivs också de avgränsningar som fanns. 1.1 Bakgrund Användandet av mobilt Internet är på stor framåtmarsch i Sverige. Tidigare har det varit problem med hastigheterna och storleken på skärmarna, men nu är dessa inte längre något problem. Detta gör att det finns en stor efterfrågan på nya program och tjänster för mobila handenheter. Dagens nya telefoner har nästan alla stöd för att komma åt Internet och många har dessutom stöd för Java. Att surfa via mobilen till webbsidor som inte är anpassade för mobiltelefoner blir dock ofta långsamt även om hastigheterna har blivit högre, det beror främst på att alla bilder är i full storlek. Många företag har numera anpassat en sida just för mobiltelefoner för att underlätta för det mobila surfandet. Det finns också webbläsare som skalar ner bilder på vanliga sidor som inte är anpassade för mobiltelefonen. Företaget som initierat detta examensarbete heter Squace och håller på att utveckla en mobil applikation som skall underlätta för mobilt surfande. Det unika med produkten är applikationens gränssnitt, vilket gör det möjligt att visa mycket information på mobilen även om skärmarna är små. För att minimerar skrivandet på mobilen finns det en webbsida där det är enkelt att administrera sitt innehåll. När idén uppkom utvecklades en prototyp med det nya gränssnittet. Där kunde tester köras för att se hur användare upplevde det nya sättet att navigera. Testerna gjordes mellan det nya gränssnittet och den vanliga inbyggda webbläsaren i mobilen. Resultaten från testerna var positiva, användarna förstod idén med gränssnittet direkt och såg de fördelar som fanns jämfört med den vanliga webbläsaren. Med hjälp av erfarenheterna från utvecklingen av den gamla prototypen startade nu utvecklingen av ett komplett system. Men för att mobilklienten skulle fungera måste också ett backendsystem byggas och ett webbgränssnitt för administrationen av innehållet i mobilklienten. Det som krävs för att köra applikationen är en mobiltelefon av senare modell som har stöd för Java. Mobilklienten kommunicerar med backendsystemet via vanlig Hypertext Transfer Protocol (HTTP) och det är inget krav med 3G även om det rekommenderas för att få högre hastighet. Backendsystemet liksom mobilapplikationen är utvecklade i Java som idag är ett modernt alternativ för Internetutveckling. 1

1.2 Problemdefinition Innan systemet kan gå live är det vikigt att en studie görs av de inblandade tekniker som kan bli aktuella. Det är av högsta vikt att systemdesignen klarar av att skalas upp när systemet i framtiden måste expanderas. Det som kommer att ingå i detta examensarbete kommer att vara följande: En genomgång av de kommunikationsgränssnitt som kan bli aktuella för extern kommunikation, samt definiera det publika protokoll som är systemets gränssnitt. Utveckla ett test-ramverk för att kunna genomföra belastningstester på systemet. Ta fram en skalbar modell för systemet 1.2.1 Kommunikation Systemet kommer att bestå av ett flertal moduler som måste kunna kommunicera med varandra på ett kontrollerat och effektivt sätt. För att kunna växa i framtiden måste delar av funktionaliteten kunna separeras och flyttas över till andra resursservrar i nätverket. En server kommer inte att klara av att ta hand om alla förfrågningar om de blir för många, sen är det inte effektivt om all funktionalitet finns duplicerad på alla servrar. Den information som visas i mobilen kommer att hämtas direkt från informationsleverantörerna via ett fördefinierat protokoll. Idag finns det endast stöd för att kommunicera via http men i en framtida kan det bli aktuellt att köra andra protokoll. Beroende på vilken typ protokoll som klienten ansluter sig med kommer det att finnas en motsvarande inkopplingsmodul som tar hand om förfrågningen. När en förfrågan kommer in till systemet kan det antingen var till en intern eller extern länk. De interna länkarna tas omhand av systemet och returnerar exempelvis användardata eller skapar olika typer av events. De externa länkarna kan peka på några olika typer av innehåll. Den kan antingen vara en Rich Site Summary (RSS) eller någon av de andra Mime-typerna som stöds av systemet. Internt mellan modulerna kan det bli frågan om något annan typ av gränssnitt för att kommunicera. 1.2.2 Prestandamätningar Vid design av ett system är det viktigt att redan från början ha med prestandaaspekterna, för ju längre tiden går desto mer tidsödande blir det att ta hand om problemen. Om antalet transaktioner ökar kontinuerligt kommer prestandan till slut att bli ett problem, vilket är fullt 2

naturligt. Alla servrar har en maximal gräns för hur många samtidiga förfrågningar de klarar av att betjäna. När ett nytt system körs igång kan det vara svårt att veta var flaskhalsarna kommer att finnas, därför är det ytterst viktigt att systematiska tester görs på systemet innan problemen uppstår. Det finns i huvudsak två stora delar att göra mätningar på i systemet, den ena är mobilapplikationens förfrågningar och den andra är webbapplikationen. Eftersom systemet i första hand inriktar sig på mobilklienterna kommer testningen att göras på den mobila delen av systemet. 1.2.3 Skalbar modell För att systemet ska kunna expanderas i framtiden är det viktigt att systemdesignen stödjer det. Det kommer att bli nödvändigt att tillföra ny hårdvara när systemet skall klara av att betjäna tusentals samtidiga användare. 1.3 Metod Eftersom utvecklingen skedde i Java undersökte jag därför vilka möjligheter som fanns för att bygga skalbara lösningar i Java. Idag finns det många intressanta öppna källkodsprogram produkter att använda sig av vid utveckling av Javaapplikationer. När systemet växer kommer delar av systemet att behöva brytas ut från huvudsystemet och kanske måste en integration mot de andra systemen till för att få utökad funktionalitet. I framtiden kommer troligen kommunikation med ekonomisystem och reklamsystem att behöva etableras. Detta gjorde att jag undersökte vilka olika teknologier som fanns för att kommunicera mellan olika system. Även om detta system är skrivet i Java är det inte säkert att de andra systemen är det, därför var det viktigt att se över vilka olika tekniker som kunde bli aktuella. När det gällde systemets prestanda studerade jag litteratur som fanns skriven inom ämnet för att sedan ta fram en testplan som kunde användas för att försöka nå de uppsatta målen med testerna. För att kunna belasta systemet behövde jag hitta någon produkt eller metod för att simulera last. Genom att belasta systemet med tusentals förfrågningar skulle jag förhoppningsvis att kunna upptäcka var falskhalsarna uppkom. Till slut nås en nivå där det inte längre går att effektivisera applikationen mer, då är gränsen nådd för vilken genomströmning som systemet klarar av att leverera med befintlig hårdvara. För att öka kapaciteten måste systemet byggas ut med mer hårdvara. Ett förslag på hur en skalbar lösning kan se ut kommer också att tas fram vilken kommer att bero på var systemet behöver mera resurser. Här går gränsen för detta examensarbete men tanken är att testverktyget skall kunna användas för att göra ytterligare tester när nya maskiner adderas till systemet. 3

1.4 Förkortningar AJAX GPRS XML ebxml HSDPA WLAN IDL WAP EJB RFC MIDP HTML MIME RSS XSLT SOA SLA Aynchronous Javascript And XML General Package Radio Service Extensible Markup Language Electronic business using extensible Markup Language High-Speed Downlink Package Access Wireless Local Area Network Interface Description Language Wireless Application Protocol Enterprise Java Beans Request For Comments Mobile Information Device Profile HyperText Markup Language Multipurpose Internet Mail Extensions Rich Site Summary Extensible Stylesheet Language Transformation Service Oriented Architecture Service Level Agreement 1.5 Avgränsning För detta examensarbete hade jag endast tillgång till en maskin att köra testerna på vilket gjorde att jag inte kunde testa hur systemet skulle ha skalat. Belastningstesterna innefattade bara serversystemet som hanterade anropen från mobiltelefonen. Webbsystemet var inte med i testerna. Databasen testades inte. 4

2. Tekniker I detta kapitel ges en beskrivning av olika tekniker och arkitekturer som har varit till grund för detta examensarbete. 2.1 Klient/Server Med Klient/Server arkitektur menas att det existerar en relation mellan två datorer som interagerar med varandra där den ena datorn agerar server. Normalt skickar klienter en förfrågan till servern som sedan genererar ett svar tillbaka till klienten. Detta är idag en vanlig arkitektur när det gäller webbsystem. [5] 2.1.1 Web-Tier-arkitektur Web-tier-arkitekturen är ett ramverk baserat på det populära designmönstret Model-View- Controller (MVC). MVC designmönstret delar upp applikationen i tre olika skikt: Modellen eller domänen är skiktet för all logik och beräkningar. Vyn är presentationen av applikationen, i webbapplikationer är det normalt en HTML sida. Controller skiktet tar hand om alla events från användare och system. Den här modellen ger ett antal design fördelar. Den största fördelen är den centraliserade kontrollen, den gör att applikationen blir lätt att ändra och den minskar kodupprepning. I figur 2.1 visas hur en förfrågan behandlas i ett system som är designat enligt web-tierarkitekturen. Figur 2.1, Behandling av en förfrågan med Web-tier 5

Det finns två olika modeller att använda av MVC design mönstret, modell 1 och modell 2. Modell 1 är mest lämpad att använda för utveckling av statiska webbapplikationer som kommer att ändras sällan, har ett enkelt flöde och har ett litet behov av centraliserad säkerhetskontroll och loggning. Modell 2 är den mest använda modellen. Den har en controller mellan webbläsaren och JSPsidan eller servletcontainern. Controllern hanterar logiken för vilka sidor som skall visas och vidarebefordringen av förfrågningar till andra sidor. Denna modell är också lättare att bygga vidare på och underhålla, för sidorna refererar inte varandra direkt. Modellen har också en central punkt för säkerhet och loggning. För att kunna betjäna flera olika typer av klienter behöver varje klient sin egen typ av controller för att behandla dess förfrågan på rätt sätt, men de kan alla använda samma applikationsmodell. Varje controller pratar sin egen dialekt med sin specifika klient men internt pratar alla samma protokoll. Denna design gör det enkelt att lägga in stöd för ytterligare klienter i framtiden. De controllers som tar hand om förfrågningarna kan vara servlets, men kan även vara av någon annan typ av klient. En styrka med servlets är att de stödjer flera protokoll än HTTP, vilket öppnar en möjlighet att ansluta andra typer av klienter än webb. Figur 2.2, Stöd för multipla klienter med hjälp av multipla controllers och en protokollrouter. Genom att sätta en protokollrouter mellan front-controllers och klienterna kan säkerheten tas om hand om på ett enda ställe, se figur 2.2. Vyn i Web-tier är normalt en JSP sida eller en servlet, tillsammans med en mer statisk resurs i form av en HTML-sida och grafik. Eftersom webbläsare är tunna klienter tar Web-tier hand om layouten för den dynamiska informationen innan den sänds över till klienten. Web-tierkomponenter är inte bundna till enbart HTML utan kan även kommunicera med klienter som stöder Mobile Information Device Profile (MIDP), Simple Object Access Protocol (SOAP) 6

och tunga klienter som stöder extensible Markup Language (XML). Alla dessa klienter använder HTTP som transportprotokoll medan de använder ett annat applikationsprotokoll. En applikation som byggts enligt MVC modellen representerar både affärsdata och implementerar affärslogik. Det finns två sätt att implementera J2EE applikationer. En är att använda Enterprise JavaBeans och den andra är att bygga en modell av Web-tier-komponenter med servlets och JSP sidor. Applikationens modell är gränssnittet mot applikationens affärslogik. Genom att separera affärslogiken från presentationen i applikation ges flera fördelar: Det blir lättare att göra ändringar. Ändringar i affärslogiken kan göras utan att presentationsskiktet ändras. Lättare underhåll. Genom att placera all affärslogik i en enda komponent behöver underhåll bara göras på ett ställe, istället för på flera ställen. Klientoberoende och återanvändning av kod. För att undvika att affärslogiken knyts till en specifik klient slås inte affärslogiken och presentationen ihop. Ligger de separerade kan flera klienter använda samma objekt för att komma åt affärslogiken. Dela upp utvecklingen. Programkod som inkluderar presentation, affärslogik och hantering av förfrågningar blir lätt komplex och svårläst. Om koden delas upp i olika moduler kan utvecklare titta på sin egen del utan att behöva titta på andra delar av koden som de inte är intresserad av. [6] 2.1.2 J2EE J2EE står för Java 2 Enterprise Edition, och är en samling av olika mjukvarustandarder som har blivit utvecklade och godkända av Javaindustrin och specificerar en Java plattform för Internet baserade tjänster och applikationer. De standarder som ingår i J2EE är JDBC - Java Database Connectivity, ett standardiserat API för anslutningar mot SQLdatabaser. JMS Java Messaging Service, för asynkron meddelande hantering. EJB Enterprise Java Beans, för snabb utveckling av distribuerade, snabba och portabla applikationer baserade på Java. RMI Remote Method Invocation, en standard för att komma åt object remote i en distribuerad javamiljö. 7

JNDI Java Naming and Directory Interface, en namnstandard för uppslag av tjänster. Java IDL Java Interface Definition Language, en standard för design av fjärrgränssnitt, för CORBA. Java XML ett antal standarder för hantering av XML dokument i Java program. Java Mail stöd för att skicka e-post. Java Servlets är ett API för att skapa dynamisk information med fullt tillgång till alla Java bibliotek. JSP Java Server Pages, är en teknologi för att skapa dynamiska webbsidor med möjligheten att köra Java kod direkt från webbsidan. För att köra en J2EE applikation måste någon applikationsserver väljas att köra applikationen på. Det finns möjligheter att köra EJB-containers eller servletcontainers om delar av J2EEspecifikationen endast skulle implementeras [9]. 2.2 Applikationsservrar En applikationsserver är en server som är anpassad för att köra skiktade och distribuerade system. Applikationsservern hanterar nästan all affärslogik och dataaccess för applikationen. I stora webbsystem är det många webbservrar som hanterar anropen från klienterna och eventuellt ett antal applikationsservrar som pratar med databaserna. Det finns många olika applikationsservrar att välja på för Suns J2EE-plattform men det finns även ett flertal för.net-plattformen. För J2EE är många öppen källkod och gratis att använda men IBM, Oracle och BEA har egna kommersiella applikationsservrar. Några av de mest kända kommersiella applikationsservrarna är JRun, WebShpere, Oracle Application Server och WebLogic. Populära applikationsservrar som är öppen källkod är JBoss, Resin, JOnAS och Geronimo. Det finns många fördelar med en applikationsserver. Uppdateringar och uppgraderingar blir enklare eftersom affärslogiken är centraliserad till en eller ett litet antal maskiner. Det medför också att det inte är någon risk att gamla versioner av applikationen existerar som behandlar data på ett felaktigt sätt. Det centraliserade sätt som klienter hämtar data och manipulerar det är också bra säkerhetsmässigt för databasstrukturen visas aldrig för användaren. Alla dessa ovanstående fördelar anses vara kostnadseffektiva vilket också har en påverkan på Total Cost of Ownership (TCO)-kostnaderna. [13] 8

Hela den funktionalitet som J2EE standarden erbjuder behövs inte alltid, och då finns det ett antal mindre applikationsservrar som endast tillhandahåller någon delfunktionalitet. 2.3 Servlets När Java introducerades på marknaden var det tänkt att användas till små inbäddade applikationer såsom Applets, men idag är Java mycket mer och ett bra språk för att bygga stora klient/server applikationer. Javas pattformsoberoende tillsammans med automatisk minneshantering gör att det är ett utmärkt val för företag med komplexa miljöer och många olika system och plattformer såsom PC, UNIX/LINUX och Mainframe. En servlet är i stort sett identisk med en vanlig webbserver med support för att komma åt Javas klassbibliotek. En servlet kan ladda in javaklasser dynamiskt i minnet vilket gör att servlets får en bra funktionalitet och hastighet. Servlets är alla sammanlänkade med servern vilket gör att det blir lätt för dem att kommunicera med varandra (Hunter 2001). Fördelar med servlets: Portabla Eftersom servlets är skrivna i Java ges med automatik möjligheten att köra dem på olika plattformar. Kraftfulla - Servlets kan nyttja hela Javas API vilket inkluderar nätverkskommunikation, trådar, datakomprimering, serialisering, internationalisering och stöd för att exekvera metoder i en annan Java Virtual Machine (JVM). Servlets har också full tillgång till J2EE paketet vilket inkluderar Enterprise Javabeans, distribuerade transaktioner, standardiserad meddelandehantering, register uppslagning och avancerad databas access. För utveckling av servlets finns det många tredjeparts produkter att välja mellan för att underlätta olika ändamål såsom XML parsning, avancerad närverkskommunikation och hantering av reguljära uttryck. Effektiva Anropet till en servlet är högst effektivt. När väl en servlet har laddats in ligger den kvar i serverns minne som en objektinstans. När ett anrop kommer till servern kan en servlet anropas på ett snabbt och effektivt sätt med ett enkelt metodanrop, vilket gör att en servlet kan bearbeta ett anrop snabbt. När flera samtidiga anrop sker till servern blir varje anrop behandlat av en separat tråd vilket ger hög skalbarhet. En annan fördel är att eftersom en servlet ligger laddad i minnet hela tiden kan det vara lämpligt att hålla externa resurser såsom databaskopplingar där för de är ofta tidskrävande att skapa. Säkra Eftersom servlets är skrivna i Java ärver de automatiskt den starka typsäkerheten från språket. Då Java inte tillåter pekare och har språket har automatisk 9

garbagecollection blir språket säkert att utveckla i. Java är också bra på att hantera fel eftersom undantagshanteringen fungerar bra. När ett fel uppstår i applikationen kastas ett undantag vilket på ett säkert sätt kan fångas upp av servern och ge användaren ett lämpligt felmeddelande och skriva ner felet i serverns loggar. Flexibla Det är också lätt att ärva en servlet klass för att utöka dess funktionalitet till en mer specialiserad variant av en HttpServlet. Servlets är också flexibla när det gäller skapandet av innehållet. För skapande av komplext innehåll finns det möjlighet att använda sig av mall-motorer såsom Extensible Stylsheet Language Transformations (XSLT). 2.4 Servletcontainers För att kunna köra servlets behövs en servletcontainer. Det finns en mängd olika applikationer att välja bland, många är kommersiella men många är också öppen källkod. De mest populära öppna programmen är Tomcat, Resin och Jetty. De har inte fullt J2EE-stöd, de stödjer endast Servlet och JSP specifikationerna. En servletcontainer är att bra val om det inte finns några krav på att använda någon annan funktionalitet i J2EE-standarden. Tomcat är utvecklat av Apache Software Foundation. Tomcat är helt skriven i Java och kan köras på vilken plattform som helst som stöder Java Runtime Environment. Eftersom servern är skriven i Java och programmet är öppet går det bra att inkapsla Tomcat i sin applikation, vilket ger full kontroll över servern. [11] Jetty är också en webbserver/servlet container helt skriven i Java. Jetty profilerar sig som en webbserver som är enkel, effektiv och lätt att inbädda i applikationer. Eftersom Jetty är liten i storlek är den ett bra alternativ för att inkapslas i applikationen. För att servern ska vara effektiv och lättanvänd för utvecklare har storleken på kärnan försökts hållas liten samt antalet externa beroenden försökt hållas nere. För att lätt kunna utöka funktionaliteten används referenser till externa jar-filer istället. [12] 2.5 Distribuerade teknologier Enterprise-applikationer behöver nästan alltid kommunicera över nätverk och det finns ett antal olika tekniker att använda för detta ändamål. När systemen växer finns det snart ett växande behov av att dela på data eller kommunicera med andra system. I stora system körs kod på olika servers beroende på vilken funktion koden har, och det kan till och med var på olika plattformar. Eftersom detta kräver att ett annat programs adressrymd koms åt ställer det 10

till svårigheter eftersom behörighet att läsa andra programs adressrymder saknas. De flesta tekniker som löser den här sortens problem har flera stora likheter. Metoder som kan köras remote är definierade via någon typ av gränssnitt som kan beskrivas med till exempel Interface Definition Language (IDL). Funktionaliteten för objekten är gömd och det enda som visas för användaren är de publika metoderna. När ett anrop sker till en metod hos ett fjärrobjekt skickas parametrarna via ett fördefinierat protokoll och när servern tar emot meddelandet tas det om hand om och tilldelas parametrarna till metoden. En annan likhet är att alla paradigm har någon form av centralt register som mappar namn till implementationer av objekt (Reilly 2002). 2.5.1 TCP/IP Sockets Sockets kan köras mellan olika plattformar och adressrymder och är flexibelt och snabbt. Men det kräver att server och klient kommunicerar via ett egendefinierat applikationsprotokoll, så båda vet hur meddelanden skall kodas och kodas av. Dessa lösningar kan vara svåra att få att fungera och har en tendens att vara felbenägna. Om det finns höga krav på prestanda är sockets ett bra alternativ eftersom det inte finns någon stor overhead. 2.5.2 Remote Method Invocation (RMI) RMI är en teknik för att dela objekt mellan olika JVM:er över nätverket. RMI tillhandahåller den unika möjligheten att dynamiskt ladda in klasser via deras bytekod i andra JVM:er även om klassen inte är känd i den mottagande JVM:en. Detta underlättar ändring och uppdatering av ett program, för det blir möjligt att lägga till nya klasser endast genom att lägga till eller uppdatera dem på servern. Denna teknik består av en server som skapar fjärrobjekt definierade enligt ett gränssnitt som kan kommas åt av klienter som har en fjärreferens till objektet. RMI tillhandahåller en stub för ett fjärrobjekt som fungerar som en proxy för objektet, och stubben är ansvarig för att exekvera metodanropen. För att skicka objekt mellan olika JVM:er använder RMI objektens serialiseringsmekanism. Genom att implementera java.io:s Serializable interface kan objektet själv serialisera sig till en byteström som sedan kan rekonstrueras igen som en exakt kopia av objektet. Denna teknik passar utmärkt i rena Javamiljöer. En stor fördel är att det går att skicka med hela objekt som argument till metoderna. I ett Remote Procedure Call (RPC)-system är man tvungen att demontera objektet till primitiva datatyper och sedan skicka över dem och sen bygga upp objektet igen i den andra JVM:en. När användare laddar ner stubimplementationerna använder RMI Javas inbyggda säkerhetsmekanism vilket gör nedladdningen säker (Reilly 2002). 11

2.5.3 CORBA CORBA är en annan teknik som är ganska lik RMI, men den stora skillnaden är att den är kompatibel mellan flera programmeringsspråk. CORBA består normalt av en Object Request Broker (ORB) och en server. ORB:en är ansvarig för att matcha de anslutande klienterna till rätt objekt via det medföljande gränssnittet till objektet. Om en ORB uppräcker att objektet ligger på en annan dator packas argumenten ihop och en anslutning upprättas till fjärrobjektet. Metoden exekveras lokalt på den andra maskinen och svaret skickas tillbaka via nätverket till klienten. När gränssnitten designas med CORBA beskrivs de med hjälp av IDL. Vid kompilering av en IDL-fil skapas två stubbar, en som fungerar som en proxy för servern och en för klienten. En annan styrka med CORBA är att det är möjligt att dynamiskt söka reda på information om de objekt som kan användas i runtime. All information om fjärrmetoder lagras i ett gränssnittsregister. Klienter kan i runtime fråga ett repository efter information om fjärrobjekten och använda sig av informationen för att anropa en metod via Dynamic Invocation Interface (DII) (Reilly 2002). 2.5.4 XML-RPC Extensible Markup Language Remote Procedure Call eller XML-RPC som det kallas är en annan teknik som är en uppsättning av implementationer för att köra remote procedure calls över Internet eller lokalt. Som transportprotokoll används HTTP och XML används för kodningen av meddelandena. XML-RPC är designat för att vara enkelt men ändå med möjligheten att kunna skicka komplexa datastrukturer över nätverket för att sedan få tillbaka ett svar. Det finns endast ett fåtal datatyper och kommandon att välja på vilket gör det extremt lättanvänt. Eftersom bara stora standarder används för att skicka data och hur meddelandena kodas kan XML-RPC köras på många olika plattformar och blir därigenom kraftfullt och flexibelt. XML-RPC är enkelt men lite långsamt eftersom XML ger en viss overhead eftersom lika information skickas hela tiden. [10] 2.5.6 Webbservices Denna standard som finns beskriven av W3C har kommit fram genom ett samarbete mellan Microsoft, IBM, BEA och SUN. En webbservice är en tjänst som finns tillgänglig över Internet och XML används för att koda alla meddelanden. Eftersom all meddelandehantering sköts via XML är webbservices inte knutet till någon specifikt programmeringsspråk eller plattform. Webbservices använder sig av väl kända standarder såsom HTTP, HTML, TCP/IP och XML. Webbservices är uppbyggt enligt SOA arkitekturen som står för Service Oriented Architecture. Konceptet är enkelt och byggt för att användas i distribuerade nätverkslösningar och går ut på att tjänster ska kunna delas. Enligt SOA arkitekturen är alla 12

mjukvarukomponenter modellerade som tjänster och designen handlar om att sätta upp gränssnitt mot tjänsterna. Arkitekturen består av tre roller, en som tillhandahåller tjänsten (Service Provider), en som vill utnyttja tjänsten (Service Consumer) och ett register som håller reda på det tjänster som finns publicerade (Registry). En Service Provider publicerar sin tjänst till registret dit en Service Consumer går för att hitta en viss tjänst. Registret håller reda på vilken adress som tjänsten finns på och sedan skapas en koppling direkt mellan Consumern och Providern, se figur 2.3. Figur 2.3, SOA Arkitekturen Simple Object Access Protocol (SOAP) är det protokoll som standarden använder för att skicka meddelanden. Protokollet är byggt för att vara enkelt, flexibelt och plattformsoberoende men ändå tillräckligt kraftfullt för att kunna användas för distribuerade lösningar. Protokollet är helt baserat på XML och uppbyggt med huvud och en body. I huvudet kan extra information läggas in utan att själva informationen i bodyn berörs. Detta gör att det är lätt att lägga till tillägg till information till meddelandena vilket också gör det flexibelt. Det finns och en färdig felhantering för protokollet, vilket gör det lätt att identifiera källan eller orsaken till felet. Det finns också ett färdigt framework för att bygga bindningar av protokollet till olika transportprotokoll om något annat protokoll än HTTP skulle vilja användas. Det går också bra att använda SOAP för Remote Prodcedure Calls vilket är en vanlig lösning för att skicka meddelanden i distribuerade lösningar. Eftersom protokollet bygger på XML passar det bra för att representera abstrakta datatyper eller för att skicka data i ett serialiserat format. Web Services Description Language (WSDL) är ytterligare en standard som webbservices bygger på. En WSDL tjänstebeskrivning är ett XML dokument som beskriver WSDLschemadefinitionen, vilket är en funktionell beskrivning av tjänsten. 13

Det finns tre nödvändiga beskrivningar som dokumentet måste innehålla: Vad tjänsten gör Vilka metoder som finns och hur de användes. Hur kommer man åt tjänsten Vilket dataformat och protokoll som krävs för att komma åt tjänstens funktioner. Var tjänsten finns Den adress som tjänsten finns på, såsom en URL. Universal Description, Discovery and Integration (UDDI) är en standard för att hitta tjänster som finns publicerade på Internet enligt SOA arkitekturen. UDDI hjälper oss med att använda de webbservices som finns publicerade. UDDI fungerar som en katalog för tjänster som tillverkarna av tjänsten valt att publicera. UDDI registret innehåller inte själva tjänsten utan bara en referens till platsen för tjänsten, när någon vill ansluta sig till en tjänst via registret sker en uppkoppling direkt mellan klienterna. Syftet med UDDI är att tillhandahålla upptäckning av webbtjänster både i design time och i runtime [2]. 14

3. Prestanda I detta kapitel kommer prestanda att beskrivas samt vilka delar som blir viktiga när god prestanda skall försöka uppnås. Det kommer också att innehålla en beskrivning av vilka delar som är viktiga när ett belastningstest ska genomföras. Här beskrivs också ett antal metoder för att göra ett system mer skalbart. Prestanda är ett mått på hur lång tid det tar innan du får ett svar tillbaka från systemet. För att kunna leverera bra prestanda måste ett system skala korrekt så att inte prestanda sjunker när antalet anrop ökar. Anropskapacitet är ett begrepp som definierar antalet förfrågningar som kan behandlas under en viss tidsperiod. Ett vanligt mått när det gäller webbsystem är antalet avklarade förfrågningar per sekund. En hög anropskapacitet betyder att vi på ett snabbt sätt betjänar en förfrågan och ger tillbaka ett svar. Detta uppfattas som snabb svarstid för en användare och kan likställas med prestanda (Haines 2005). Varför är det viktigt med bra prestanda? Med dålig prestanda blir effekterna lite olika beroende på vilket typ av system det är frågan om: Interna system - Minskad produktivitet blir påtaglig när de interna applikationerna har dålig prestanda, vilket gör att det tar längre tid för de anställda att göra sina arbetsuppgifter. Någonting som också har påtaglig inverkan är felsökning, då en eller flera andra människor blir tvungna att lämna sina ordinarie uppgifter för att koncentrera sig på prestandaproblemet istället. Dåliga svarstider kan också leda till missnöje och stress. Kommersiella applikationer - När applikationen säljs till externa kunder är det viktigt att inte användarna tappar förtroendet för applikationen. Det kan leda till att kunden går till en annan leverantör när nästa investering skall ske. Det senare fallet ger också en tydlig effekt på intäkterna eftersom försäljningen minskar. Icke-kommersiella applikationer - När det är en tjänsteapplikation som är gratis är prestandan av största betydelse för att inte användarna ska tröttna. Även användarupplevelsen är av stor vikt för om användarna ska fortsätta att använda tjänsten. Hur ska vi göra för att uppnå bra prestanda? Det viktigaste är att slutanvändarnas svarstider är bra. Det går att mäta dessa på två sätt, antingen med aktiva eller passiva tester. 15

Den aktiva övervakning sker med simulerade transaktioner som representerar delar av funktionaliteten som körs mot systemet över en viss tidsperiod. Resultaten från övervakningen kan användas till att se trender för svarstiderna och även larma om det skulle gå utanför vissa gränser. Förhoppningsvis kan med dessa resultat hitta orsaken till svarstiderna innan slutanvändarna märker problemen. Dessa typer av tester är ytterst intressanta att köra från olika delar av världen om det är en internationell applikation. Passiv övervakning kollar på verkliga förfrågningar i runtime. Dessa resultat ger oss en mer sanningsenlig bild över de verkliga svarstiderna som en användare har, och genom att beräkna medelvärde, standard avvikelse, varians, minimum och maximum får vi värdefull information om systemet. Någonting som vi också måste hålla koll på är hur systemets resurser utnyttjas. Eftersom applikationen oftast körs mot någon server finns det flera delar som är viktiga att titta på för att uppnå prestanda: Heapen Pooler Cache Heapen är den viktigaste resursen att analysera, då vi är intresserade av hur många objekt som finns skapade. En felkonfigurerad heap kan resultera i minskad prestanda även om applikationen är skriven helt perfekt. Många väljer Java eftersom språket har automatisk skräphantering och avreferering av objekt. Det är endast när garbagecollectorn körs som minnet frigörs, vilket inte alltid är helt optimalt. Men till skillnad från C++ där all avreferering måste skötas själv är det ändå bekvämt och dagens JVM:er är effektiva. Tillverkarna har lagt ner mycket tid på att komma på smarta algoritmer för detta. Den tyngsta operationen för JVM:en är när långlivade objekt ska rensas upp, det kräver nämligen att alla trådar i JVM:en låses. När en server tar emot en förfrågan läggs den på en kö, som sedan betjänas av trådpoolen. När den behandlats tas den bort från kön. Om poolen inte utnyttjas maximalt skulle resurserna kunna användas av någon annan del i systemet. Men om poolen är överansträngd kommer det att resultera i att förfrågningar får vänta eftersom det inte finns någon ledig resurs. Det sista är typisk en sådan sak som bör undvikas, eftersom det leder till sämre prestanda. En annan viktig resurs är JDBCs anslutningspool. Den är viktig eftersom nästan alla enterprisesystem har en eller flera databaser som det kommunicerar med. Här gäller samma som för trådpoolen att om inga lediga anslutningar finns får klienterna vänta till det blir några lediga. Java Connection Architecture (JCA) anslutningspooler är lik JDBC:s anslutningspool 16

men den här kommunicerar inte med databaser utan andra system som stödjer JCA specifikationen. Ett smart sätt att minska belastningen är att bygga in en cache. För att inte minnet ska ta slut är det är viktigt att cachen har en fast storlek, vilket annars kan resultera i att server kraschar. När cachen blir full måste objekt tas bort för att ge plats åt nya. Detta bör helst undvikas eftersom en cache normalt bara är snabb om den ligger i primärminnet. Vissa cache-implementationer stödjer lagring på sekundärminne om cachen blir full men när detta tillstånd infinner sig tappar nästan cachen sin funktion för den måste lägga all tid på att flytta objekt vilket hämmar prestandan. 3.1 Testplan När en rörelse startas känns det fullt naturligt att ta fram en affärsplan, och det är lika viktigt att göra en testplan när ett utvecklingsprojekt startas för att kunna kvalitetssäkra systemet. Genom att ta fram en testplan fås några delar gratis. Det ena är förståendet av hur användarna använder systemet och det andra är att alla viktiga delar i systemet blir dokumenterade, de kommer också att testas genom hela utvecklingsprocessen vilket garanterar en högre funktionalitetsgrad. För att kunna göra bra testfall är det ytterst viktigt att användarna tas med i utvecklingsfasen, även om alla fall har gåtts igenom missas alltid några. När mönstret för hur användarna använder systemet kan testskript skapas vilka är identiska med riktiga användare. Dessa kan sedan användas både för funktionella tester samt till belastningstester. Detta bör förslagsvis ske på en testmiljö och först när testmiljön är kalibrerad kan applikationen flyttas över till produktionsmiljön. Det bästa är om en identisk miljö kan sättas upp för att köra testerna, men om systemet är stort och komplext är det inte möjligt och en mindre nerskalad variant får användas istället. Att kalibrera ett system är en iterativ process, allteftersom systemet ändrar karaktär och nya funktioner byggs in måste testerna köras på nytt igen. Kalibreringen är någonting som oftast kommer sist i utvecklingscykeln men det är av högsta vikt att det finns med i utvecklingen redan från början. Den totala utvecklingstiden kommer garanterat att minska om tester av koden körs under utvecklingen, då kan fel eller problem upptäckas direkt när ändringar av källkoden gjorts. Det kan vara svårt att ta fram ett korrekt transaktionsmönster av användandet för ett nytt system eftersom det inte finns något underlag för att kunna kartlägga hur användarna använder systemet. Ett sätt att få tag i de mönster som användare följer i systemet är att kolla i loggarna och ta ut all information som är relevant. Ett annat sätt är att titta på de användarfall som finns för systemet, de ska helst tas fram innan systemet byggs och ska illustrera alla händelser i systemet. Om nu dessa finns är de bra att titta på, men det är ganska ofta som det slarvas med dessa. En viktig sak att tänka på när testerna 17

körs är att nästan alla användare är dåliga på att logga ut ur systemet, vilket kan resultera i att många sessioner ligger och skräpar och tar upp plats vilket kan ha viss betydelse. 3.2 Belastningstest För att kunna göra bra belastningstester är det viktigt att ha med ett antal steg (Haines 2005). Det är inte säkert att alla steg alltid blir med, men ju fler som finns med desto mer ökar chanserna belastningstesterna skall lyckas. Återigen är testningen är en iterativ process som kommer att göras om och om igen, och de punkter som listas nedan bör göras i ordningsföljd men inkluderar hela tiden föregående punkts delar: 1. Enhetstester 2. Integrationstest med applikationen 3. Belastningstest av applikationen i testmiljö 4. Belastningstest av produktionsmiljön 5. Kapacitets analys 1. Enhetstestningen bygger på den funktionalitet som behövs i systemet enligt de användarfall som finns framtagna. Varje utvecklare ansvarar för testning av sina komponenter och när ändringar görs körs testerna igen för att se om komponenterna fortfarande uppfyller den funktionalitet som de ska göra. Traditionellt behandlar testerna enbart funktionaliteten av komponenterna och inte prestanda, även om det skulle vara effektivare att redan i detta skede titta över prestandan på koden. När vi kör ett enhetstest kan komponenten analyseras av ett profileringsverktyg som sammanställer en bild av hur minneshanteringen varit under testet och hur mycket tid som spenderats i olika delar av koden, och sist men inte minst om det finns några objekt kvar i minnet efter testet körts klart. Profileringsverktyget kör normalt en garbagecollection och tar sen en kopia av heapen innan testet körs och när testet är färdigt tas en ny kopia. Efteråt ges en detaljerad bild över hur minnet påverkades av testet och även information om några objekt inte laddats ur minnet. De kvarvarande objekten kan vara potentiella minnesläckor som är viktiga att kolla upp om de ska vara kvar i minnet eller inte. En annan viktig minnesrelaterad sak som bör undvikas är att skapa objekt i onödan. I webbapplikationer är det vanligt förekommande att objekt skapas och förstörs i snabb följd. Det vanligaste fallet är när ett objekt skapas inuti en 18

loop vilket illustreras nedan. for (int i=0; i<iterator.hasnext(); i++) { for (int j=0; j<iterator.hasnext(); i++) { Integer maxprice = new Integer(2000); if ((Integer)iterator.next().price > maxprice){ dosometing(); } } } Beroende på hur många poster som finns i de två iteratorerna kommer objektet maxprice att allokeras och förstöras lika många gånger. Om de innehåller 100 poster var kommer detta förfarande att ske 100 x 100 (10 000) gånger. Detta mönster gör att garbagecollection kommer att öka drastiskt eftersom en massa objekt skapas hela tiden. Om vi istället skriver om koden lite kommer allokeringen att ske en gång istället för det 10 000 gångerna. Integer maxprice = new Integer(2000); for (int i=0; i<iterator.hasnext(); i++) { for (int j=0; j<iterator.hasnext(); i++) { if ((Integer)iterator.next().price > maxprice){ dosometing(); } } } Om samma objekt måste skapas vid varje förfrågan skulle en cache kunna vara till hjälp eftersom då kan objektet bara hämtas därifrån utan att behöva skapas. Eftersom servlets ligger laddade i minnet hela tiden som applikationen körs kan det också vara ett bra ställe att lagra statisk information. 2. Integrationen av komponenterna startas när vi har testat alla komponenter och funnit att de har tillräckligt god funktionalitet och prestanda. Det är då dags att kolla om komponenterna klarar av att fungera tillsammans med de andra komponenterna och se om de fortfarande bibehåller samma funktion och kvalitet. Tanken med denna fas är att ytterligare kunna identifiera objekt som ligger kvar på heapen och ineffektiva algoritmer. Här testas hela kedjan av anrop och för att se att alla komponenter håller måttet. Detta test ska inte ses som ett belastningstest utan mer som ett funktionellt test för ett fåtal användare. Om prestandan redan i detta stadium inte skulle vara tillräcklig är det ingen idé att göra ett fullskaligt lasttest. Om ett Service Level Agreement (SLA) 19

finns skrivet gentemot kund är det bra att i detta läge försäkra sig om att systemet uppfyller de krav som utlovats. 3. När systemet har passerat föregående test är funktionaliteten godkänd och eventuella SLA eller krav från kunden uppfyllda under liten belastning, vilket gör att det är dags att testa systemet under lite tyngre last. Denna fas ska testa systemet med det antal användare som systemet förväntas klara av när det är i drift. Någonting att tänka på här testerna körs är att loggning är kostsamt vilket gör att det är bra att vara försiktig med just loggningen. Om testerna gick bra kan det ändå vara en bra idé att köra dem igen med loggningen på. Då finns en chans att upptäcka någonting som går snett i loggarna även om applikationen fungerar. Om vi lyckas identifiera flaskhalsarna redan nu kan de åtgärdas direkt och systemet kommer att klara att leverera god prestanda på lång sikt. Genom att köra denna iterativa process redan när funktionaliteten är enkel i applikationen kommer vi att få fram en stabilare plattform att bygga vidare från. 4. Att testa systemet i produktionsmiljön går ofta bra att genomföra innan systemet har satts i drift. När systemet har användare som kör, ska alla stop undvikas i största möjliga mån vilket gör att testerna blir svåra att genomföra. Det vanligaste är att en liknande testmiljö sätts upp där testerna körs. Ett problem med det är att produktionsmiljön kan stor och komplex. Om systemet har 200 servrar i produktion blir det dyrt att sätta upp en liknande testmiljö för att kunna köra så rättvisa tester som möjligt. 5. I det sista steget fungerar systemet bra och det svarar upp till de SLA som skrivits. Nu gäller det att pressa systemet till den punkt när systemets resurser börjar ta slut och svarstiderna ökar drastiskt. Det gäller att långsamt öka antalet användare för att kunna se vilka av anropen som inte klarar av att svara upp mot sina tidskrav. Under testet loggas vid vilken nivå som respektive anrop inte längre klarar av att svara. Att testa ett webbsystem skiljer sig en del från applikationer som installeras på en klient (Cohen 2004). Antalet samtidiga användare kan öka från ett till 10 000 när som helst. För att kunna garantera att användarna kan köra systemet utan att det känns långsamt gäller det att hitta och förstå karaktäristiken för skalbarheten och felfrekvensen i systemet när lasten är hög. Eftersom både skalbarheten och felfrekvensen är nära sammankopplade måste båda testas annars blir svaret svårt att analysera. Skalbarheten beskriver hur applikationen klarar av att fungera under olika nivåer av last, exempelvis kan tester köras med 1, 100, 1 000 och 10 000 samtidiga användare. Ju fler nivåer vi testar på desto bättre kontroll får vi på hur systemet beter sig, men det blir också mer tidskrävande. Det är även viktigt att titta på svaret från 20

systemet för om hälften får tillbaka en sida med ett felmeddelande klarar inte systemet av belastningsnivån. Tabell 3.1 visar ett exempel på en sammanställning från 4 tester med olika antal samtidiga användare. Denna sammanställning ger en bra översikt över hur systemet skalar och vi vid vilket antal som eventuellt systemet får problem. Det är fullt naturligt att svarstiderna ökar för ju fler samtidiga användare desto mer resurser krävs av systemet. Systemet skalar bra om svarstiden ökar linjärt med antalet användare. Det går också att se om någonting drastiskt händer vid en speciell nivå, vilket skulle vara värdefullt. Tabell 3.1, Visar en fördelning över svarstiderna vid olika belastningsnivåer. < 1 sekund 2-5 sekunder > 5 sekunder 1 85 % 10 % 5 % 100 75 % 15 % 10 % 1 000 70 % 20 % 10 % 10 000 60 % 25 % 15 % Skalbarhetstestet tar inte hänsyn till användarupplevelsen av applikationen, den visar endast verkliga fakta från testerna ur systemets perspektiv. Därför måste också antalet fel mätas under testerna för att säkerställa att systemet returnerar korrekt information. Tabell 3.2 visar antalet sidor med fel som visats vid samma belastningsnivåer. Tabell 3.2, Visar procentuellt antal felaktiga svar till klienten vid olika belastningsnivåer. < 1 sekund 2-5 sekunder > 6 sekunder Totalt 1 1 % 5 % 7 % 13 % 100 2 % 4 % 10 % 16 % 1 000 4 % 9 % 14 % 27 % 10 000 15 % 25 % 40 % 80 % För att kunna göra riktiga slutsatser behövs informationen från båda tabellerna. Om bara den första tabellen analyseras vid en belastning på 10 000 samtidiga användare hade endast 15 procent problem med att sidor visades långsamt. Men när prestandatabellen analyseras visar den att 80 procent av alla sidvisningar skulle ge en felaktig sida tillbaka vid samma 21

belastningsnivå. Detta är ett bra exempel på att båda dessa parametrar behövs för att kunna göra en riktig bedömning av hur ett system beter sig. När ett belastningstest har körts finns det ett antal frågor som Haines (2005) vill ha svar på: Vilka anrop är långsammast att köra? Vilka anrop är mest förekommande? I dessa anrop vilka delar tar längst tid? Är prestandaproblemen orsakade av kod, konfiguration eller andra yttre beroenden? Det är viktigt att gå igenom alla långsamma anrop och hitta orsaken till varför de är långsamma. Beror det på att metoden är långsam, att databasanropet är långsamt, eller på tråd eller minnesproblem. Om det går att förstå att det är kodrelaterat måste metoderna gås igenom för att hitta orsaken. Skulle ändå prestandan vara ett problem är det bästa sättet att köra samma anrop igen men denna gång genom ett profileringsverktyg. Om det är möjligt att hitta någonting i de mest frekventa anropen kan även små ändringar göra ganska stora förbättringar om det är många anrop. För att kunna beräkna hur många samtidiga användare som kan betjänas kan en kapacitetsanalys göras. Med det menas en belastning av systemet ända till dess att svarstider ökar okontrollerat. Ett anropsbaserat system har alla samma karaktäristik som visas i figur 3.1. När antalet användare ökar är det som skiljer sig vid vilket antal samtidiga användare som svarstiderna påverkas (Haines 2005). Figur 3.1, Belastningsdiagram för ett webbsystem 22

När antalet användare ökar är det fullt naturligt att systemets resursutnyttjande stiger eftersom mera resurser krävs för att klara av arbetet. Slutligen nås den gräns när lasten blir för hög för systemet och resurserna i systemet inte räcker till längre. Till slut kommer svarstiderna att öka exponentiellt eftersom systemet inte hinner med alla inkommande anrop. Det gäller att klara av och köra systemet med hög last utan den övre gränsen överskrids för då klarar inte systemet av att leverera längre. Att ha en buffert mellan 25-40 procent är ett bra riktmärkt enligt Haines. Det är dock ingen bra idé att ha för stor buffert för då kan systemet vara överdimensionerat vilket skulle kunna innebära att man betalar pengar i onödan för någonting som inte behövs. Men själklart är det ändå bättre att ligga närmare den övre gränsen än den undre för att vara på att den säkra sidan. En viktig sak att tänka på är att inte hålla på och försöka optimera koden och systemet för mycket, enligt Ashmore (2004) så kommer de stora vinningarna att ske under de första 20 procenten av arbetet. Det är i början som de mest uppenbara och stora problemen upptäcks. Det är också viktigt att inte börja med optimering av applikation förrän den är i sådant skick att den är testbar. Utvecklare bör inte heller försöka optimera koden hela tiden för i slutändan är chansen att just de delarna ändå inte spelar någon roll i det stora hela. Med detta menas inte att koden skall skrivas hur som helst men att sitta och optimera koden hela tiden är mer tidskrävande och ineffektivt än att göra det i slutet när hela applikationen är färdig. För att kunna initiera ett lasttest måste någon typ av lastgenerator skapas, vilket är någon typ av mjukvara. Det finns många färdiga typer av lastgenerator att använda och många är gratis att ladda ner från Internet. Uppsättningen av lastgeneratorn innebär att klienten anpassas till systemet, exempelvis måste klienten först logga in och sen utföra en serie av anrop. Sedan kan x antal klienter startas upp och på så sätt simuleras x antal samtidiga användare. Resultaten från körningarna kan sammanställas till rapporter där det blir enkelt att se om alla delar uppfyller de utlovade prestandakraven. För att kunna ställa en diagnos av applikationen varför den har den prestanda den har måste ett profileringsverktyg användas. Med hjälp av verktyget får vi fullständig tillgång till JVM:en och kan titta på utnyttjandet av alla resurser. Det går att se hur mycket minne som är allokerat och vilka typer av objekt som finns inladdade i minnet, se bilaga C. Det går också att se hur mycket CPU-tid som varje metod som körs i JVM:en tar och vilka klasser och metoder som tar mycket tid, se bilaga D. Det går också att titta på hur trådar körs och används och hur skärpsamlaren används. När systemet endast kör i en JVM är det lätt att få en bra överblick över minnesresurserna men om systemet är stort och körs på flera maskiner och JVM:er blir det lite svårare. Det är då vanligt att presentationslagret ignoreras för det är oftast i affärslogiken eller längre ner som de tunga delarna ligger, förutsatt att applikationen är byggd i olika lager. 23

Enligt Marinescu (2006) är det viktigt att inte bara testa skalbarheten utan även hur databasen klarar av att leverera den information den ska klara. Genom att testa systemet när databasens storlek ökas till en hög nivå simulerar att systemet har körts en längre tid. För att kunna testa databasen med mycket information måste ett program eller ett script skapas som fyller upp databasen med riktig information. Testet ska först köras mot databasen när den är i dess ursprungliga storlek, därefter körs samma test om igen men nu med databasen uppskalad till en hög nivå vilket motsvarar många användare. Om svarstiderna ökar för mycket när databasstorleken ökat skalar inte databasen på rätt sätt. Det kan finnas flera olika felkällor men den enklaste och mest uppenbara att titta på är om alla index är rätt uppsatta så läsning av tabellerna inte kommer att ske i linjär tid. För även om en tabell har 100 000 rader jämfört med 100 ska det gå snabbt att slå upp information i den om alla index är rätt uppsatta. Detta test ger en bra bild över hur databasen klarar av att växa. 3.3 Skalbarhet 3.3.1 Systemarkitektur För att utveckla ett system som har bra prestanda är det viktigt med en bra systemarkitektur. Alla skulle vilja ha ett system med bra prestanda, hög säkerhet, hög flexibilitet. Att ta fram en optimal lösning är dock ingenting som är enkelt och inte helt kompromisslöst. När designen för ett datasystem är bestämd finns det många olika behov, vissa funktionella och andra icke-funktionella. De funktionella kraven beskriver i stora delar systemets funktionalitet, hur systemet ska bete sig i olika situationer. Dessa behov kan brytas ner i användarfall och är oftast ganska lätta att hantera. De icke-funktionella behoven beskriver restriktioner, gränser och andra viktiga aspekter för att tillhandahålla den önskade funktionaliteten. Ett exempel på ett icke-funktionellt behov är att systemet måste klara av 5000 anrop i sekunden. Det finns mycket att säga om de icke-funktionella behoven för de interagerar nära med varandra. När en design av arkitekturen valts gäller det att hitta en bra balans mellan dem Haines (2005). De icke-funktionella kraven kan delas upp i grupperna som beskrivs i figur 3.2. 24

Figur 3.2, Icke-funktionella behov Prestanda - Det är ytterst viktigt att användare inte upplever dålig prestanda, det kan lätt leda till att användare överger produkten om det är lätt att byta ut den mot någonting annat. En viktig uppgift är att hitta och upptäcka flaskhalsarna och hitta handlingsplaner för hur de ska tas omhand om. Dessa aspekter bör ses över redan vid designen av systemet. Tillgänglighet - Det finns mycket som kan störa ett systems drift. En del kan tas om hand om med felhantering och övervakning, andra går det inte att förutsäga. Tillgänglighet är ett mått på tiden som systemet är tillgängligt att köras. Men vad krävs för att uppnå hög tillgänglighet? Det finns båda hårdvaru- och mjukvaruproblem att ta hand om. Det lättaste att hantera är hårdvaran, för det går att multiplicera alla kritiska komponenter i systemet för att få redundans. Det går att använda flera nätverkskort, flera hårddiskar och RAID (Redundant Array of Independent Disks) för att sprida ut informationen på flera diskar. Men mjukvaruproblemen är svårare att hantera. Det kan vara minnesläckor, säkerhetsuppdateringar eller vanliga uppgraderingar av systemet. Om systemet har byggts med en bra arkitektur kan uppdatering göras av en server eller modul i taget, detta utan att störa resten av systemet. Skalbarhet - Skalbarhet är en faktor som behöver ses över när antalet användare blir stort, då kan det bli viktigt att kunna behandla tusentals anrop från klienter. För att kunna klara av detta måste anropen spridas ut för att det finns alltid en fysisk begränsning i vad en server klarar av att leverera. För att fortsätta och bevara hög prestanda när lasten på ett system ökar, kan en lastbalanserare sättas som front för skiktet. Lastbalanseraren ansvarar för att dirigera trafiken till de servrar som ingår i klustret. Säkerhet - Säkerheten är nästan helt omöjligt att garantera till hundra procent för ett system som ligger publikt på Internet. Även om det lokala systemet har en bra säkerhet kan svagheterna ligga i exempelvis operativsystemet som systemet körs på eller i någon av de tredjeparts program som eventuellt har använts. Men du kan 25

skydda dig genom att använda de tekniker och program som hjälper till med att öka säkerheten såsom kryptering, certifikat och brandväggar. Underhållsmässighet - För att kunna tillgodose de icke-funktionella krav som de flesta system har måste uppdateringar av systemet göras lite då och då. Då är underhållsmässighet ett krav som ligger nära tillgänglighetskravet för om du måste uppgradera systemet blir direkt tillgängligheten lidande även om du bara ändrar i någon del av systemet. Flexibilitet - Med flexibilitet menas möjligheten att producera nya versioner av applikationen för att tillhandahålla ytterligare funktionalitet. För att inte var låst till någon databastillverkare utan det skall vara möjligt att lätt byta till någon annan tillverkare om det skulle bli aktuellt. För att skapa flexibla system kan tekniker som abstraktion och skiktning användas, de är inte heller alltid bra för prestandan. Portabilitet - Ett portabelt system är ett sådant som kan köras i många olika miljöer såsom minidator, stordator eller PC. System som är utvecklade i Java har oftast denna funktion inbyggd med automatik eftersom Java stöds på de flesta plattformar [8]. 3.3.2 Analysverktyg För att kunna analysera ett system måste vi samla information från systemet. Att samla in data är inte det svåra, det gäller bara och veta vilken information som är intressant. Däremot kan det vara svårt att tolka informationen. Det räcker inte med att bara samla in information från applikationen utan information om hur systemet mår är lika viktigt. Insamling av data för prestanda kan ske på flera sätt, antingen via olika typer av APIer eller också implementeras det direkt i koden. På senare tid har det blivit lättare att komma åt informationen vill ha mycket tack vare att många applikationsservrar har anammat gränssnittet Java Management Extensions (JMX). JMX tillhandahåller en arkitektur för övervakning av applikationer och nätverk skrivna i Java. Det finns stöd för att ställa frågor om konfigurationen och ändra den i runtime. Men för att kunna mäta svarstider på metodnivå eller göra djup analys av Structured Query Language (SQL) måste kod användas. Det går att på egen hand lägga in koden som samlar in informationen eller också används något av de verktyg som finns. En fördel med att göra det själv är att du får fullständig kontroll på det som ska övervakas och det kan sen presenteras det på valfritt sätt. Men att använda ett färdigt verktyg ger också många fördelar: Källkoden blir renare, koden för övervakningen behöver inte skapas. 26

Verktygen kan övervaka hela applikationen Koden är skalbar både uppåt och neråt, loggning kan ske av stora mängder data. Verktygen kan gå in i bytekoden och göra tilläggen för övervakningen där. All information samlas upp på något centralt ställe. De mest avancerade verktygen kan följa anrop genom flera JVM:er. 3.3.3 Klustring av applikationsservrar Med ett kluster menas en grupp applikationsservrar som alla kör en J2EE-applikation som om de vore samma enhet. Det finns två sätt att skapa ett kluster, antingen sker skalningen vertikalt eller horisontellt. Med vertikal skalning menas att antalet processorer och minne ökas och flera instanser körs på samma maskin. Horisontell skalning innebär att flera maskiner kopplas till klustret. För att kommunicera inom klustret finns tre olika varianter. Den första innebär att alla servrar har sin egen uppsättning av filsystemet, det vill säga egna filer för alla applikationer. Den andra innebär att alla servrar delar filsystem, då finns alla filer lagrade centralt där alla maskiner i klustret kan hämta informationen till applikationerna. Den sista innebär att det finns en administrationsserver som har hand om alla filer. Då ansvarar administrationsservern för att alla servrar har en uppdaterad version av applikationerna, vilket innebär att applikationer kan tryckas ut och även tas bort om de har avinstallerats. En viktig sak att tänka på är att alla delar i systemet med unika uppgifter måste dupliceras annars finns det ändå en sårbar punkt. Enligt Penchikala (2004) är följande aspekter viktiga att tänka på innan vi bestämmer oss för att implementera ett kluster: Ska systemet skala vertikalt eller horisontellt? I vilket lager borde klustret implementeras? Var någonstans i systemet måste en lastbalanserare sättas in? Hur ska sessioner hanteras? Vilken typ av policy ska användas för lastbalanseraren? Slumpvis, round-robin, viktbaserad eller den minst belastade servern? Hur vet vi när en server är nere? När borde en förfrågan avbrytas och försöka skickas till en annan server? 27

3.3.4 Lastbalansering Det finns två olika typer av lastbalanserare. Den ena är en mjukvara som kan installeras på en maskin och kallas mjukvaru-lastbalanserare. Den andra kallas hårdvaru-lastbalanserare och är precis som den låter egen hårdvara med lastbalanseringsfunktionen färdiginstallerad. Den senare är dedikerad till uppgiften att dirigera trafiken på det sätt den är konfigurerad att göra. Eftersom Tomcat valdes som servletcontainer har jag undersökt några alternativ för att lastbalansera just Tomcat. Om inte ekonomi spelar roll är det effektivast att ha en dedikerad hårdvaru-lastbalanserare eftersom den endast har en uppgiften. Med Tomcat följer det med en webbapplikation som heter Balancer och den är en lastbalanserare. Den är enkel att använda och blir automatiskt installerad när Tomcat installeras. Det går att definiera regler som sedan kan köras i kedjor av regler, för att exakt kunna specificera hur trafiken skall gå. Reglerna bygger på ett färdigt gränssnitt vilket det gör det flexibelt och enkelt att bygga sina egna regler. Den är dock inte tänkt för stora enterprise webbsystem. Den annan lösning är att låta Apaches HTTP-Server agera lastbalanserare. Apache HTTP- Server är ett öppet källkodsprogram och därmed fritt att använda vilket gör den till ett bra val. Den kan konfigureras för att direkt skicka alla förfrågningar via en speciell port direkt till Tomcat. 28

4. Genomförande I detta kapitel kommer en beskrivning av hur utvecklingen av SquaceML gick till. Jag kommer också att beskriva protokollet och ge exempel på hur det kan användas. Jag kommer också att beskriva hur framtagandet av testplanen gått till och uppsättningen av testmiljön. Sist i kapitlet ges en beskrivning av hur de första testerna gick och vilka flaskhalsar som hittades. 4.1 Kommunikation 4.1.1 Extern kommunikation Förfrågningarna sker via kommunikationsprotokollet HTTP som också är det vanligaste protokollet och en standard för fråga/svar applikationer över Internet. Den senaste versionen av protokollet är 1.1 och hanteras av de flesta webbläsare idag. Utvecklingen av HTTPprotokollet ansvarar World Wide Web Consortium och Internet Engineering Task Force för och den nuvarande version 1.1 har funnits sedan 1999 och finns beskriven i en RFC (RFC2616). Idén är att en förfrågan skickas till systemet antingen från Javaklienten i mobilen eller från den inbyggda appleten som finns integrerad på webbsidan. Båda klienterna bygger på samma kodbas och pratar därför samma språk vilket betyder att endast en typ av förfrågningar kommer in till systemet. Det är en servlet som tar hand om den inkommande förfrågan. Den tar hand om autentisering av klienten och skickar sedan vidare förfrågningen in i systemet, se figur 4.1. Figur 4.1, Extern kommunikation 29

Det protokoll som klienterna och inkopplingsmodulen pratar är internt och kommer inte till en början att vara publikt. Om protokollet i en framtid släpps fritt öppnar det möjligheten att skriva egna klienter till systemet. Om nya klienter börjar utvecklas kan också efterfrågan på fler stödda protokoll bli aktuell. Då skulle en protokollrouter kunna sättas in framför inkopplingsmodulen för att stödja flera protokoll, enligt Web-tier-mönstret. SquaceML är namnet på det publika protokoll som är gränssnittet mot informationsleverantörerna, se bilaga B. Systemets funktion kan liknas med en proxy där all trafik går genom systemet och sedan vidarebefordras. Detta innebär att det är innehållsleverantörerna är ansvariga för att den information som visas under deras länk är uppdaterad och korrekt. Protokollet är baserat på XML och kan liknas med hur RSS-formatet är uppbyggt. En RSS-läsare går till en Internetlänk och läser in sidan som är kodad enligt RSS standarden. I det här fallet ska sidan vara kodad enligt SquaceML standarden istället, men funktionen är den samma. Om sidan till den begärda URL:en redan är SquaceML kan den direkt returneras till klienten. Men om sidan är en RSS eller någon annan typ måste informationen först konverteras till SquaceML innan den kan skickas tillbaka till klienten. När utseendet var bestämt för klienten, var min uppgift att försöka hitta en bra struktur för att kunna skicka den information som behövdes. Jag använde mig av ett XML schema för att bygga upp strukturen. Tanken med det var att validering av sidor skulle kunna göras mot schemat. Det skulle vara ett värdefullt verktyg att ha när utvecklingen av en site görs, för att verifiera att den XML som finns är korrekt. Det skulle kunna göras med en webbsida som tar länken till siten som parameter och gör valideringen av sidan mot schemat. Sedan kan feedback ges tillbaka till användaren om valideringen gick bra eller dåligt. Det kommer att bli viktigt att läsa in sidorna i systemet på ett effektivt och kontrollerat sätt, för de flesta externa sidor som hämtas kommer att vara SquaceML-sidor. För att läsa in sidorna i systemet använde jag mig av en programvara som heter Java Architecture for XML Binding (JAXB). JAXB används idag för att konvertera XML-strukturer till Javaobjekt och tvärtom. Den kan dessutom validera dokumentet mot XML-schemat direkt vi inläsning. För att tillverka de Javaobjekt som behövs för att beskriva protokollet använde jag mig av ett annat program som översätter ett XML-schema till Javaobjekt. Programmet heter XML to Java Compiler (XJC), och följer med som ett extraprogram till JAXB. Med hjälp av JAXB kan SquaceMLsidor enkelt läsas in i systemet och de blir automatiskt konverterade till Javaobjekt. Protokollet är designat efter gränssnittet i mobilen vilket gör att leverantörerna själva kan anpassa sina egna sidor på ett enkelt och dynamiskt sätt. Under alla rutor finns en länk som pekar på en ny sida med samma struktur, vilket gör att en site kan byggas mer eller mindre hur 30

djup som helst. Utvecklaren har kontroll över det mesta i gränssnitten förutom den nedre raden där det finns navigeringsknappar och plats för favoritlänkar. Det finns stöd för två olika vyer i protokollet, en som visar ett rutnät och en som visar upp en artikel. Headtaggen har med utseendet på huvudet i klienten att göra, se figur 4.2. Det som går att påverka är ikonen uppe till vänster där en länk och en ikon till siten kan läggas in. Det går att skapa tabbar för gruppering av informationen och det finns ingen begränsning på hur många. Om tabbarna inte skulle få plats på samma sida kommer det en höger-pil längst upp till höger. Men antalet tabbar bör försöka hållas nere annars blir det oöverskådligt. Då är det bättre att försöka hitta underkategorier till huvudkategorierna istället eftersom det inte finns någon begränsning på hur djup struktur som kan byggas. Figur 4.2, Headelementet Bodytaggen beskriver bodyn som antingen kan vara ett rutnät eller en richtext, se figur 4.3. Figur 4.3, Möjliga body element 31

Figur 4.4 visar hela klienten och den motsvarande XML-strukturen till bilden visas under figuren. Figur 4.4, Klientens förstasida <squaceml> <head> <title>my Page</title> <iconimage src= http://www.site.com/images/microphone.jpg title= Settings > <tablist> <tab text= My Page selected= true link= länk vid klick ></tab> </tablist> </head> <body> <squaregrid bgimage= mybackgroundimage.jpg > <square title= New Content link= http://www.site.com/newcontent/ ></square> <square title= Affärsvärlden link= http://www.affarsvarlden.se/rss.xml displayletter= A ></square> <square title= Apple Hot News link= http://images.apple.com/main/rss/hotnews/hotnews.rss ></square>. </squaregrid> </body> </squaceml> I figur 4.5 visas ett exempel på hur en artikel kan se ut i mobilklienten eller appleten, och under finns den motsvarande XML filen. 32

Figur 4.5, En artikel i mobilklienten <squaceml> <head> <iconimage iconsrc="http://www.site.se/images/site_icon.jpg link="http://www.site.se/ title="site.se" /> <title>site.se</title> </head> <body> <infobox> <content> <![CDATA[ <img src="http://www.site.se/milan.jpg ><BR><BR><b>Milan fick revansch</b><br><br><em>milan vann Champions League-finalen mot Liverpool i Aten. </em><br><br>milan fick revansch<p/>i Istanbul förlorade Milan ansiktet. På onsdagen var laget i Aten för att ta det tillbaka.<p/> ]]> </content> </infobox> </body> </squaceml> Detta gör att utvecklare enkelt kan bygga sina siter helt valfritt. Det som behövs för att bygga en site är en publik webbsida som kan skriva ut XML. 4.1.2 Intern kommunikation Än så länge är hela systemet skrivet i Java och all funktionalitet ligger i samma JVM. Ända till den dagen kommer då integration med andra system blir aktuell eller funktionalitet bryts ut till en annan server kommer den interna kommunikationen att vara enkel eftersom alla program exekveras i samma JVM. I figur 4.6 visas anropskedjan för en förfrågan som kommer till systemet. 33

Figur 4.6, Hur en förfrågan till systemet tas om hand. Alla förfrågningar kommer att gå via inkopplingsmodulen som sedan skickar vidare förfrågan till Dispatchermodulen. Här finns informationen om alla registrerade plug-ins. Beroende på vilken typ av förfrågan som kommer in, kommer en passande plug-in att köras. En plug-in kan impelmentera fyra olika interface, requestfilter, requestfetcher, responseconverter och responsefilter vilka syns i figur 4.6. Det är sedan upp till den modul som implementerar pluginen och bestämma vilken funktionalitet som behövs i plug-inen. Kedjan för en förfrågan är inte helt olik den som Web-tier använder sig av. Dispatchermodulen tolkar förfrågan och skickar den sedan vidare till någon plug-in, där logiken för inläsningen och behandlingen ligger. När inläsningen lyckats och konverteringen till squaceml gjorts kan vi bestämma hur svaret ska se ut som returneras till klienten. 4.2 Testning Testningen kommer att bestå av två delar, den första är utvecklingen av en testplan som sedan kan användas för att uppsatta målen. Den andra delen av testningen är belastningstesterna. De kommer att användas för att försöka hitta flaskhalsar som bara kan upptäckas när systemet belastas. Testerna kommer att ge svar på hur de olika modulerna klarar av att samarbeta under last. Test av funktionaliteten av modulerna kommer inte att göras utan det är en förutsättning för att det sak vara någon idé att köra lasttesterna. 4.2.1 Testplan Utvecklingen av testplanen startade med att jag definierade de punkter som var relevanta för testet: Sätta upp ett mål för testet Bestämma den maximala svarstiden för en förfrågan Skapa en testklient som kan simulera mobilklienten Ta fram ett transaktionsmönster för att simulera användare 34

Skala upp databasen till det önskade antalet användare Ta fram verktyg för att kunna analysera under testet Det första som behövdes göras var att bestämma målen med testet. Tillsammans med uppdragsgivarna bestämdes att målet skulle bli att säkerställa att serverarkitekturen skulle klara av att skala även om det skulle bli 50 000 samtidigt inloggade mobilklienter. Men för att klara av att köra systemet med så många samtidiga användare kommer troligen inte hårdvaran att räcka till. Idag körs systemet på en enda maskin vilket förmodligen är för lite. För att det ska bli möjligt att uppnå de önskade nivåerna kommer testning att behöva köras parallellt med utvecklingen i takt med att systemet växer och mer hårdvara adderas. Den totala tiden som det får ta för en förfrågan bör inte överstiga en sekund eftersom den slutgiltiga tiden kommer att vara betydligt längre beroende på uppkopplingstider, nedladdningstider och generering av information. För att simulera x antal klienter använde jag ett Framework för belastningstester som heter Rteload. Med hjälp av programmet kan ett stort antal samtidiga klienter startas och sedan kan statistik från körningen genereras. I figur 4.7 visas hur en rapport från en körning kan se ut. Högst upp visas antalet förfrågningar som gjorts under testets tid, sedan kommer start- och stopp-tider för testet. Nedersta raden visar detaljerad statistik för den förfrågan som gjorts, i det här fallet laddning av hemsidan. Transaktions Per Second (TPS) visar antalet transaktioner gjorda per sekund, och resten av fälten visar matematiska beräkningar på utfallet. Om vi skulle testa flera länkar skulle det finnas flera rader med information till varje länk. Benchmark report Number of samples: 7460 Test started: Mon Sep 24 14:17:51 2007 Test ended: Mon Sep 24 14:20:16 2007 Transname TPS Num Mean Max Min Stddev P90 P95 homepage 51.45 7460 0.13 0.57 0.06 0.01 0.19 0.21 Figur 4.7, Benchmark report från ett test Kommunikationen mellan klienten och systemet bygger på HTTP. I testramverket finns en färdig webbklient för att koppla upp sig mot siter. Klienten behövde modifieras så den pratade 35

samma protokoll som klienten och servern gör. Det bestod i att skicka ett antal parametrar som systemet förväntade sig att få. För att bestämma ett transaktionsmönster körde jag själv mobilklienten och noterade det sätt jag navigerade runt i applikationen, se bilaga A. Eftersom systemet vid testtillfället inte var öppet för allmänheten fanns det inga definierade mönster över hur användare navigerar sig i applikationen. Det fanns inte heller några användarfall framtagna som var till någon hjälp. Uppskalningen av databasen till önskat antal användare gjordes med ett antal JUnit-tests som använde sig av systemets datamodell för att skapa användare och den information som normalt skapas vid samma tillfälle. För att få det mer realistiskt har jag varierat antalet bookmarks för användarna, vilket har betydelse vid laddningen av förstasidan i klienten där alla personliga bookmarks listas. För att kunna analysera hur Tomcat mår var jag tvungen att använda mig av någon profileringsverktyg. Jag använde mig av JProfiler som är ett bra verktyg för profilering av Java-applikationer. Tomcat kan startas upp med ett extra kommando och sedan kan minnesoch CPU-lasten kollas i runtime. Det går också att se hur många trådar som körs och hur mycket resurser som är allokerat för hela JVM:en. Figur 4.8 visas hur mycket minne som heapen har använt i den aktuella JVM:en. Figur 4.8, JVM-vy i jprofiler För att kunna komma upp till nivån 50 000 användare kommer testerna att behöva köras olika etapper. I tabell 4.1 visas den tänkta planen för att successivt öka antalet användare och förfrågningar. 36

Tabell 4.1, Visar en fördelning över svarstiderna vid olika belastningsnivåer. Försök Användare Transaktioner per sekund Anropsfrekvens 1 100 20 5 sek 2 1000 200 5 sek 3 5 000 1 000 5 sek 4 10 000 1 000 10 sek 5 20 000 1 000 20 sek 6 30 000 1 000 30 sek 7 40 000 1 000 40 sek 8 50 000 1 000 50 sek Målet är att komma upp till 1000 transaktioner per sekund. För att komma upp till den nivån kan frekvensen ökar och om 5000 användare skulle göra ett anrop var femte sekund skulle den nivån uppnås. Det är inte särskilt troligt att en användare hinner med att göra någonting så ofta. För att hålla den nivån kan vi successivt sänka anropsfrekvensen när antalet användare stiger. Sedan gäller det att systemet klarar av att fortsätta leverera den transaktionslasten då antalet användare ökar. 4.2.2 Belastningstestet Vad är det som behövs testas och vilka delar kan vi testa? Applikationen är tänkt att köras i mobiltelefonen som sedan kommunicerar med Internet. Därför är det mest intressant att mäta den tid som systemet tar på sig att generera svaret till klienten. Vi kan mäta den tid det tar för en förfrågan från det att den kommer in till systemet fram till den tid då svaret är redo att skickas tillbaka till mobiltelefonen. Uppkopplingstider och nedladdningshastigheter mellan telefonen och systemet är faktorer som vi inte rår över, då vissa kör 2G, vissa 3G och andra WLAN. Andra tidsfaktorer som kommer att variera är den tid det tar för systemet att koppla upp sig mot den begärda URLen, renderingen av sidan och nedladdningen av sidan, vilka visas i figur 4.9. 37

Figur 4.9, Utomstående tidsfaktorer som inte kan bestämmas Jag vill försöka minimera påverkan av yttre faktorer för att testerna ska kunna jämföras på ett bra sätt. Om det helt plötsligt under ett test visar sig att CPU:n rusar upp och det är något annat program som tar resurserna blir det svårt att analysera resultaten av körningarna. För att slippa påverkan från externa källor vill jag försöka skapa en så isolerad miljö som möjligt. För testerna har jag skapat statiska sidor som inte behöver genereras vid varje anrop vilket gör att inläsningen av sidan kommer att vara optimal. När anrop kommer att göras mot externa siter kommer svarstiderna att vara längre eftersom de flesta har dynamiska webbsidor som genererar sidan. Sidorna som används för testet ligger på en webbserver som sitter på samma nät och har en uppkoppling på 1-Gigabit, vilket borde göra att svarstiderna blir i det närmaste konstanta. När antalet testanvändare är lågt kommer det troligen att fungera bra, men längre fram kommer även bandbredden att bli en potentiellt trång sektor. För att sprida lasten kan vi användas oss av flera webbservrar i testerna för att de inte ska bli nedlastade. Vid det första testet körde jag med 100 samtidiga användare men redan vid 30 stycken var processorbelastningen upp i 100 %, vilket inte var någon bra indikation. När jag kom till 70 användare slutade Tomcat att svara. Detta indikerade på att någon resurs måste ha tagit slut, men för att få reda på vilken behövde jag köra profilering på JVM:en. För att kunna profilera Tomcat var jag tvungen att hitta en nivå med användare där applikationen inte gick ner. Vid 30 användare klarade systemet av att köra utan att gå ner och då kunde jag gå in och titta hur JVM:en såg ut. Med jprofiler syntes det att en massa nya trådar skapades hela tiden som bara levde en kort stund för att sedan bara ligga och vänta. Efter att ha granskat koden visade det sig att bildinläsningsrutinen skapade en ny tråd för varje bildförfrågan istället för att använda sig av en trådpool. Anledningen till att bildinläsningen gjordes i en egen tråd var för att kunna köra två processer parallellt. Tanken med att ha en separat tråd för att läsa in bilderna var bra, för samtidigt gjordes komprimering av de andra delarna i svaret. Men att starta en tråd tar en hel del resurser av systemet så vinningen jämfört med att göra allting sekventiellt var inte så stor. Efter att tagit bort skapandet av trådarna gick applikationen att köra utan problem med 50 samtidiga användare. Nu var applikationen stabil och det var dags att gå in och kolla med 38