Johdanto

Alla on kuvaus täysin riippumattomasta suorituskykytestistä Sun Sparcin ja Blade Linuxin välillä. Testin tulokset osoitavat selkeästi Linuxin suorituskyvyn ylivoimaisuuden vaativassa tuotantokäytössä. JRComplex Oy on valmis osoittamaan Open Source ratkaisuiden ylivoimaisen tehokkuuden myös sinun ympäristössäsi, ota yhteyttä !

1. Testilaitteet

Rauta:
- Sun Sparc Fire V240, 4GB RAM, 2x1,8GHz CPU, 1000 nic
- HP Intel Blade 20P G2, 2GB RAM, 2x3GHz CPU, 1000 nic

Softa:
- käyttöjärjestelmä Sun Solaris 9 ja RedHat Enterprise Linux ES
- preforkkaava apache 1.3.33, oma käännös
- php 4.3.x oma käännös
- php.ini ja apachen konffis molemmissa identtinen
- käyttiksessä Sun on viritetty tcp:n osalta. RedHat oli perustilassaan.

Rauta on kohtalaisen vertailukelpoista, sillä erotuksella, että Sunissa on muistia tuplaten Bladeen nähden, mikä ei pelastanut Sunia tässä testissä...

2. Mitä testattiin

Tätä testiä edelsi käytännön testi, jossa laitettiin vuorotellen kumpikin kone tuotantoon siten, että kaikki sisääntuleva php- liikenne ajettiin ko koneelle. Seurattiin tilannetta ja todettiin, että liikenne ei ollut riittävää erojen havaitsemiseksi, molemmat koneet selvisivät tästä testistä likimain samoilla tuloksilla.

Siirryttiin vaiheeseen b, jonka tarkoituksena oli tykittää koneita epäinhimillisellä kuormalla, jotta saataisiin eroja aikaan.

Vaihe b: Testattiin kokoonpanojen CPU/verkko/sovellustehot yhdellä kertaa kysymällä nilltä httperf- ohjelmalla yhtä php- tiedostoa apachen kautta seuraavilla parametreilla:

- luodaan 4000 sessiota vauhdilla 40 kpl/s
- jokainen sesssio koostuu 5 eri querystä, jotka tehdään 2 sekunnin välein

3. Testitulokset

Blade:
Total: connections 6000
requests 30000
replies 30000
test-duration 108.007 s

Request rate: 277.8 req/s (3.6 ms/req)
Reply rate [replies/s]: min 19.8 avg 283.4 max 467.6 stddev 101.4
Reply time [ms]: response 122.5 transfer 1.0
Net I/O: 4409.4 KB/s

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

Session rate [sess/s]: min 0.00 avg 55.55 max 102.21 stddev 24.21
Session lifetime [s]: 9.6

Connection rate: 55.6 conn/s (18.0 ms/conn, <=949 concurrent connections)
Connection time [ms]: min 8020.3 avg 9623.0 max 53030.6 median 8025.5 stddev 4090.0

Sun Fire:
Total: connections 5828
requests 29140
replies 29140
test-duration 116.278 s

Request rate: 250.6 req/s (4.0 ms/req)
Reply rate [replies/s]: min 16.8 avg 252.7 max 298.0 stddev 78.1 (23 samples)
Reply time [ms]: response 1802.8 transfer 37.1
Net I/O: 3970.1 KB/s

Errors: total 172 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 172 addrunavail 0 ftab-full 0 other 0

Session rate [sess/s]: min 0.00 avg 50.12 max 64.81 stddev 18.53
Session lifetime [s]: 17.2

Connection rate: 50.1 conn/s (20.0 ms/conn, <=1022 concurrent connections)
Connection time [ms]: min 8045.5 avg 17201.7 max 21928.2 median 17285.5 stddev 1168.3

CPU- load ja apachen child- prosessien määrä testin aikana max.

Blade: 1,55 / 820

Sparc: 46,49 / 596

Summa:

Blade suoriutui testistä 8s nopeammin, kuin Sun. Blade kykeni vastaamaan jokaiseen luotuun pyyntöön, eikä sen CPU load noussut missääin vaiheessa > 1.5. Bladessa oli parhaimmillaan > 800 apache child- prosessia.

Sun oli hitaampi, sen CPU load nousi > 40 eikä se kyennyt vastaamaan kaikkiin pyyntöihin, vaan missasi 172 clienttia. Sun kantoi parhaimmillaan reilut 500 apache childia.

Ero on Bladen hyväksi häikäisevä. Testi Sunille toistettiin siten, että samalla tarkkailtiin erillisellä Sunin performance- softalla, josko se kertoisi, miksi Sun hyytyy niin totaalisesti. Havaittiin, että Sun kestää about 500 apache childia, jonka jälkeen CPU- kuorma kasvaa sikamaiseksi. Blade kesti hienosti yli 800 childia minimaalisella kuormalla. Sunin performance tool ei testin aikana kertonut minkään muun alueen ongelmista, kuin CPU:n. Työkalu valvoo mm. Tcp- liikennettä, nfs:ää yms.

Historia kokemus tähän asti on osoittanut, että Sun kestää n. 500-600 apache childia ja sitten hyytyy totaalisesti. Tämä testi todisti teorian oikeaksi myös uuden Sun Firen osalta. Bladen antama yhtälö >800 apache childia kuormalla 1.5 on äärimmäisen hyvä. Oletus ennen testiä oli, että Blade hyytyy jopa ennen Sunia ;)

