Linux vs Windows performance (Java server app)

maandag 21 februari 2005 10:53

Officieel moto fan :)

Sowieso moet je beginnen met het vergelijken van OS'en uit een vergelijkbare tijdsperiode - FC uit 2004, en Windows 2000 uit 1999 zijn natuurlijk niet gelijk qua releasedatum.

Begin dus even met Windows 2003 als platform te gebruiken. Verder is het met Windows 2003 zinvol om zowel met Windows 2003 Standard als Windows 2003 Enterprise te testen omdat ook deze qua performance kunnen verschillen (en lang niet altijd in voordeel van Enterprise)

Verder zal je een logische bottleneck moeten zoeken door middel van de standaard performance tools - waarom houdt je Linux server op bij 10,000 berichten, en waarom houd je Windows server op bij 5000 berichten. Is bij beide de CPU gelimiteerd? Is het een IO probleem?

Verder zal je verschillen moeten uitzoeken - gebruik je op beide platformen wel dezelfde JVM, gebruik je op Linux wel een journaling FS?

Dit zijn dingen die je eerst moet gaan uitzoeken alvorens je een verklaring hiervoor zal kunnen geven

[ Voor 8% gewijzigd door elevator op 21-02-2005 10:11 ]

Acties:

maandag 21 februari 2005 11:10

Je gebruikt op beide dezelfde JVM (versie) inderdaad? Dat is iets wat erg veel kan uitmaken.

Ook dezelfde hardware dus, inclusief hoeveelheid geheugen e.d.?

Ik voeg trouwens even aan de topictitel toe dat het over een Java applicatie gaat.

TrailBlazer: het is natuurlijk onzin dat je onder Windows niets te weten kunt komen over waar de bottlenecks zitten. Het lijkt mij ook erg interessant om te weten wat het verschil veroorzaakt

[ Voor 29% gewijzigd door Wilke op 21-02-2005 10:57 ]

Acties:

maandag 21 februari 2005 11:14

broer van Ron

Topicstarter

- Beide servers zijn 100% identieke Dell Servers en allebei zware jongens ( dual xeon, 2 GB intern, etc ).
- Inderdaad dezelfde versie van Java ( JRE 1.4.2 aangezien deze door Tibco zelf wordt aangeleverd en support .

Sowieso moet je beginnen met het vergelijken van OS'en uit een vergelijkbare tijdsperiode - FC uit 2004, en Windows 2000 uit 1999 zijn natuurlijk niet gelijk qua releasedatum.

Dit is een wens van mijn werkgever, onze klanten gebruiken Windows 2000 en niet Windows 2003.
Ook draaien er bij een aantal klanten al RedHat Enterprise servers ( vooral mail-server/firewall maar ook Oracle ). Zo ie zo kun je dit nooit mooi vergelijken want MS komt iedere 4 jaar uit met een nieuwe server-variant terwijl Linux constant met nieuwe distros/releases etc komt.

Ik weet niet hoe en wat jij getest hebt, maar als je postfix of sendmail tegenover Exchange zet ...

Het gaat hier dus puur om een back-end voor Tibco EAI/Middleware. Een zware JAVA applicatie die veel performance van systemen kan eisen wanneer er grote berichten moeten worden verwerkt. Er is genoeg ervaring bij ons bedrijf mbt het tunen van een Windows server voor Tibco ( services disablen, Virtueel geheugen instellen, disk-settings, registry tweaks, etc). Voor de Linux machine zijn alleen de noodzakelijke componenten van Fedora Core 2 geinstalleerd en is de Kernel 2.6.x gecompileerd voor deze hardware ( heb ik overigens niet zelf gedaan maar een van mijn vriendelijke linux-guru collegas ). Mijn Linux kennis beperkt zich helaas nog zover dat ik hier nog even niet aan wil beginnen op een belangrijk test-systeem. Gelukkig hebben mensen als "r3boot" een tijdje bij dezelfde klant gezeten als ik.

Het verschil vind ik echt opvallend, ik had eerlijk gezegd wel verwacht dat het wat kan schelen maar niet zoveel. Ik heb eens zitten kijken naar een pakket als SysStat om extra gegevens te kunnen krijgen uit je server tijdens de tests maar ik heb hier weer geen Win32 tegenhanger van. Eigenlijk zou ik het liefst een (open-source of minstens freeware ) applicatie hebben die uitgebreide logging heeft voor Linux en Windows.

[ Voor 7% gewijzigd door JeanJeremy op 21-02-2005 11:13 ]

Het is erg, maar het kan nog veel erger. Dus eigenlijk valt het reuze mee.

Acties:

maandag 21 februari 2005 11:17

Officieel moto fan :)

Nogmaals - zowel Linux (vmstat, iostat) als Windows (perfmon, kernrate) leveren een boel tools aan om inzicht te krijgen in problemen.

Je zal echter eerst eens bottlenecks moeten gaan bepalen om te zien waar je tegen de problemen aan loopt om vervolgens te gaan kijken waar het mis gaat

Verder - dat je klanten nu 2000 gebruiken betekent niet dat je daar nu nog testen mee moet uitvoere. Windows 2000 gaat binnenkort de extended lifecycle in en dan zal er vanuit jullie als leverancier uit toch naar een opvolger gekeken moeten gaan worden, dus waarom niet voorbereiden op de toekomst

