Teknik, hosting & e-handelsløsninger

Svar: hvad er der galt med hastigheden på vores forside?

Kim Tetzlaff - Kim Tetzlaff ApS — Tue, 08 Oct 2013 09:06:24 GMT

Nils:

Kim Tetzlaff - KTJ-Media.dk:
Ryd op i databasen, og fjern overhead

Det kan være svært at sikre MySQL' bliver trimmet ved kun at truncate denne ene db. -Hvis mysql'ens generelle INNODB Mem er fyldt. Så skal der mere til.

Det er typisk tilfældet på en shared hosting at man er påvirket af alle de andre magento sites load på MySQL'en.

Jeg skriver nu ikke KUN at de skal truncate databasen, jeg skriver de skal rydde op i den. og ja det siger lidt sig selv at man på en shared host påvirker hinanden, derfor er det endnu mere vigtigt, som jeg har sagt før, at man holder sin røv fri, og sørger for at alt spiller, også databasen.

Nils:

Kim Tetzlaff - KTJ-Media.dk:
Se på jeres htaccess fil, hvis i har sådan en, om den kan justeres og forbedres, og hvis noget af det kan komme ind serversidet, kan det være endnu bedre for performance : http://www.ktj-media.dk/blog/htaccess-indflydelse-performance/

.htaccess kan ikke bruges til noget. Sitet er hosted på en nginx. Med mindre de har ændret i HTTP Header svaret.

har ikke set på deres server, kun på deres løsning.

Nils:
PingDom siger at initial svar på serveren ligger på 7-11 sekunder. - Det er ret lang tid. (Det kan/skal magentohotel klare på deres servere)

Der vil vi nok altid være uenige.. jeg er ikke af den overbevisning at selvom den kode der er bag sitet er noget skod, så skal hosten kompenserer for dette. Skal selvfølgelig ikke kunne sige om der er lavet noget skod kode på sitet, eller om det er hosten den er gal med, men det er ret tit sådan at det er skodkode der er synderen.

MVH Kim Tetzlaff

Svar: hvad er der galt med hastigheden på vores forside?

Lucas - PerfGrid — Tue, 08 Oct 2013 09:04:19 GMT

Søren.Pedersen:

Vi snakker ikke trafik her vi snakker core performance.

Hvis alt vi snakker i, er Ghz, og og beregninger, hvorfor laver man så CPU'er med mindre gigahertz end man gjorde for 2-3 år siden?

Søren, der er en grund til at rigtig mange CPU'er til servere idag, bliver leveret med flere cores, mere cache, og mindre gigahertz.

Mange af de nye CPU'er idag, beregner måske single thread data lidt langsommere, end nogle gjorde for noget tid siden. Og efter min mening (Og nok også resten af verden, undtaget dig) - har scalability og performance under høj load, da en del mere at sige, end "Jeg kan beregne 10.000 if statements hurtigere end din server, dog kan jeg kun klare 10 besøgende". Vi lever i en verden hvor IT og internettet bliver mere og mere vores hverdag, vi stiller flere krav, til at ting skal kunne klare mange besøgende.

Performance != scalability - kan godt være det er i dine øjne, men tror sku store IT virksomheder der arbejder med mange millioner besøgende, har lidt mere styr på hvordan man skalere og hvad der skal til.

Ja jeg ved godt, at x magento shop, måske ikke har millioner af besøgende, men man må forvente at antallet af besøgende på sin side skal have lov at vokse, og kunne klare mange concurrent users. Så skal man da ikke vælge host x fordi de kan lave 10k if/else statements mere, hvis host y, kan klare langt flere besøgende.

Jeg kender utrolig mange folk, der har haft en side hosted ved et udenlandsk firma, hvor at scriptet ovenfor kørte måske 5% hurtigere, men alligevel når siden fik besøgende så begyndte siden at få timeouts etc, fordi deres infrastruktur simpelthen ikke kunne følge med (selvom deres CPU kunne beregne PHP hurtigere (Som jo er UTROLIG vigtigt i din verden)), men x host, som var 5% langsommere, kunne klare 40-50 gange mere trafik uden problemer, og overall loading tid, faldt i sidste ende alligevel.

