Vaadin is a framework for building rich web applications. Vaadin features server-side architecture where all of the business logic is located on server and only presentation layer is located on client side. Server-side architecture can be advantage since session state is stored on server. Statefulness can also be a disadvantage since server is frequently contacted. Obviously, the big mystery is scalability which is the main „pros and cons“ Vaadin battle. The question is, is Vaadin capable of satisfying the needs of an application that requires thousand of concurrent active users.

1. Mit o Vaadin
skalabilnosti
Gordan
Ivanović
IGEA – IN2 Grupa

2. Sadržaj
 O Vaadinu
 Motivacija testiranja
 Što smo i kako testirali
 Rezultati
 Zaključak
12.05.2014. IGEA – IN2 Group 2

3. Ukratko o Vaadinu
 Framework za razvoj rich web aplikacija
 Server-side i client-side
 Orijentiran na server-side
12.05.2014. IGEA – IN2 Group 3

4. Prednosti
 Kratka krivulja učenja
 Čist kod
 Lagan za održavanje
 Server-side orijentiran
 Nema borbe s mnogobrojnim klijentskim tehnologijama
 Bolji fokus na implementaciju poslovnih procesa
 Proširiv
 Dobro se integrira s drugim tehnologijama
 …
12.05.2014. IGEA – IN2 Group 4

5. Mane
 Server-side orijentiran
 Client-side razvoj
 Velika količina generiranog HTML koda
 Performanse??
 Skalabilnost??
12.05.2014. IGEA – IN2 Group 5

6. Testiranje Vaadin tima
 Web aplikacija za kupovinu kino karata (QuickTickets)
 Vaadin 6
 Vaadin zadovoljio (premašio?) očekivanja
 Može podnijeti veliko opterećenje
 Jedan server može podnijeti kupovinu kino karata za cijeli SAD i
Kanadu (Vaadin polu-šala)
12.05.2014. IGEA – IN2 Group 6

7. Motivacija za novo testiranje
 Vaadin 7
 Aplikacija za kupovinu kino karata je relativno light-
weight po pitanju količine interakcije usera/klijenta s
aplikacijom/serverom
 Testiran samo jedan scenarij
 Još uvijek skalabilnost glavni razlog za nekorištenje
Vaadina
 Jedno od rijetkih (jedino?) istraživanje Vaadin
skalabilnosti dostupno na webu
 Postoje usporedbe s drugim tehnologijama – nije cilj ovog
testiranja
12.05.2014. IGEA – IN2 Group 7

8. Što testiramo
 Implementirali smo jednostavan use-case
 Javni adresar stanovnika po državama i kontinentima
 Cilj nije bio stvoriti potpuno realan use-case po pitanju
tržišne potražnje već simulirati kompliciraniju (enterprise)
web aplikaciju
 Veći broj raznolikih AJAX requestova
 Veće opterećenje na server
 Veće opterećenje na bazu
 Teže skalirati
12.05.2014. IGEA – IN2 Group 8

9. Implementacija i izvedba
 Vaadin aplikacija u integraciji sa Springom
 Dvije verzije aplikacije:
a) Sve komponente su immediate
b) Nijedna komponenta nije immediate
 Nismo koristili cacheiranje
 Amazon Cloud
 2 large instance za aplikacijske servere
 2 large instance za JMeter
 1 large instanca za bazu (Postgresql)
12.05.2014. IGEA – IN2 Group 9

10. Implementacija i izvedba - JMeter
 JMeter
 Četiri korisnička scenarija
 Svaki snimljen posebno za pojedinu verziju aplikacije
 U scenarijima implementirana kašnjenja– trajanje scenarija cca 3
minute
 Na svakoj instanci pokrenuta 3 scenarija koja su gađala isti
server
12.05.2014. IGEA – IN2 Group 10

11. Implementacija i izvedba – JMeter
scenariji
 Tri scenarija koja simuliraju kompliciranije(realnije)
slučajeve korištenja
 Pretraživanje + unos jedne osobe u bazu + unos jedne adrese u
bazu + minimalno grešaka pri unosima
 Pretraživanje + unos jedne osobe u bazu + unos jedne adrese u
bazu + puno grešaka pri unosima
 Pretraživanje + unos tri adrese u bazu + malo grešaka pri unosu
12.05.2014. IGEA – IN2 Group 11

12. Implementacija i izvedba – JMeter
scenariji
 „Dodatni” scenarij - samo unošenje podataka u polja bez
perzistiranja u bazu
 Odlazaka na bazu ima za potrebe punjenja padajućih izbornika
 Nije puštan u kombinaciji s ostalima već sam za sebe
 Prema broju odlazaka na bazu sličan Vaadin testu skalabilnosti
 Razlozi ovog testiranja:
 Istraživanje utjecaja baze na rezultate prvih testova
 Veći fokus na client-server komunikaciju nego na cijelu aplikaciju
12.05.2014. IGEA – IN2 Group 12

13. Rezultati – kombinacija 3 immediate
scenarija
12.05.2014. IGEA – IN2 Group 13
Broj
korisnika
Pristiglo Ajax
requesta u
minuti
Obrađeno
average/peek Ajax
Request po minuti
Broj
servera
Median
(ms)
540 22860 9336/13441 1 13
1080 45720 10536/14285 1 208
1080 45720 10626/14421 2 38
2160 91440 13212/20641 2 59
4320 182880 11562/24441 2 1126
- Zadnje mjerenje pokazalo je loš odziv i povećan broj
grešaka > 1%

14. Rezultati – kombinacija 3
non-immediate scenarija
12.05.2014. IGEA – IN2 Group 14
Broj
korisnika
Pristiglo Ajax
requesta u
minuti
Obrađeno
average/peek Ajax
Request po minuti
Broj
servera
Median
(ms)
540 11520 5550/8643 1 21
1080 23040 8951/13548 1 33
2160 46080 8817/15206 1 317
2160 46080 10026/16680 2 175
4320 92160 13442/22631 2 265
- U zadnjem mjerenju prihvatljivo vrijeme odziva i prihvatljiv
broj grešaka < 1%

15. Rezultati – dodatni scenarij
12.05.2014. IGEA – IN2 Group 15
 Broj korisnika: 4800
 Broj pristiglih zahtjeva u minuti: 110400
 Prosječno obrađeno zahtjeva u minuti: 24006
 Peek obrađeno zahtjeva u minuti: 35014
 2 servera uz median vrijeme odziva 117ms

16. Zaključak
 Obrada zadovoljavajućeg broja AJAX requesta u minuti
 Kombinacija (kompliciranih) korisničkih scenarija i broja
korisnika daje zadovoljavajuće rezultate isto kao i
kontrolni scenarij
 Najveći problem kod (pre)velikog broja korisnika
predstavlja vrijeme odziva i broj odbijenih zahtijeva
 Činjenica da je u testovima baza u pojedinim trenutcima
postala usko grlo pokazuje da Vaadin dobro podnio
povećano opterećenje
 Testiranje je pokazalo da bi Vaadin zadovoljio potrebe
jedne bogatije aplikacije s prosječnim brojem (korisnika u
peek periodima korištenja)
12.05.2014. IGEA – IN2 Group 16

17. IGEA – IN2 Grupa