Acties:

maandag 21 februari 2005 11:31

broer van Ron

Topicstarter

elevator schreef op maandag 21 februari 2005 @ 11:14:
Verder - dat je klanten nu 2000 gebruiken betekent niet dat je daar nu nog testen mee moet uitvoere. Windows 2000 gaat binnenkort de extended lifecycle in en dan zal er vanuit jullie als leverancier uit toch naar een opvolger gekeken moeten gaan worden, dus waarom niet voorbereiden op de toekomst

100% met je eens, maar het is gelukkig een afstudeer-opdracht waar ik dit als opdracht heb meegekregen. Dus ..... just doing my job as ordered

Het is erg, maar het kan nog veel erger. Dus eigenlijk valt het reuze mee.

Acties:

rapture

Zelfs daar netwerken?

Eenvoudig gezegd (niet bepaald wetenschappelijk verantwoord): Windows vreet de eerste 500MHz en 128MB ram op om een muiscursor te tonen. Windows is "eenheidsworst", het moet aan de eisen van alle klanten voldoen, dus er zit een hoop onnodige programma's op de achtergrond te draaien, zodat er weinig overblijft voor het echte werk. De Windows-kernel is een "fat-ass-variant" (zit veel te veel in) tov Linux-kernels die je netjes op maat compileerd.

Windows is een commercieel product, dus de programmeurs moeten tegen een deadline overhaast programmeren, hierdoor heeft men niet veel tijd om het boeltje te optimaliseren. Linux is open source, hier zijn er geen deadlines en iedereen die kan programmeren mag meehelpen.

bv Windows Sharing is closed source en werkt alleen op Windows-computers. Samba-mensen willen graag dat het onder Linux werkt en zitten alles op uit te proberen (reverse-enginering). Na 3 jaar tijd is Samba 2x zo snel als het origineel en kan 4x meer clients bedienen.

MS heeft door dat "eenheidsworst" en "fat-ass" niet goed voor servers zijn en Windows 2003 server is lekker kaal. Zodat je meer uit je server haalt, dus zeker eens testen met Windows 2003 server.

[ Voor 3% gewijzigd door rapture op 21-02-2005 11:33 ]

maandag 21 februari 2005 11:37

Acties:

maandag 21 februari 2005 11:54

Officieel moto fan :)

rapture schreef op maandag 21 februari 2005 @ 11:31:
De Windows-kernel is een "fat-ass-variant" (zit veel te veel in) tov Linux-kernels die je netjes op maat compileerd.

Ik mis de feiten in je betoog.

Acties:

CH4OS

It's a kind of magic

JeanJeremy schreef op maandag 21 februari 2005 @ 11:10:
Dit is een wens van mijn werkgever, onze klanten gebruiken Windows 2000 en niet Windows 2003.
Ook draaien er bij een aantal klanten al RedHat Enterprise servers ( vooral mail-server/firewall maar ook Oracle ). Zo ie zo kun je dit nooit mooi vergelijken want MS komt iedere 4 jaar uit met een nieuwe server-variant terwijl Linux constant met nieuwe distros/releases etc komt.

Wat weerrhoud je, om dan een Linux-(kernel)versie te zoeken, die qua release date (bijna) hetzelfde is, als die van MS Windows?

Als er toch constant nieuwe Linux-distro's uitkomen, zal er echt wel eentje zijn, die een release date heeft, die (bijna) identiek is aan die van Windows 2000...

JeanJeremy schreef op maandag 21 februari 2005 @ 11:17:
100% met je eens, maar het is gelukkig een afstudeer-opdracht waar ik dit als opdracht heb meegekregen. Dus ..... just doing my job as ordered

Dus als iets niet goed gaat, vraag je niet of je het anders kan / mag doen, want het is niet de opdracht?

Vind ik wel erg krom als ik eerlijk ben...

[ Voor 24% gewijzigd door CH4OS op 21-02-2005 12:32 ]

maandag 21 februari 2005 11:55

Acties:

dawuss

gadgeteer

Misschien kun je wat meer aangeven over wat het precies voor load is die je applicatie veroorzaakt? Heeft het heel veel disk of netwerk i/o? Of hangt het juist vooral veel multi-threaded te rekenen?
Mijn ervaring is namelijk dat Linux en BSD op het gebied van caching echt met kop en schouders boven Windows uit steekt, mits er voldoende RAM aanwezig is natuurlijk.

micheljansen.org
Fulltime Verslaafde Commandline Fetisjist ©

maandag 21 februari 2005 13:06

Acties:

maandag 21 februari 2005 13:24

rapture schreef op maandag 21 februari 2005 @ 11:31:
Eenvoudig gezegd (niet bepaald wetenschappelijk verantwoord): Windows vreet de eerste 500MHz en 128MB ram op om een muiscursor te tonen. Windows is "eenheidsworst", het moet aan de eisen van alle klanten voldoen, dus er zit een hoop onnodige programma's op de achtergrond te draaien, zodat er weinig overblijft voor het echte werk. De Windows-kernel is een "fat-ass-variant" (zit veel te veel in) tov Linux-kernels die je netjes op maat compileerd.