Så ja, jeg har en mening baseret på facts om at vi lever i en verden der skal skalere. Alle der arbejder med scalable sites, ved også - at skalere betyder oftest du mister en lille bitte smule performance. Men hvis x script bliver kørt 5% hurtigere på server x end y, og du kan leve med at have lille antal besøgende, så er det vel helt fint. Men fra jeg tror mange synspunkt, har mængden af concurrent users en del mere at sige.

Jeg ved godt du ikke er enig med mig, og det ved jeg du aldrig bliver, så ja, folk fra Amino og sikkert også alle andre steder, kan fylde dig med facts, som er bevist af også store virksomheder, men alligevel, vil de 5% altid betyde mere - de 5% af en test der intet siger omkring skalering.

Du må meget undskylde hvis jeg træder dig over dine tæer

Svar: hvad er der galt med hastigheden på vores forside?

Søren.Pedersen — Tue, 08 Oct 2013 08:40:47 GMT

Lucas - Hosting4Real:

Bare fordi PHP kan beregne de 4 funktioner på server x hurtigere end server y, betyder ikke at en magento shop, eller wordpress side vil loade hurtigere på server x end server y.

Giver jeg dig overhovedet ikke ret, man må formode at hvis man kan lave x*y på en server på 2 sekunder mod 14 sekunder på en anden er serverens performance ligeledes markant hurtigere og derfor vil de fleste andre ting ligeledes køre hurtigere. Om det er 4 funktioner eller 500 er sandsynligvis lige fedt da alle 500 funktioner jo netop vil gøre relativt hurtigere (i single thread som du jo netop selv påpeger PHP er) Vi snakker ikke trafik her vi snakker core performance. Der er sikkert masser af andre parametre, men lad os da checke om motoren er iorden først, lidt ala køre rundt i en fiat 127 med brede dæk, kan godt være den ligger godt i svinget men der er ikke performance til at få den ned ad langstriben, ever.

Hvis du selv havde testet op imod diverse udbydere med diverse tal, gode som dårlige, ville du vide at performance i 99% af tilfældende, er ligefrem proportional med de tal netop et simpelt script der laver x*y viser.

Nok om det, du har en mening, jeg en anden, så stopper tråden her.

Svar: hvad er der galt med hastigheden på vores forside?

Lucas - PerfGrid — Tue, 08 Oct 2013 08:30:06 GMT

Søren.Pedersen:

Giver da et fint billede hvad hvad PHP kan levere, er da logik at jo hurtigere en PHP server kan eksekvere diverse beregninger jo mere power er der bag, er da den bedste metode til at teste om serveren kan leve noget power inden man begynder at rode med sin kode, er da logik for burhøns at motoren, her PHP, skal være iorden inden man kan forvente et hurtig site.

Så du mener simpelthen en server med en quad core 3.4ghz kan klare mere trafik end en server med 8 cores på 2.2ghz?

PHP er single threaded, så ja - du kan teste hvor hurtig din CPU kan beregne samme kode om og om igen, fortæller dig intet om hvordan din side loader hvis du har mere end 1 besøgende :)

Så nej :) Scriptet er helt fint, til at teste skift mellem PHP versioner for at se om der er en forbedring eller ej, i de funktioner der bliver testet i scriptet (hele 4 funktioner?)

Bare fordi PHP kan beregne de 4 funktioner på server x hurtigere end server y, betyder ikke at en magento shop, eller wordpress side vil loade hurtigere på server x end server y.

Svar: hvad er der galt med hastigheden på vores forside?

Søren.Pedersen — Tue, 08 Oct 2013 08:25:03 GMT

Lucas - Hosting4Real:

Hvad kan man bruge dette script til helt præcis? Så vidt jeg kan se på koden tester vi math funktionen 50k gange, string manipulation 100k, loops 10 millioner gange, if/else statement 10 millioner gange.

