Onderwerp: Vmware performance

Ik heb op mijn windows pc een centos image.
Ik heb daar een hele webserver setup (php met xcache) draaien wat prima werkt.
Ook heb ik een windows directory geshared met mijn linux image.

Nu merk ik een groot verschil als ik mijn include path instel op het geimporteerde mapje, of een 'lokaal' mapje.
Het verschil is ruim factor 10. Nu maakt het script wel veel gebruik van bestanden op het path, dus er is vrij veel IO.
Dit wordt echter ook weer aardig afgevangen door xcache (wat gewoon werkt).

Hoe kan dit verschil zo groot zijn? Zijn de interne bestanden misschien allemaal al in het geheugen geladen?
Zo ja, kan ik dat ook doen op mijn live VPS?

Mijn geshared map staat op "vmhgfs".

Dus als ik het goed lees klaag je dat het VMware Host Guest FileSystem (vmhgfs) niet erg performant is?
Tja.. er zijn wel meer problemen met dat filesysteem, zoals diverse case sensitivity issues en unicode problemen, op zich sta ik daar niet raar van te kijken, het filesysteem is een beetje een "kludge". Het werkt redelijk, maar verwacht er nu geen wonderen van, er zitten nogal wat layers tussen.

Als je een betere performantie en betrouwbaarheid wilt dan is de consensus dat je beter het industry standard CIFS/SMB/Samba kan gebruiken ofwel een normale windows share en die dan vanuit linux met Samba benaderen.

Wila, ja dat klopt. Maar ik weet niet of het nou dus zo erg daaraan ligt, of dat dat normaal is.

Wat ik wil bereiken is dat mijn site sneller laadt. Ik heb een VPS die de bestanden op de SAN heeft staan. Als dat vergelijkbaar is dan valt er dus veel te winnen om die bestanden ergens anders op te slaan (geheugen ?).
Het vreemde is dus dat er dmv xcache al bestanden in het geheugen staan. Daarom vind ik het zo vreemd dat het zo'n groot verschil is. Het zal dat alleen het opzoeken van de bestanden zijn wat zo traag is, maar ik heb xcache op Stat = Off staan.
Kan iemand dit verklaren?

Verder is het ook mogelijk een soort van tmpfs partitie te hebben waar je alle bestanden van een deel van je disk mirrored in je geheugen?

Waarom sla je de bestanden niet gewoon op op de VPS ipv op de windows pc? Als je er vanaf de windows pc bij moet kan je op je vps bijv samba draaien om dat mogelijk te maken.

Tja, de vraag of dit nu echt aan vmhgfs ligt of ergens anders aan heb ik eigenlijk al beantwoord.
Weet ik dit zeker? Wel, ik mis echt ALLE technische achtergrond informatie (ik weet niet eens welk VMware product je gebruikt, welke versie, hardware setup etcetera.. ) maar omdat je spreekt over vmhgfs op een windows host is het iig duidelijk dat je spreekt over een van de desktop producten: VMware Workstation/Server of Player. Sharen via vmhgfs is NIET beschikbaar op het ESX/ESXi/vSphere platform.

Uiteindelijk maakt me je technische info in mindere mate uit omdat ik ontzettend veel klachten over de performantie van vmhgfs gezien heb door de jaren heen en dat is bijna altijd opgelost door naar of NFS of naar SMB over te stappen voor de sharing van de bestanden.

Hoe dat je setup op je hosting platform is snap ik dus niet helemaal, want daar zal je dit sharing mechanisme normaalgesproken niet hebben.

De vraag die overblijft is eigenlijk: "Hoe kan het filesystem iets uitmaken als alle bestanden gecached in het geheugen staan (dmv xcache)". IMHO zou dat dus niet uit moeten maken.
En maakt dat wel uit dan wil ik daar iets tegen doen, aangezien op mijn vps de IO ook niet optimaal is.

Helaas ken ik xcache niet echt goed, dus moet een aantal aannames maken.
Een van de aannames is dat ofschoon xcache je bestanden / opcodes cached, dat het voordat het de cache gebruikt toch nog altijd even gaat kijken ofdat het php bestand dat het gecached heeft nog het meest actieve bestand is. Ofwel je xcache gaat diverse aanroepen naar de windows API uitvoeren om te controleren ofdat de datum/tijd/bestandsgrootte e.d. nog allemaal hetzelfde zijn als wat in de cache zit. Omdat je bestanden zelf erg klein zullen zijn (we spreken tenslotte over php scripts) maakt het daadwerkelijke lezen ipv alleen de check of het up-to-date is eigenlijk bar weinig uit. Als de "is het bestand nog recent" check bijv. 100 milli seconden duurt en het daadwerkelijke lezen+omzetten naar opcodes slechts 10 millis, dan snap je dat je daadwerkelijke snelheidswinst elders te halen is. Om het zeker te weten zou je moeten gaan profilen, maar dan gaan we over iets heel anders praten.


Waar je dus naar zou kunnen zoeken is ofdat je xcache zijn "is de cache nog recent" checks uit kan zetten of naar een wat lagere frequentie kan instellen. Dus ipv "controleer iedere bestandsaanvraag" naar "controleer 1x/uur"

Na een snelle controle op de project pagina, heb ik het "natte vinger" gevoel dat je een beetje met de instellingen van de volgende twee variabelen zou kunnen spelen.
xcache.ttl seconds Ttl (Time To Live) value for the php entry (cached opcodes of a file), 0=forever.
xcache.gc_interval seconds Garbage collection interval.
--
Wil

Bestanden staan gewoon in de cachet hoor, en heb stat uitstaan dus dat mag het ook niet zijn.

Ook al staan je bestanden in de cache, dan zal je xcache op bepaalde momenten nog steeds gaan kijken ofdat dit inderdaad de laatste versie van je bestand is. De settings die ik aangaf zouden die gedrag kunnen beinvloeden (of niet, want ik heb geen ervaring met xcache, echter wel met VMware)

Je geeft zelf al aan dat je site 10x langzamer is bij gebruik van een HGFS file share, maar snapt niet waarom?
Ik geef je een uitleg dat het een trage (maar toch nuttige) feature is van het VMware desktop platform, dat is algemeen bekend. Hier is een recente post (Fusion in dit geval omdat dat het eerst naarboven kwam, maar het probleem is platform wijd)
Als je switched naar Samba, dan zal je zien dat je site plusminus 3x sneller wordt.

Ja "soms". Maar ik gebruik dit ding alleen om te testen. Uit de admin kan ik zien dat het gewoon in de cache staat.
Omdat stat uitstaat kijkt ie ook niet of een bestand er nog staat (ja alleen na gc tijd). Dit is ook makkelijk testen door de bestanden te verwijderen uit het fs.
Het blijft dan nog steeds werken.

Ik zal nog eens kijken of er niet wat andere filesystem calls zijn..