Als je het topic goed had gelezen, had je kunnen zien dat de topicstarter dus alle onnodige services e.d. uit heeft gezet. Wat nog wel draait zal - net als onder linux - echt niet zoveel uitmaken dat dit 50% verschil kan verklaren.

De Windows-kernel vergelijking slaat nergens op: de NT-kernel is een micro-kernel waar dus juist vrij weinig in zit, terwijl Linux-kernels monolithic zijn en dus juist de 'fat-ass' variant. Het 'netjes op maat gecompileerd' heeft ook vrijwel geen invloed, een modulaire kernel is niet merkbaar trager op welk gebied dan ook. Dit zijn argumenten die niet alleen geen hout snijden, maar ook nog eens gewoon domweg niet waar zijn.

Op deze manier ga je het verschil niet verklaren. Het zal inderdaad zo zijn dat Linux op een punt iets behoorlijk goed loopt te doen terwijl Windows loopt te zuigen (blijkbaar), maar het punt van discussie in dit topic is dus waar dat 'm in zit, en onzinnige vergelijkingen over grote/kleine kernels (die dan ook nog verkeerd om worden gemaakt) en het gebruik van 500 MHz voor het verplaatsen van de muiscursor vallen niet in de categorie 'zinvolle discussie' wat mij betreft.

Windows is een commercieel product, dus de programmeurs moeten tegen een deadline overhaast programmeren, hierdoor heeft men niet veel tijd om het boeltje te optimaliseren. Linux is open source, hier zijn er geen deadlines en iedereen die kan programmeren mag meehelpen.

Blaat, kan zo zijn, is misschien waar, misschien niet, whatever....maar zoals je in de topicstart ziet staan willen we dus graag een wetenschappelijke, dus aanwijsbare verklaring van waar dan precies het verschil zit. Dus geen zweverig verhaaltje over hoe geweldig Open Source wel niet is en waarom Closed Source zuigt.

Het kan allemaal waar zijn (of niet - daarover hier geen discussie aub), maar zweverige verhaaltjes gaan het verschil niet maken in een verslag waarin je wilt verklaren waar het hem nou precies in zit.

Sorry dat ik even zo uitval (vat het niet persoonlijk op vooral), maar ik haat het ook als Microsoft fanboys hetzelfde doen in omgekeerde richting (namelijk flamen of dingen als 'feit' presenteren die domweg niet waar zijn)- dus dan moet je ook consequent zijn.

Acties:

maandag 21 februari 2005 13:32

Ik bedoel dus dit:

Als er uit was gekomen dat Windows 2x zo snel was, dan zou je ook naar technische redenen zoeken waarom Linux zo traag is (bv. misschien zit er hardware bij die niet goed ondersteund wordt), en je niet verschuilen achter verhaaltjes over Open source etc. Dat zijn gewoon niet zulke zinvolle discussies.

Nu Linux 2x zo snel is, wil je dus ook graag weten door welk onderdeel dit precies veroorzaakt wordt. Dus: welk onderdeel van Linux doet het zo veel beter dan het vergelijkbare onderdeel in Windows?

Daarom is het inderdaad belangrijk om te weten wat momenteel de bottleneck is, op beide OS'en. Is het netwerkverkeer, belasting van de PCI-bus, i/o naar harddisks, of staan beide CPU's continu op 100% en is i/o geen probleem?
Welk filesystem gebruikt Linux, wordt er veel naar bestanden geschreven/gelezen, zijn er veel hele kleine bestanden of juist een paar grote, is alles dynamisch berekend (CPU-bound?) of is het gewoon domweg data laden en overpompen, etc.

Ik weet niet zo goed wat deze java-applicatie doet, dus vandaar dat topicstarter toch eerst zelf informatie in die richting zal moeten zien te krijgen

offtopic:
Ook ik vind het erg grappig dat Linux zonder veel fine-tuning dus blijkbaar behoorlijk wint in dit geval, maar het vinden van een concrete verklaring is lastig zonder meer informatie.

Acties:

Stewie!

Keen must die!

JeanJeremy schreef op maandag 21 februari 2005 @ 11:17:
[...]

100% met je eens, maar het is gelukkig een afstudeer-opdracht waar ik dit als opdracht heb meegekregen. Dus ..... just doing my job as ordered

En als je naast win2k en linux ook win2k3 meeneemt in de test en het verschil laat zien tussen die twee windows versies, denk je niet dat je op zo'n manier een computer nitwit beter overtuigt? Je kan hem ook voorstellen Linux RedHat 5 te installeren en daarop te testen en vergelijken met Windows 2000, ik denk dat er dan wel een belletje gaat rinkelen

Marathon loper in Tokyo, London, Rotterdam, Maria Alm, San Francisco, Berlin, Chicago, Amsterdam
Strava: https://www.strava.com/athletes/149347154

maandag 21 februari 2005 13:35

Acties:

maandag 21 februari 2005 17:39

broer van Ron

Topicstarter

Dus als iets niet goed gaat, vraag je niet of je het anders kan / mag doen, want het is niet de opdracht? Vind ik wel erg krom als ik eerlijk ben...