Nu ved jeg ikke rigtig hvordan hjemmesider i denne verden virker, men jeg tror det er de færreste der har sider der executer kode som dette.. Endnu et godt eksempel på at teste hastighed af beregninger som aldrig nogensinde vil blive brugt.

Giver da et fint billede hvad hvad PHP kan levere, er da logik at jo hurtigere en PHP server kan eksekvere diverse beregninger jo mere power er der bag, er da den bedste metode til at teste om serveren kan leve noget power inden man begynder at rode med sin kode, er da logik for burhøns at motoren, her PHP, skal være iorden inden man kan forvente et hurtig site.

Svar: hvad er der galt med hastigheden på vores forside?

Lucas - PerfGrid — Tue, 08 Oct 2013 08:20:06 GMT

Søren.Pedersen:

Helt enig, man kan jo spørge udbyderen når man har et tal at gå ud fra, alternativt kan man jo fyre et benchmark script af og se hvad tid det tager at eksekvere, bruger selv dette script

http://php54serv1.webhosting.dk/bench.php?numtimes=3

prøvede det af på en udbyder hvor det tog 38 sek :-)

Hvad kan man bruge dette script til helt præcis? Så vidt jeg kan se på koden tester vi math funktionen 50k gange, string manipulation 100k, loops 10 millioner gange, if/else statement 10 millioner gange.

Nu ved jeg ikke rigtig hvordan hjemmesider i denne verden virker, men jeg tror det er de færreste der har sider der executer kode som dette.. Endnu et godt eksempel på at teste hastighed af beregninger som aldrig nogensinde vil blive brugt.

Sjove er, dette script er blevet kørt, på både utrolig store servere, med ultra godt hardware, og andre maskiner med knap så godt hardware. Men hvor beregninger af præcis disse funktioner kan passe en CPU bedst.

Jeg vil mene, at dette ikke giver noget billed af den rigtige verden, helt ligesom den MySQL test du linker til ret ofte, fordi - ja, vi laver ikke samme beregning så mange gange som de tests gør.

Disse tests er latterlige, hvis man vil benchmarke servere, så gør man det med 'real world' examples, og ikke sådan noget skod kode som dette. Sorry to say, men det er virkelig latterligt med disse tests, og folk der har en lille bitte smugle hjerne, ved også at disse tests INTET fortæller om den rigtige performance i virkeligheden, og om hvordan en server skalere.

Og ja jeg har set test resultater af dette script, på servere, som rigtig mange folk ikke har adgang til, som nok tager imod lidt mere data og trafik og alligevel processer data hurtigere end andre servere ;)

Du burde vide bedre Søren.

Svar: hvad er der galt med hastigheden på vores forside?

Powerhosting — Tue, 08 Oct 2013 08:12:36 GMT

Drinkworld:

Hej med jer,

Vi har fået lavet forskellige ting på vores forside i løbet af flere år, men de sidste par måneder er vores forside blevet virkelig langsom.

Det drejer sig kun om forsiden og ikke de andre sider.

www.drinkworld.dk

Er der nogen som kan identificere hvorfor vores forside er så langsom, evt. hvilke moduler? og hvordan kan vi løse dette problem?

Hej Drinkworld.

Den nemmeste måde for dig er at deaktivere alle dine 3. parts-moduler og så aktivere dem én af gangen mens du tester loadtiden.

Gør evt. det samme med din template.

På den måde kan se finde synderen.

God vind med shoppen!

P.S. Til de interesserede kan jeg oplyse at serverens load meget sjældent er over 1:

load average: 0.36, 0.31, 0.27

Svar: hvad er der galt med hastigheden på vores forside?

Søren.Pedersen — Tue, 08 Oct 2013 07:59:17 GMT

Nils:

Lad os så sige at setup'et er nginx/php-fpm. Så har udbyderen offloaded PHP-FPM til et PHP Cluster. Hvilken node i php offload clustered viser dit script da load average for ?