Testin tulos on sen verran yllättävä, että toistin sen vielä kertaalleen Bladelle siten, että käänsin itse samoilla optioilla php:n Bladeen, eikä se vaikuttanut tulokseen ollenkaan.

Samalla tuli testattua myös ero myös apache 1.3.x:n ja apache2:n ero, kun molemmissa käytettiin preforkkausta (apache2 prefork mpm). Ne olivat tasan samanlaiset.

4. Jälkikommentit

Vaikka tätä testiä pyörittelisi mitenpäin, ei sitä tulosta saa muutettua ja toistin testin monta kertaa ja varmistin, että kaikki käännökset ja konffikset on identtiset. Lisäksi varmistin tosiaankin, että Sun ei hytyynyt mihinkään muuhun juttuun, esim. nfs- tms. vaan kyllä se väsähti ihan totaalisesti CPU:n osalta.

Ei tämän jälkeen oikein voi perustella itselleen mitenkään, miksi kannattaisi jatkaa Sunin kanssa, kun näitä rautoja aletaan uusia...

Tuo linux/balde- suorituskyky on kyllä aika super, en ole vuosien aikana koskaan nähnyt, että yksikään meidän Sun olisi jaksanut enempää, kuin n. 600 apache childia kerrallaan ja olen pitänyt sitä sellasena maagisena lukemana...

Nyt bladessa oli vielä muistiakin vähemmän ja se jaksoi loistavasti. Kun tuumaa tuota testissa tullutta 800 childia 1.5 loadilla, niin siitä voi vetää hurjat päätelmät, mitä se oikeasti jaksaa ennen hyytymistään: testin aikana http:llä pyydettäessä blade vastasi samantien. Se voi kestää jotain 1500 childia, mikä on kyllä epäluonnollisen tehokasta...

Tämä siis on osoitus blade/linux- yhdistelmän php (=cpu)- performancesta ja osin myös yleispreformancesta. Jos jaksan jossain vaiheessa testata cachella vielä saman, niin näkee, mikä on ero, kun ei olekaan kyse cpu- voimista, vaan silkasta tcp- liikenteen kestokyvystä.

Testasin kaatumarajaa Sunin ja Liinuksin välillä httperfillä. Sun hyytyy tasolla 100 sessiota/s, Linux kestää n. 600 sessiota/s. Testissäni sessio=yhteys, jonka aikana tulee 5 pyyntöä 2 s välein.

5. Kritiikkiä ja kommentteja

Edellä olevaa testiä on SUN käyttäjien toimesta arvosteltu seuraavilla kommenteilla:

Apache palvelinta ei ollut käännetty SUNin kaupallisella CC kääntäjällä

Organisaatiolla, joka teki testin, ei ollut käytössään maksullista CC kääntäjää, eikä aikonut sellaista hankkia. SUN käyttäjät testasivat sfnet.atk.linux.palvelimet uutisryhmässä tulosten julkistamisen jälkeen Apachea CC ja GCC (3.4.2) kääntäjillä Solaris Sparc-alustalla. Lopputuloksena saatiin vain 5% ero CC:n hyväksi ja sekin vasta optimoinnin jälkeen. Linux käyttäjät/GCC-puoli ei tehnyt vastaavaa testiä
Ero kääntäjien välillä on täysin merkityksetön ja todennäköisesti kallistuu kumman kääntäjän hyväksi tahansa riippuen optimoinnista, testitilanteesta tai testiympäristöstä. Yhteenvetona voi siis sanoa, että kääntäjän merkitys tämäntyyppisessä suorituskykytestissä, jossa käytetään Open Source komponentteja on täysin marginaalinen, eikä selitä lopputulosta

Testissä ei ollut mukana SUNin kaupallista webserveriä

Organisaatiolla, joka teki testin ei ollut käytössään maksullista SUNin webserveriä, eikä aikonut sellaista hankkia. Apache oli testivaatimus

Käytetty kääntäjä (gcc 2.95.3) ei ollut uusin

Käytetty GCC versio saattoi vaikuttaa tämän testin tulosten lukuarvoihin, mutta kuten kohdan 1. perusteluista nähdään, ei kääntäjän vaihtamisella ole olennaista vaikutusta itse peruskysymykseen. Uusimman GCC:n käyttäminen vain todennäköisesti kallistaisi lopputulosta enemmän Linuxin suuntaan

Rauta oli erilainen

Tämä oli nimen omaan testin tarkoitus, eli laittaa Solaris Sparc Linux Bladea vastaan ja katsoa, kummalla on parempi suorituskyky

Testissä oli Solaris 9, eikä 10

Organisaatiolla, joka suoritti testin ei ollut käytössään uusinta Solaris 10:iä. Toisaalta Linuxistakin oli vanhempi RHES 3 versio, joka käyttää vielä vanhaa 2.4-sarjan kerneliä

Testi ei ollut riippumaton

Testi oli täysin riippumattoman organisaation SUNeja ylläpitävän henkilön tekemä

Testitilanne ja käytetyt komponentit määrittelivät jo ennalta tulosta

Testin suorittava organisaatio halusi suorittaa nimen omaan reaalimaailman testin, joka tapahtuu täysin siinä tilanteessa ja niillä komponenteilla, missä oikeassakin tuotannossa eletään. Testin tulos haluttiin nimen omaan olevan yhdistelmän: Käyttöjärjestelmä + rauta-alusta + komponentit vertailu

Takaisin etusivulle