Zelf zou ik het nog veel liever testen met een Solaris machine en/of Unix, maar mijn opdrachtgever volstond met een Windows 2000 vs Linux. Verder hebben wij ervaring met Windows 2000 mbt de Middleware back-end applicaties.

ik ben nu bezig met vmstat en kernrate te kijken wat er precies op de achtergrond gebeurd tijdens een flinke load.

off-topic maar misschien interessant:
Ik begrijp dat voor veel mensen Middleware / EAI niet echt bekend is dus laat ik het ff snel uitleggen:
EAI is Enterprise Application Integration wat als doel heeft om verschillende applicaties/databases met elkaar te laten praten. Door middel van adapters en een BUS (seperaat netwerk) kunnen servers met elkaar communiceren. Bijvoorbeeld: Oracle database X krijgt een aanpassing aan een klant, via de BUS wordt deze aanpassing rondgegooid naar alle andere servers. De overige adapters kijken of ze deze info nodig hebben en zo ja dan pikken ze dit op en verwerken ze deze gegevens. Bijvoorbeeld SAP-server Y zegt: dit is interessant, en Siebel database Z zegt ... niet interessant. Wanneer je een flink groot bedrijf hebt zal dit dus leiden tot ENORM veel dataverkeer via UDP ( het zijn tenslotte broadcasts) op je BUS. Om ervoor te zorgen dat geen gegevens verloren gaan is het zaak dat de Middleware componenten zo snel mogelijk hun berichten verwerken.
Eventueel kun je via speciale RAD-tools zelf intelligentie toevoegen op een server die aan de BUS hangt. Hiermee kun je mbv Java-code zo uitgebreid te werk gaan als je wilt, simpele berichten opgooien tot complete applictaties bouwen.

[ Voor 15% gewijzigd door JeanJeremy op 21-02-2005 13:39 ]

Het is erg, maar het kan nog veel erger. Dus eigenlijk valt het reuze mee.

Acties:

Paultje3181

Eerlijk gezegd vind ik die opmerking over, ga eens OS'en vergelijken van dezelfde periode beetje loos... Ik neem aan dat je voor je win2000 wel alle updates mag gebruiken? Waarom dan niet voor linux... Dus pak een redhat 7.x en update die... Dan krijg je dus een 2.6 kernel, nieuwste java, nieuwste alles... Hetzelfde dus als wanneer je een Fedora Core 3 pakt met standaard een 2.6 kernel. Het feit dat windows de kernel niet/nauwelijks update en Linux wel moet niet de reden zijn dat de test niet zinvol is...
Oke als je de installatie en grafische dingen vergelijkt: oke, dan gaat dit op, maar voor server-doeleinden niet... Een gloednieuwe KDE 3.3 ziet er beter uit dan een win 3.11, maar de server-applicaties kunnen best vergeleken worden vind ik...

On-topic: weinig te zeggen, ik weet er te weinig vanaf

Sorry...

maandag 21 februari 2005 17:56

Acties:

dinsdag 22 februari 2005 09:34

We wachten dus tot de topicstarter met meer informatie komt over gebruikte filesystems en andere informatie waar om is gevraagd

Tot die tijd is er weinig zinnigs over te zeggen denk ik.

Acties:

TrailBlazer

Karnemelk FTW

Wilke schreef op maandag 21 februari 2005 @ 10:53:
Je gebruikt op beide dezelfde JVM (versie) inderdaad? Dat is iets wat erg veel kan uitmaken.

Ook dezelfde hardware dus, inclusief hoeveelheid geheugen e.d.?

Ik voeg trouwens even aan de topictitel toe dat het over een Java applicatie gaat.

TrailBlazer: het is natuurlijk onzin dat je onder Windows niets te weten kunt komen over waar de bottlenecks zitten. Het lijkt mij ook erg interessant om te weten wat het verschil veroorzaakt

nee ik bedoel ook niet dat je de bottlenecks niet kan aangeven, maar dat je niet kan aangeven waardoor die bottleneck ontstaat. Als de IO minder is is het natuurlijk makkelijk te zeggen de IO code is minder mij Microsoft maar of je daar verder mee komt

dinsdag 22 februari 2005 12:25

Acties:

dinsdag 22 februari 2005 12:54

broer van Ron

Topicstarter

Filesysteem
W2k = NTFS op C (system) en D (applicaties)
Linux = EXT3 filesystem met aparte partitie voor /OPT waar applicaties staan

Net wat loggings van Perfmon en VMstat zitten bekijken.
Beide loggings zijn op weinig plekken (Linux haalt wel nog een klein beetje hogere User Time ) anders op 1 uitzondering na: context switches/sec

De Linux server heeft in idle mode zo'n 190 en full load 8000 switches/sec
De Windows heeft in idle mode zo'n 375 en full load bijna 25.000 switches/sec

A context switch occurs when the kernel switches the processor from one thread to another—for example, when a thread with a higher priority than the running thread becomes ready. Context switching activity is important for several reasons. A program that monopolizes the processor lowers the rate of context switches because it does not allow much processor time for the other processes' threads. A high rate of context switching means that the processor is being shared repeatedly—for example, by many threads of equal priority. A high context-switch rate often indicates that there are too many threads competing for the processors on the system