Helt enig, man kan jo spørge udbyderen når man har et tal at gå ud fra, alternativt kan man jo fyre et benchmark script af og se hvad tid det tager at eksekvere, bruger selv dette script

http://php54serv1.webhosting.dk/bench.php?numtimes=3

prøvede det af på en udbyder hvor det tog 38 sek :-)

Svar: hvad er der galt med hastigheden på vores forside?

Nils — Tue, 08 Oct 2013 07:50:22 GMT

Søren.Pedersen:

20 og køre godt kræver jo således 20 cores da hver core således er på "capacity" og ikke overloaded. Hellere have 20 cores og et load på 0 end 20 cores og et load på 50 :-)

Lavt load = serveren har intet i process queue der venter

Højt load = serveren har ting i queue der venter (per core)

Så du har delvist ret, dog er det bedre at have et load på 0 end et på 10 så det er lige det der er relevant

For at kunne bruge load average til noget fornuftigt skal du også vide hvormange cores der er i systemet.

Det kan kun se dit load average i din php kode.

Lad os så sige at setup'et er nginx/php-fpm. Så har udbyderen offloaded PHP-FPM til et PHP Cluster. Hvilken node i php offload clustered viser dit script da load average for ?

Svar: hvad er der galt med hastigheden på vores forside?

Nils — Tue, 08 Oct 2013 07:45:32 GMT

Kim Tetzlaff - KTJ-Media.dk:
Ryd op i databasen, og fjern overhead

Det kan være svært at sikre MySQL' bliver trimmet ved kun at truncate denne ene db. -Hvis mysql'ens generelle INNODB Mem er fyldt. Så skal der mere til.

Det er typisk tilfældet på en shared hosting at man er påvirket af alle de andre magento sites load på MySQL'en.

Kim Tetzlaff - KTJ-Media.dk:
Se på jeres htaccess fil, hvis i har sådan en, om den kan justeres og forbedres, og hvis noget af det kan komme ind serversidet, kan det være endnu bedre for performance : http://www.ktj-media.dk/blog/htaccess-indflydelse-performance/

.htaccess kan ikke bruges til noget. Sitet er hosted på en nginx. Med mindre de har ændret i HTTP Header svaret.

PingDom siger at initial svar på serveren ligger på 7-11 sekunder. - Det er ret lang tid. (Det kan/skal magentohotel klare på deres servere)

Connection på de fleste andre elementer ligger på +2 sekunder. det er også skræmmende lang tid.

Svar: hvad er der galt med hastigheden på vores forside?

Kim Tetzlaff - Kim Tetzlaff ApS — Mon, 07 Oct 2013 22:49:49 GMT

Som jeg altid har sagt, optimer din hjemmeside så den køre godt og hurtigt på en lille server, så kan man altid rykke over på en større hvis det er nødvendigt. Og den nødvendighed har jeg kun set få gange. Så tænk aldrig hardware som det første når man gerne vil have en hurtigere hjemmeside.

Og det passer, man kan få de fleste typer hjemmesider til at køre hurtigt og stabilt, ved at tune og optimere selve løsningen, og det er selv på små servere og dårlige hosts.

MVH Kim

Svar: hvad er der galt med hastigheden på vores forside?

Lucas - PerfGrid — Mon, 07 Oct 2013 22:26:05 GMT

Søren.Pedersen:

Lucas - Hosting4Real:

Nu ved jeg ikke så meget omkring Web - men load average fortæller vel intet?

Load kan være 2, og det kan køre skidt, den kan også være 20, og køre godt.

20 og køre godt kræver jo således 20 cores da hver core således er på "capacity" og ikke overloaded. Hellere have 20 cores og et load på 0 end 20 cores og et load på 50 :-)

Lavt load = serveren har intet i process queue der venter

Højt load = serveren har ting i queue der venter (per core)

Så du har delvist ret, dog er det bedre at have et load på 0 end et på 10 så det er lige det der er relevant

http://blog.scoutapp.com/articles/2009/07/31/understanding-load-averages

