_{(*) Om voor veerkracht en hoge beschikbaarheid te zorgen, is elke transactie onmiddellijk naar de database geschreven. Er is geen data caching gebruikt.}

_{(**) De applicatie gebruikt XAP als een applicatieserver, in-memory Data Grid, messaging server en als ontwikkel framework}

Benchmark details

Om tot de eerdere hardware besparingscijfers te komen, zoals hierboven beschreven, zijn de volgende uitgangspunten gebruikt:

• De applicatie – een applicatie voor het handelen in aandelen met twee processtappen, validatie en vergelijking, uitgevoerd op een feed van koop en verkoopverzoeken. Het domein model bestaat uit een opdracht, een handels- en een aandelensymbool.
• De hardware – 1 Dual Core Intel(R) Xeon(R) X5260 CPU @ 3.33GHz, 64 bit, 4GB memory, met RH Linux.
• Één applicatie, twee middleware implementaties – XAP zorgt voor een transparente migratie voor applicaties met een traditionele architectuur. Dit maakte het mogelijk om het uitvoeren van precies dezelfde code met een traditionele architectuur tegenover XAP te plaatsen.
• De traditionele architectuur (zonder XAP) - in dit scenario draaide de applicatie op een populaire JEE applicatie server, gebruikmakend van JMS message broker en een MySQL database. Om betrouwbaarheid en hoge beschikbaarheid te bereiken werden alle transacties synchroon naar de database geschreven met een two-face commit. Er is geen data caching gebruikt
• De XAP-gebaseerde architectuur - in dit scenario maakte de applicatie gebruik van GigaSpaces XAP als applicatie server, message broker en In-Memory Data Grid (die onlosmakelijk makend transactioneel is). Veerkracht werd bereikt door alle gegevens in het interne geheugen te laden van de in-memory Data Grid. Alle transacties werden op de achtergrond naar een MySQL database weggeschreven om voor een100% data consistentie te zorgen.
• Benchmark procedure - de applicatie werd gekoppeld aan de traditionele architectuur met behulp van een Spring Framework configuratiebestand. Vervolgens is de applicatie overgezet op de hardware met de hierboven vermelde specificaties zodat het in staat was om een grote hoeveelheid gegevens te kunnen verwerken. Daarna werd de doorvoertijd en de gemiddelde latency gemeten. Vervolgens is een kopie van dezelfde applicatie gemaakt en werd deze gekoppeld aan GigaSpaces XAP met een ander Spring configuratiebestand, ingezet op dezelfde hardware machines en werden wederom de doorvoertijden en latency gemeten. Het uiteindelijke resultaat is het verschil in prestaties tussen de twee implementaties.
• Hoe is de 80% kostenbesparing op hardware berekend? De benchmark toonde een 500% performance verbetering aan. Dit zou betekenen dat de doorvoersnelheid 5 keer sneller is op dezelfde hardware. Maar het betekent ook dat dezelfde doorvoersnelheid met 1/5 van de hardware bereikt kan worden en dus een kostenbesparing van 80% oplevert. Voor een gedistribueerde applicatie betekent dit neerwaartse schaalbaarheid.

Nog meer benchmarks

Meer details over de hierboven beschreven JEE performance benchmark kunt u tezamen met de volgende benchmarks opvragen:

• Massive throughput for Java and .NET – GigaSpaces XAP demonstrated over 1 million read operations/sec. (1K payload) for both Java and .NET, on a single Sun4450 machine with Intel 7460 CPU and no special tuning.
• Low latency benchmark – XAP demonstrated 0.29ms latency for a remote call with an object containing 8 fields. For the same object, with synchronous replication to an in-memory backup, latency was only 0.69ms.
• High performance on multi-core – XAP demonstrated the ability to increase throughput up to 1,400,000 operations/sec., on a Sun T5240 Sparc machine.
• Web application performance – conducted on the classic ecommerce application example, Pet Clinic, running on commodity hardware and MySQL. XAP achieved 1.4 billion page views per day, with latency of only 6 ms.

Wilt u meer details over de financiële voordelen voor uw organisatie? Neem dan contact met ons op via het  contactformulier.