Het klinkt inderdaad logisch dat er veel processen tegelijk gebruik willen maken van de CPU. Tenslotte komen er soms wel 10.000 berichten voorbij in een paar minuten die allemaal een apart process opstarten op de server. De Linux server heeft dus maar 50% van de tijd nodig om de gegevens te verwerken en ook maar 33% van de context switches.

Zou dit kunnen zijn dat Linux beter omgaat met het behandelen van meerdere processen of het beter gebruik maken van de dual-cpu die in de machine zit. Ook hebben de servers HyperThreading aanstaan dus het systeem kan dit zien als 4 CPU's.

Het is erg, maar het kan nog veel erger. Dus eigenlijk valt het reuze mee.

Acties:

dinsdag 22 februari 2005 13:07

Dit is informatie waar je iets aan hebt $_/-\o_$

In Windows is het starten van processen (relatief) duur. In Linux is dit juist heel goedkoop - dat moet ook wel, aangezien de hele filosofie van UNIX (en dus Linux) is: 'do one task, and do it well' - dat wil zeggen maak kleine programma's die heel goed zijn in 1 specifiek ding, en combineer die met elkaar om iets ingewikkelds te maken. Dat wil dus zeggen: veel processen starten.

Het schijnt dat in Windows het maken van threads relatief goedkoop is t.o.v. Linux, maar ook dat is iets waar recentelijk heftig aan gewerkt is in Linux. Interessant om te weten is daarom welke kernel versie je precies draait in Linux. Ook is het zoals Elevator zegt wel degelijk interessant om het eens in Windows 2003 te proberen - al is het maar om gewoon te weten of het iets uitmaakt. Als jullie een MSDN-subscription hebben zou je dat zonder (verdere) kosten wel moeten kunnen testen.

Verder is het misschien interessant om te zien wat de applicatie doet: start die veel threads binnen 1 proces, of juist heel veel processen die min-of-meer onafhankelijk van elkaar zijn? Als je in Windows voor elk request een proces gaat maken, kan ik je wel verzekeren dat dat niet optimaal is in ieder geval - ik neem dan ook niet aan dat ze zo stom zouden zijn om dit te doen eerlijk gezegd.

Voor de rest: mogelijk scheduled linux slimmer dan Windows 2000, en/of - wat zeker een mogelijk is - Linux kiest voor een grotere latency gecombineerd met een hogere througput. Dat wil zeggen: elk request op zich duurt wat langer, maar daardoor kun je er wel meer afhandelen in dezelfde tijd (langere timeslices zouden hiertoe kunnen leiden - minder context switches, maar gemiddeld wat langere wachttijden).

Overigens kan ik me voorstellen dat Windows 2000 niet zo veel kan met HT, aangezien win2k (bij mijn weten) van voor de tijd van HT is. Daar zou het ook (deels) aan kunnen liggen.

[ Voor 19% gewijzigd door Wilke op 22-02-2005 12:59 ]

Acties:

_JGC_

Verder hoop ik dat de RHEL versie die jullie willen gaan gebruiken ook NPTL en een 2.6 kernel heeft, grote kans dat die dat niet hebben (je had beter met White Box linux kunnen testen, is de SRPMs van RHEL ontdaan van Redhat branding en als installeerbaar iets aangeboden). Sinds kernel 2.6 en de NPTL threading code is linux enorm vooruitgegaan in threading, wat je voornamelijk kunt merken bij Sun's JAVA.
Je zou de test op linux nog eens kunnen herhalen:
export LD_ASSUME_KERNEL=2.4.1
vervolgens je test herhalen om zonder NPTL, met i686 geoptimaliseerde glibc te proberen.
export LD_ASSUME_KERNEL=2.2.5
vervolgens je test herhalen om zonder NPTL met generic glibc te proberen.

Ik denk dat je bij 2.4.1 al een enorme terugval in prestaties ziet, waarbij 2.2.5 er nog een stapje onder gaat zitten (zij het niet zo'n groot verschil als met je vorige test en 2.4.1).
Die export regels doe je voor je je java applicatie start.

De Sun JDK is enorm aangepast aan NPTL en kan soms 100% sneller zijn in threading code met NPTL vergeleken met de situatie zonder NPTL. Ik heb ooit vergelijkingen gezien van JDK 1.4 van zowel IBM als Sun, waarbij sun met een bijna-100% verschil zat, terwijl de JDK van IBM het geen donder uitmaakte (IBM JDK was in de 1.3/1.4 tijden sowieso al stukken sneller en kleiner in geheugenomvang dan die van Sun, met 1.5 doen ze echter niet echt meer mee)

dinsdag 22 februari 2005 13:46

Acties:

dinsdag 22 februari 2005 14:22

Officieel moto fan :)

JeanJeremy schreef op dinsdag 22 februari 2005 @ 12:25:
Zou dit kunnen zijn dat Linux beter omgaat met het behandelen van meerdere processen of het beter gebruik maken van de dual-cpu die in de machine zit. Ook hebben de servers HyperThreading aanstaan dus het systeem kan dit zien als 4 CPU's.