er faktisk en god artikel.

Ved skam godt hvordan unix load virker :) Men der kan også ligge 64 sandy bridge CPUer bag ved den server, så hvis der er en load på 50 har det alligevel ingen betydning :) Fordi der er massere af CPU'er at tage af :) Derfor vil jeg mene, at nummeret er ligegyldigt, når man ikke kender hardware, fordi - ja, hvis den siger 'hey, der er 10 i load' - så kan vi sige.. tja, det meget, eller det er lidt - vi ved det ikke :) Derfor syntes jeg, at det er en faktor man ikke bør tænke på, når man ikke kender infrastrukturen bagved.

Og selvom load er 0, kan en server jo stadig være sløvere end en server med 10 i load - eller 50 i load, kommer an på mange ting.

Optimer ud fra hvad du ved sløver siden, ikke ud fra hvad du tror sløver siden. - tag de æbler der hænger lavt, og lad vær med alt mulig mikro optimering, eller udregning af CPU, hvis man kan forbedre loading tid, ved at fixe nogle billeder.

Ingen grund tll at køre ting mere kompleks end de er.

Det er min mening ihvertfald, om folk kan lide den eller ej - er vel op til dem

Svar: hvad er der galt med hastigheden på vores forside?

Søren.Pedersen — Mon, 07 Oct 2013 22:17:32 GMT

Lucas - Hosting4Real:

Nu ved jeg ikke så meget omkring Web - men load average fortæller vel intet?

Load kan være 2, og det kan køre skidt, den kan også være 20, og køre godt.

20 og køre godt kræver jo således 20 cores da hver core således er på "capacity" og ikke overloaded. Hellere have 20 cores og et load på 0 end 20 cores og et load på 50 :-)

Lavt load = serveren har intet i process queue der venter

Højt load = serveren har ting i queue der venter (per core)

Så du har delvist ret, dog er det bedre at have et load på 0 end et på 10 så det er lige det der er relevant

http://blog.scoutapp.com/articles/2009/07/31/understanding-load-averages

er faktisk en god artikel.

Svar: hvad er der galt med hastigheden på vores forside?

Lucas - PerfGrid — Mon, 07 Oct 2013 22:02:25 GMT

Søren.Pedersen:

<?

$load= sys_getloadavg();
echo "Now:".$load[0]."<br>5 min:".$load[1]."<br>15 min:".$load[2];
?>

kald den hvad du vil, f.eks testload.php og start den i din browser. Giver dig serverens load. En anden ting, som de andre skriver, 400 billeder er helt godnat, det skal bestemt bringes ned.

Nu ved jeg ikke så meget omkring Web - men load average fortæller vel intet?

Load kan være 2, og det kan køre skidt, den kan også være 20, og køre godt.

Unix Load er relativt til den mængde cores du har, har du 24 tråde til rådighed på din server, kan du have en load på 20 og nok også lidt mere hvor der stadig er mulighed for at sende trafik til CPU'en uden du skaber nogen form for queue på CPU'en.

Men hvis du kun har 1 core i din maskine, så vil 2 i load være relativt meget. - Så de kan ikke bruge unix load til en dyt, uden at kende specs af CPU'en :)

Svar: hvad er der galt med hastigheden på vores forside?

Søren.Pedersen — Mon, 07 Oct 2013 21:48:57 GMT

Drinkworld:

men de sidste par måneder er vores forside blevet virkelig langsom.

Inden du burger oceaner af tid og penge for at finde ud af om det er dine scripts/moduler der er blevet langsomme var det måske en god ide at checke loaded på din server. Du kan checke din webserver ved at uploade en simple fil indeholdende

<?
$load= sys_getloadavg();
echo "Now:".$load[0]."<br>5 min:".$load[1]."<br>15 min:".$load[2];
?>

kald den hvad du vil, f.eks testload.php og start den i din browser. Giver dig serverens load. En anden ting, som de andre skriver, 400 billeder er helt godnat, det skal bestemt bringes ned.