[patrikweb]

Ett korrekt byggt SAN med rätt prestanda som inte är överbelastad kommer ha så liten skillnad i latency så att det inte kommer märkas.

Dock ett överbelastad SAN med hög I/O kommer sänka hela plattformen mer eller mindre. Finns inget värre seghet i ett system än hög I/O wait.

[Danielos]

Ursprungligen postat av johan1234

Då du verkar ha kört mycket tester - vad anser du är bäst? När det gäller Gluster har vi lärt oss en hel del - precis som du inte mycket på den positiva sidan.

När det gäller glusterfs så gäller det att köra väldigt många storage noder, men prestandan blir aldrig tillräcklig i samband med php-processer som så att säga hänger kvar med "file descriptors" öppna i mycket stor utrsträckning, vilket är förödande med glusterfs. Så glusterfs är generellt mycket bra och stabilt, men lämpar sig inte riktigt för webbhosting i samband med webbserver som accessar filsystemet. Och jag håller med om det du säger ang. balans, och jag både tror och förväntar mig att CN kommer att närma oss mer och mer

[Clarence]

Ursprungligen postat av johan1234

Jag kontaktade Anders och var öppen med att jag skulle vilja lägga honom på en SSD disk så både han och vi kan se hur det förändrar värdena (alla våra SQL servrar går till SSD nu). Jag blev minst sagt förvånad när jag såg att det gjorde absolut ingenting i testet. Kunderna som har fått SSD istället för vanlig är jätteglada och ser stora reella förbättringar (inte konstigt kan man tycka - våra diskar där är flera flera multiplar snabbare och i de flesta databasdrivna projekt ger det effekt. Jag fick dock lite utläggningar om varför det inte gav någonting i testet - från ett par tekniker (för jag är förbluffad själv). Någonstans när jag får tid skall jag försöka summera lite dessa svar. Det handlar lite om att testet mäter mer latency än prestanda i tex hur snabbt SQL servern serverar svaren. Skall se om vi kan köra en tråd om det framöver så att Anders får än mer feedback och kan förbättra ännu mer.

Ja testet är lite konstigt utformat. T ex "compile" som blir helt jämförelselös då man inte får någon nytta av opcode caches som alla vettiga hotell använder. Eller write file som faktiskt inte mäter diskprestanda utan mest bara latency osv. Även sammansättningen blir väldigt skum när t ex 1000 diskwrites blir lika viktiga som 1000 sql-frågor. Det finns ingen som helst likhet med en vanlig webbapplikation. Bättre hade varit att försöka skapa en isolerad exempel-applikation med normal andel av de krävande operationerna och exekvera hela denna utifrån 1000 gånger. Inget som hindrar att man detaljmäter delarna där heller.

[johan1234]

Clarence - en tekniker skickade mig en mycket detaljerad analys i november förra året som fick mig att tänka lite då... Anders ville förbättra skriptet - tyvärr han jag aldrig ta tag i det. Hittade mailet här och kopierar in den lilla summeringen han hade. Om det kan vara av intresse.

"Sammanfattningsvis så har era siffror inte med lastbalanserare, databaskluster eller dylikt att göra, utan de visar enbart att ni har högre nätverksoverhead
mellan webbserver och mysql-server än andra ovanför er i testet. Några ovanför er har kanske till och med databas på samma server som webbserver.

Testet mäter dessutom överhuvud taget inte eventuellt overhead i lastbalanserade miljöer, då mätningen börjar när ett script redan exekverats på en klusternod.

För att göra en bättre mätning sätt ur slutkundsperspektiv så skulle han istället också mäta hela scriptets exekveringstid från anropande klient,
då man då också får med:
1. TCP-handskakning med lastbalanserare eller webbserver
2. Eventuellt overhead p.g.a överbelastad lastbalanserare/reverse-proxy/m.m
3. Tid som request väntar i listen-queue på webbserver-nod
4. Överbelastat nätverk för svarspaketen
m.m.

[Clarence]

Ursprungligen postat av johan1234

Clarence - en tekniker skickade mig en mycket detaljerad analys i november förra året som fick mig att tänka lite då... Anders ville förbättra skriptet - tyvärr han jag aldrig ta tag i det. Hittade mailet här och kopierar in den lilla summeringen han hade. Om det kan vara av intresse.

"Sammanfattningsvis så har era siffror inte med lastbalanserare, databaskluster eller dylikt att göra, utan de visar enbart att ni har högre nätverksoverhead
mellan webbserver och mysql-server än andra ovanför er i testet. Några ovanför er har kanske till och med databas på samma server som webbserver.

Testet mäter dessutom överhuvud taget inte eventuellt overhead i lastbalanserade miljöer, då mätningen börjar när ett script redan exekverats på en klusternod.

För att göra en bättre mätning sätt ur slutkundsperspektiv så skulle han istället också mäta hela scriptets exekveringstid från anropande klient,
då man då också får med:
1. TCP-handskakning med lastbalanserare eller webbserver
2. Eventuellt overhead p.g.a överbelastad lastbalanserare/reverse-proxy/m.m
3. Tid som request väntar i listen-queue på webbserver-nod
4. Överbelastat nätverk för svarspaketen
m.m.

Men även om man skulle ta med detta gör testets sammansättning att det är svårt att få någon ordentlig relevans för en riktig applikation/sajt även om det säkert är troligare med korrelation än ej. Vad man skulle kunna göra vore att modellera enklare prototyper som har samma typ av last som vanliga webb-applikationer. Det är inte helt lätt utan kräver ordentlig profiling av vanliga mjukvaror för att sätta samman till en representativ modell för dom.

[tartareandesire]

Ursprungligen postat av Clarence

Men även om man skulle ta med detta gör testets sammansättning att det är svårt att få någon ordentlig relevans för en riktig applikation/sajt även om det säkert är troligare med korrelation än ej. Vad man skulle kunna göra vore att modellera enklare prototyper som har samma typ av last som vanliga webb-applikationer. Det är inte helt lätt utan kräver ordentlig profiling av vanliga mjukvaror för att sätta samman till en representativ modell för dom.

+1 på den. Som testet är utformat idag så är det ganska intetsägande. Faktum kvarstår dock att även om man skulle göra några av de förändringar som föreslagits så är det väldigt enkelt för webbhotellen att "fuska". Jag skulle inte rekommendera någon att bry sig om dessa resultat alls när de letar nytt webbhotell, möjligtvis med undantaget att vara lite försiktig med de som visar upp riktigt dåliga siffror.

[johan1234]

Många refererar till dessa siffror utan att egentligen veta underlaget. Vore härligt om Anders tog och ändrade lite för att få en förbättring - och komma lite närmare verkligheten.

Fuskbiten kommer vi aldrig ifrån tyvärr vilket nog gör att man alltid skall ta sådana här test med en liten nypa salt.

[tartareandesire]

Ursprungligen postat av johan1234

Många refererar till dessa siffror utan att egentligen veta underlaget. Vore härligt om Anders tog och ändrade lite för att få en förbättring - och komma lite närmare verkligheten.

Fuskbiten kommer vi aldrig ifrån tyvärr vilket nog gör att man alltid skall ta sådana här test med en liten nypa salt.

Det enda möjliga som jag ser det skulle vara om Anders gavs tillgång till det interna systemet och kan göra riktiga slumpade tester men jag vet inte om det är en särskilt realistisk tanke.

[Anders Karlsson]

Ursprungligen postat av johan1234

Jag kontaktade Anders och var öppen med att jag skulle vilja lägga honom på en SSD disk så både han och vi kan se hur det förändrar värdena (alla våra SQL servrar går till SSD nu). Jag blev minst sagt förvånad när jag såg att det gjorde absolut ingenting i testet. Kunderna som har fått SSD istället för vanlig är jätteglada och ser stora reella förbättringar (inte konstigt kan man tycka - våra diskar där är flera flera multiplar snabbare och i de flesta databasdrivna projekt ger det effekt. Jag fick dock lite utläggningar om varför det inte gav någonting i testet - från ett par tekniker (för jag är förbluffad själv). Någonstans när jag får tid skall jag försöka summera lite dessa svar. Det handlar lite om att testet mäter mer latency än prestanda i tex hur snabbt SQL servern serverar svaren. Skall se om vi kan köra en tråd om det framöver så att Anders får än mer feedback och kan förbättra ännu mer.

Såg ni någon skillnad i resultatet, för jag kan tänka mig att siffror som "Search" och "Search no Index" borde bli bättre med SSD diskar.

[Yllas]

Vi flyttade en sajt igår från en av våra egna servrar till kundens City Network o det är en fruktansvärd skillnad.
Och då ska ni veta att vår server verkligen inte någon snabb maskin utan bara en dev som tuffar på hos Bahnhof men den går som en raket jämnfört med CN.

Jag kommer aldrig föreslår någon kund för CityNetwork iaf.