Probeer inderdaad eens HT af te zetten op Windows 2000 aangezien dat niet altijd even goed ondersteund wordt

Verder zijn processen op Windows veel duurder dan op Linux (test bv. maar eens een CGI op Windows en een CGI op Linux en je zal het verschil zien), dus dat is ook een stuk architectuur die dan schijnbaar niet juist geschreven is voor Windows

Acties:

Bas!

Hmm meneer jgc, ik geloof niet dat de topicstarter op zoek is naar welk os het snelst is, maar meer waarom linux beter presteert dan windows.
Dan heeft de persoon meer aan elevators post over bottleneck bepaling. Probleem is alleen dat het een beetje appels met peren vergelijken blijft aangezien linux behoorlijk andere io en cpu scheduler uitgangspunten heeft naar ik me kan herinneren en de meeteenheden waarschijnlijk nooit 1 op 1 vergelijkbaar zijn.
Het is moeilijk om te bepalen wat de defacto linux performance is, zoals jgc dan eigenlijk weer aangeeft. Ander filesystem, andere io scheduler, andere threading (er zijn nu geloof ik drie grote lib pthread verhalen) en cpu schedulers.
Je mag dus blij zijn dat windows achter blijft.

dinsdag 22 februari 2005 14:43

Acties:

_JGC_

Bas! schreef op dinsdag 22 februari 2005 @ 14:22:
Hmm meneer jgc, ik geloof niet dat de topicstarter op zoek is naar welk os het snelst is, maar meer waarom linux beter presteert dan windows.
Dan heeft de persoon meer aan elevators post over bottleneck bepaling. Probleem is alleen dat het een beetje appels met peren vergelijken blijft aangezien linux behoorlijk andere io en cpu scheduler uitgangspunten heeft naar ik me kan herinneren en de meeteenheden waarschijnlijk nooit 1 op 1 vergelijkbaar zijn.
Het is moeilijk om te bepalen wat de defacto linux performance is, zoals jgc dan eigenlijk weer aangeeft. Ander filesystem, andere io scheduler, andere threading (er zijn nu geloof ik drie grote lib pthread verhalen) en cpu schedulers.
Je mag dus blij zijn dat windows achter blijft.

Mja, waar ik hem op wil wijzen is dat linux niet per se sneller hoeft te zijn dan windows. RHEL 3 is al een oud stuk software wat de nodige jaren meegaat, daar heb je RHEL voor. Fedora is een bleeding edge desktop distro die ik persoonlijk ook nergens anders voor zou gebruiken.
Java 1.5 is enorm geoptimaliseerd voor NPTL de laatste tijd, waar ik dus het verschil in performance in zoek. Probeer het zonder NPTL (die LD_ASSUME_KERNEL dingen zetten NPTL aan of uit omdat de linker niet met de NPTL libs wil werken als de setting op bepaalde waarden staat) en je zult zien dat linux ineens gelijk of achter met windows loopt.

Voor linux zijn er overigens 3 thread implementaties: linuxthreads, NPTL en NGPT. NGPT is destijds ontworpen als threadlib voor glibc 2.2.x, maar is nooit doorontwikkeld omdat de glibc ontwikkelaars meer heil zagen in NPTL (wat toevallig ook door een van de hoofd developers, Ulrich Drepper, is bedacht)

dinsdag 22 februari 2005 14:44

Acties:

dinsdag 22 februari 2005 19:57

broer van Ron

Topicstarter

Zojuist wat tests gedraaid met de W2000 server zonder HyperThreading.
The Context Switches per sec. gaan inderdaad omlaag naar ongeveer 19000 ( voorheen 25000 ) maar dit is nog steeds aanzienlijk hoger dan Linux ( met HyperThreading enabled ). Morgen wil ik nog tests gaan doen met HyperThreading disabled op de Linux server maar vermoed dat dit niet uit mag maken omdat de 2.6 kernel hier wel mee om zou moeten gaan.

Verder heeft dit weinig effect op de performance van de server. Sterken nog, voorheen kon deze 10.000 berichten afhandelen tussen de 54 en 64 seconde en de eerste test runs zitten nu rond de 67-68 sec. Dus CS/sec gaan omlaag maar performance ook ... mmmmm

update
Ook even een test gedraait op de Linux serverr, met de export LD_ASSUME_KERNEL=2.4.1.
De Context switches/sec van de linux server gaan ineens drastisch omlaag, tijdens de verwerking van 10.000 files zit deze rond de 1250 per sec. Terwijl dit voorheen 8000 was. Wat wel zo is is dat de duur van de test ineens van een gemiddelde 33 seconde naar 1minuut 30 knalde. Dus minder context switches/lagere performance. (again, ik zie een patroon jullie ook ?

)

Vreemd eigenlijk want mijn verwachtingen waren dat doordat de context/switching omlaag ging, de processer makkelijker de kleine taken kon afhandelen en sneller klaar zou zijn met de 10.000 berichten.

Overigens, op de server draait 1 process wat eigenlijk de Engine is van Tibco ( Business Works Engine ) waar op dus alle 10.000 "processen" op worden gestart. Het is dus niet zo dat er op een server ineens 10.000 nieuwe processen bijkomen.

[ Voor 43% gewijzigd door JeanJeremy op 22-02-2005 15:34 ]

Het is erg, maar het kan nog veel erger. Dus eigenlijk valt het reuze mee.

Acties:

mOrPhie

❤️❤️❤️❤️🤍

Om even een duit in het zakje te doen: Wellicht is het een idee om 'ns te kijken of er een verschil is in performance van Java tussen windows en linux machines en dan of dit overéén komt met jouw Tibco-tests. Je zou dit kunnen doen door een paar andere (stuk of 4 a 5?) java-applicaties te pakken en hier de performance van te meten. Blijkt dat onwillekeurig linux danwel windows sneller is, dan kun je de java-implementatie (in dit geval JRE 1.4.2) van beide OS'en in elk geval niet de schuld geven. Blijkt dat in de meeste/alle gevallen de java-applicaties onder linux sneller draaien, dan zou je kunnen stellen dat Java onder linux sneller is. In dat geval kijk je niet zo zeer naar het OS, maar naar de implementatie zelf; Misschien wel, dat het unix-team bij sun beter hun best heeft gedaan dan het windows-team, om maar 'ns iets te zeggen.

Kijk alleen wel uit met java-GUI-applicaties. Deze kan (zeker in linux naar verluid) een vertragende factor zijn.

Deze informatie lijkt mij nuttig om te weten bij het lokaliseren van de reden.

Een experimentele community-site: https://technobabblenerdtalk.nl/. DM voor invite code.

dinsdag 22 februari 2005 20:59

Acties:

Mars Warrior

Earth, the final frontier

Ik kwam toevallig een stukje tegen uit 2002 (tja, oud...) over (Java) performance testen tussen Linux en Windows uitgevoerd door TMC:

TMC tested both WebSphere and WebLogic on both Windows 2000 and RedHat Linux 7.2. TMC found that WebLogic performed "noticeably" better on Windows. For WebSphere, TMC found that the operating system made no difference to performance. To simplify the benchmarks, TMC used Windows for WebSphere as well.

Blijkbaar kan de implementatie van de App server veel uitmaken of het op een van de twee beter draait, dus denk dat dit (performance van JRE) inderdaad wel een punt is om uit te zoeken voordat je iets zinnigs kunt zeggen

En wat ik wel weet is dat exception handling onder Windows veel meer CPU tijd kost (reden mij onbekend) dan onder Linux. Dus als een applicatie veel van exceptions gebruik maakt (bijv. bij het opbouwen van netwerk verbindingen) dan is deze onder Windows trager...

Moet je maar een shet volgede proberen:

code:

1 2	try { float f = Float.parseFloat(str); } catch (NumberFormatException ex) {}

En dan natuurlijk met een geldige float str en een ongeldige...
Als mijn ervaring op jouw systemen ook klopt (Windows veel trager dan Linux) dan kan het dus zijn dat jullie applicatie veel op exceptions vertrouwd ipv via een if() dingen te testen, en dat dit een van de redenen kan zijn dat Windows trager is dan Linux...

[ Voor 39% gewijzigd door Mars Warrior op 22-02-2005 21:39 ]

Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs

donderdag 19 mei 2005 13:26

Acties:

donderdag 19 mei 2005 13:49

broer van Ron

Topicstarter

Even nog een late update, het topic is al wat ouder maar als TS wil ik jullie dit niet onthouden.:P

Mijn onderzoek is bijna voltooid ( nog 2 weken ) maar na veel ge-test en ge-lees ben ik erachter dat een groot deel van de performance winst op Linux in DIT geval !!!!!!!!!! ontstond doordat de Linux Scheduler veel beter om kan gaan met een groot aantal Threads ( +10.000 ) op een systeem dan de Windows variant. Windows 2000 Server heeft namelijk een statische timeslice wat betreft de tijd dat een thread aan de beurt komt, terwijl de Linux O(1) Scheduler (sinds Kernel 2.5) een veel hogere intelligentie/algoritmes heeft om threads zo snel mogelijk af te handelen.

Hierdoor heeft de Linux server op momenten maar 10% van de Context Switches van de Windows server en dit geeft een grote performance winst in mijn geval.

Hier nog wat interessante links:
http://support.microsoft.com/?kbid=259025
http://www.oreilly.com/catalog/linuxkernel/chapter/ch10.html
http://www.iamexwi.unibe....ng/LinuxScheduling-1.html
http://www.samspublishing...article.asp?p=101760&rl=1

[ Voor 16% gewijzigd door JeanJeremy op 19-05-2005 13:28 ]

Het is erg, maar het kan nog veel erger. Dus eigenlijk valt het reuze mee.

Acties:

sampoo

elevator schreef op maandag 21 februari 2005 @ 11:14:
Nogmaals - zowel Linux (vmstat, iostat) als Windows (perfmon, kernrate) leveren een boel tools aan om inzicht te krijgen in problemen.

Je zal echter eerst eens bottlenecks moeten gaan bepalen om te zien waar je tegen de problemen aan loopt om vervolgens te gaan kijken waar het mis gaat

Verder - dat je klanten nu 2000 gebruiken betekent niet dat je daar nu nog testen mee moet uitvoere. Windows 2000 gaat binnenkort de extended lifecycle in en dan zal er vanuit jullie als leverancier uit toch naar een opvolger gekeken moeten gaan worden, dus waarom niet voorbereiden op de toekomst

Ik denk dat dit onderzoek onder andere een beweegredenen kan/moet verschaffen of een stap naar Linux niet net zo goede prestaties oplevert als de nu gebruikte Windows 2000. De klant heeft geen ervaring met Windows XP en kan zich niet zo goed inleven als bij Windows 2000 het geval is. Maar ik denk dat de meerkosten om ook een vergelijking met Windows XP te doen niet zo hoog zijn aangezien dat min of meer identiek is aan de Windows 2000 vergelijking. Verder wordt Windows 2000 aardig up-to-date gehouden en kan je het best vergelijken met een recente Linux OS.

donderdag 19 mei 2005 23:59

Acties:

vrijdag 20 mei 2005 00:16

broer van Ron

Topicstarter

Het onderzoek is inmiddels al afgerond hoor

En ik heb alleen Windows 2000 gechecked tegen een Linux installatie omdat dit de standaard was van de bedrijven waar wij zitten. Het beheer valt ook onder ons daar dus de klant zal het worst zijn of wij beheer doen op een Linux machine of op een w2k machine.

Waar het om gaat is dat we te veel ijzer nodig hebben met de W2K bakken en ook te veel incidenten krijgen met de software die niet 100% goed om kan gaan met hoge pieken op Windows. Te vaak memory foutmeldingen van het OS. Windows 2003 wil de klant toch niet, men is eerder geneigd om richting Unix / Linux te gaan en binnenkort zullen we de eerste Linux server inrichten. In eerste instantie op de Ontwikkel-omgeving maar we zullen zien

Het is erg, maar het kan nog veel erger. Dus eigenlijk valt het reuze mee.

Acties:

Stewie!

Keen must die!

JeanJeremy schreef op donderdag 19 mei 2005 @ 23:59:
Het onderzoek is inmiddels al afgerond hoor

En ik heb alleen Windows 2000 gechecked tegen een Linux installatie omdat dit de standaard was van de bedrijven waar wij zitten. Het beheer valt ook onder ons daar dus de klant zal het worst zijn of wij beheer doen op een Linux machine of op een w2k machine.

Waar het om gaat is dat we te veel ijzer nodig hebben met de W2K bakken en ook te veel incidenten krijgen met de software die niet 100% goed om kan gaan met hoge pieken op Windows. Te vaak memory foutmeldingen van het OS. Windows 2003 wil de klant toch niet, men is eerder geneigd om richting Unix / Linux te gaan en binnenkort zullen we de eerste Linux server inrichten. In eerste instantie op de Ontwikkel-omgeving maar we zullen zien

Heb je toen ook aangegeven dat de situatie onder windows 2003 heel anders kan zijn dan op windows 2000 maar dat dit niet getest is?

Je hebt toch ook geen 2.2 kernel gebruikt?

Ik bedoel: windows 2003 is onderusen toch behoorlijk volwassen OS

[ Voor 7% gewijzigd door Stewie! op 20-05-2005 00:20 ]

Marathon loper in Tokyo, London, Rotterdam, Maria Alm, San Francisco, Berlin, Chicago, Amsterdam
Strava: https://www.strava.com/athletes/149347154

vrijdag 20 mei 2005 01:22

Acties:

neh

DaMorpheus schreef op vrijdag 20 mei 2005 @ 00:16:
[...]
Heb je toen ook aangegeven dat de situatie onder windows 2003 heel anders kan zijn dan op windows 2000 maar dat dit niet getest is? Je hebt toch ook geen 2.2 kernel gebruikt?
Ik bedoel: windows 2003 is onderusen toch behoorlijk volwassen OS

Wat zou het doel daarvan zijn als meteen al duidelijk was dat windows 2003 geen optie was?

XT, 640K ram, 20 MB harddisk, MS-DOS 4.0...

vrijdag 20 mei 2005 01:36

Acties:

mOrPhie

❤️❤️❤️❤️🤍

Ik denk dat men uit moet kijken dit individuele resultaat, dat zich alleen spitst op de specialisatie "Java server applicaties", te gaan lezen als een overal performance vergelijking tussen windows en linux. Dat is simpelweg niet het geval. Zijn doel was het verschil in performance van java server applicaties op windows 2000 en linux 2.6 te vinden. Bij een overal performance zou je je ook niet alleen op java server applicaties richten.

Een experimentele community-site: https://technobabblenerdtalk.nl/. DM voor invite code.

vrijdag 20 mei 2005 02:09

Acties:

Stewie!

Keen must die!

plork schreef op vrijdag 20 mei 2005 @ 01:22:
[...]

Wat zou het doel daarvan zijn als meteen al duidelijk was dat windows 2003 geen optie was?

Aantonen dat het wel een optie was omdat het een x% beter presteert en dezelfde voordelen van windows 2000 heeft ten opzichte van linux?

Marathon loper in Tokyo, London, Rotterdam, Maria Alm, San Francisco, Berlin, Chicago, Amsterdam
Strava: https://www.strava.com/athletes/149347154

vrijdag 20 mei 2005 15:38

Acties: