Teknik, hosting & e-handelsløsninger

Svar: Sådan forbedrede jeg performance med 680 gange - Lær om hjemmesiders hastighed og performance

Kim Tetzlaff - Kim Tetzlaff ApS — Wed, 24 Apr 2013 12:10:22 GMT

Chris Lund Nikolajsen:

Der er et sikkerheds hul i W3TC bør opdateres specielt dem der nævner de bruger det på forummer
http://blog.sucuri.net/2013/04/update-wp-super-cache-and-w3tc-immediately-remote-code-execution-vulnerability-disclosed.html

Jep, man skal også huske at opdaterer hvis man bruger WP super Cache og andre caching plugins som tager hensyn til mfunc

Svar: Sådan forbedrede jeg performance med 680 gange - Lær om hjemmesiders hastighed og performance

Chris Lund Nikolajsen — Wed, 24 Apr 2013 11:58:39 GMT

Der er et sikkerheds hul i W3TC og WP Super Cacher. Bør opdateres specielt dem der nævner de bruger det på forummer
http://blog.sucuri.net/2013/04/update-wp-super-cache-and-w3tc-immediately-remote-code-execution-vulnerability-disclosed.html

Svar: Sådan forbedrede jeg performance med 680 gange - Lær om hjemmesiders hastighed og performance

Lucas - PerfGrid — Wed, 27 Mar 2013 10:41:12 GMT

Kasper, ja vi spare ca 2ms Per pageview ved brug af nginx iforhold til varnish :)

Svar: Sådan forbedrede jeg performance med 680 gange - Lær om hjemmesiders hastighed og performance

Lucas - PerfGrid — Wed, 27 Mar 2013 10:38:55 GMT

Men generet, opnår vi langt højere Performance med nginx som RP, end varnish feks, men i sidste ende kommer det jo også an på applikationen man skal skalere hvad der virker bedst :)

Svar: Sådan forbedrede jeg performance med 680 gange - Lær om hjemmesiders hastighed og performance

Anonymous — Wed, 27 Mar 2013 10:34:13 GMT

Lucas - Hosting4Real:

Squid er et rigtig godt alternativ, eller nginx cache :)

Og de målinger i Google analytics måler ikke fuld pageload :) de måler indtil et bestemt event, så det mindste du lazy loader vil ikke blive talt med (advertisement gjort på den rigtige måde feks)

Er det noget, du har nogle målinger på? Alt, jeg har set af komparative analyser, falder ud til Varnish' fordel. Med undtagelse af et par enkelte test, hvor man har testet LiteSpeeds caching engine op mod Varnish. Dér vandt LiteSpeed til min overraskelse.

Svar: Sådan forbedrede jeg performance med 680 gange - Lær om hjemmesiders hastighed og performance

Nils — Wed, 27 Mar 2013 10:30:53 GMT

Lucas - Hosting4Real:
Squid er et rigtig godt alternativ, eller nginx cache :)

De er et alternativ. - De når bare ikke varnish til sokkeholderne.

Software arkitekturen og programerrings metoderne er kodet til hvordan nutidens kernels er designet.

SQUID forventer at den skal holde styr på hvorvidt data er på disk eller i memory. Når det allerede er implementeret i OS'ets kernel så kommer SQUID Ret hurtig i konflikt med kernel metoderne i sin algoritme.

Svar: Sådan forbedrede jeg performance med 680 gange - Lær om hjemmesiders hastighed og performance

Lucas - PerfGrid — Wed, 27 Mar 2013 10:22:11 GMT

Squid er et rigtig godt alternativ, eller nginx cache :)

Og de målinger i Google analytics måler ikke fuld pageload :) de måler indtil et bestemt event, så det mindste du lazy loader vil ikke blive talt med (advertisement gjort på den rigtige måde feks)

Svar: Sådan forbedrede jeg performance med 680 gange - Lær om hjemmesiders hastighed og performance

Anonymous — Wed, 27 Mar 2013 10:15:17 GMT

@Lukas: Hvad mener du er bedre end Varnish?

#SiteSpeed -- Jeg taler ikke om Googles PageSpeed tool, men om speedmålingerne i Google Analytics.

Svar: Sådan forbedrede jeg performance med 680 gange - Lær om hjemmesiders hastighed og performance

Nils — Wed, 27 Mar 2013 10:12:43 GMT

Kasper Bergholt:
Spændende setup! Jeg har rigtigt gode erfaringer med Varnish -- dog i samspil med EZ Publish, ikke Wordpress; nåede op på 25.000 requests per sekund i en synteitsk test.

Vores primære fokus er magento performance hosting. Wordpress løser bare nogle opgaver mere effektivt end magento.

Når jeg benchmarker på vores systemer bliver datacentrets båndbredde ret hurtigt en bottleneck på den infrastruktur jeg har adgang til. Eller serverens memory til at spawne multiple client sessions. (>1000 samtidige med siege) Så jeg har ikke kunne presse vore virkeligt optimere løsninger helt endnu. Det er der, der er en helt del andre parametre der kommer i spil når det er live-users på commerce løsninger.

- Så jeg kan faktisk ikke svare på det.

Svar: Sådan forbedrede jeg performance med 680 gange - Lær om hjemmesiders hastighed og performance

Lucas - PerfGrid — Wed, 27 Mar 2013 09:53:42 GMT

Kasper Grubbe:

Wordpress er en bitch at performance optimere, da den benytter alle mulige sære regler i dens routing. Det ser dog ud som om den er blevet bedre ved sidste release, og at det er et fokus fra Wordpress udviklerne.

Det ved jeg ikke rigtigt, wordpress er ikke værre end meget andet - folk kan bare ikke finde ud af at bruge wordpress som det egentligt skal bruges, og kan fint skaleres.

Kasper Grubbe:

Varnish er dog essentielt hvis man virkelig vil scale og sparke røv, det er også det som BT og alle de andre større sites benytter.

Varnish er godt ja, men du behøves ikke varnish for at skalere en side, der findes mange andre - nok bedre alternativer :)

Kasper Bergholt:

Problemet med Pingdom Tools er, at der ikke tages højde for eksekvering af scripts (herunder Java). Du får kun stats for, hvor lang tid, det ta'r at downloade filerne -- ikke hvor lang tid det ta'r at eksekvere dem.

Problemet er at du ikke har ret her, pingdom tager højde for eksekvering af scripts - ihvertfald Javascript etc :)

2: Man kan også bruge webpagetest.org, som også tager højde for eksekvering af scripts :)

Kasper Bergholt:

Den reelle loadtid er det, brugerne oplever -- dem, der bouncer, forlader indkøbskurven el. ikke konverterer for sidens loadtid ikke er optimal -- i min optik er det den vigtigste parameter at måle på, når man foretager loadtests.

Ja RUM er klart en god ting at måle, og det er utrolig vigtigt, dog syntetisk test er mindst lige så vigtigt, da den test vil være meget mere stabil - oftest fordi man kender connectivity, hardware etc, og bruger det konstant.

RUM bliver vigtigt når du skal finde ud af om den reele performance er dårlig - fordi bare fordi du har noget der er hurtigt i chrome, betyder det ikke at du lige har gjort en side meget langsommere i IE eller firefox etc :) - Men begge 2 er lige vigtige hvis man skal snakke om performance.

Kasper Bergholt:

Helt enig. Og ja, jeg interesserer mig primært for brugeroplevelsen. Ligesom fx Google SiteSpeed tool gør.

Google SiteSpeed (Pagespeed) er ikke lige det bedste tool at bruge - den giver dig kun et meget lille billed af dit problem - og faktisk er den outdated - der er mange ting der kan gøres bedre end de foreslår etc - og nogle ting er endda forkerte :)

- Men i sidste ende, så kan man jo diskuttere performance i mange år, og alle vil have forskellige meninger :)

Svar: Sådan forbedrede jeg performance med 680 gange - Lær om hjemmesiders hastighed og performance

Anonymous — Wed, 27 Mar 2013 09:50:35 GMT

Nils:

Kim Tetzlaff - KTJ-Media.dk:
Varnish er dog essentielt hvis man virkelig vil scale og sparke røv, det er også det som BT og alle de andre større sites benytter. Men det kan godt være det ikke spiller pænt sammen med Wordpress, og det ville egentlig ikke overraske mig, jeg er dog ret sikker på at de større Wordpress sites i DK benytter Varnish, heriblandt http://bloggersdelight.dk/

www.commercegruppen.dk er en Wordpress med en del plugins.

Den ligger på vores server hos Interxion i ballerup med følgende setup:

Varnish / Nginx / PHP-FPM / APC & WP Super Cache.

Bloggers Delight bruger Varnish. - Og et par cluster nodes... ;-)

Spændende setup! Jeg har rigtigt gode erfaringer med Varnish -- dog i samspil med EZ Publish, ikke Wordpress; nåede op på 25.000 requests per sekund i en synteitsk test.

Jeg kan se, I har valgt WP Super Cache, som jeg også sværger til. A/B-testede I det op mod W3 Total Cache?

Svar: Sådan forbedrede jeg performance med 680 gange - Lær om hjemmesiders hastighed og performance

Nils — Wed, 27 Mar 2013 09:47:04 GMT

Kim Tetzlaff - KTJ-Media.dk:
Varnish er dog essentielt hvis man virkelig vil scale og sparke røv, det er også det som BT og alle de andre større sites benytter. Men det kan godt være det ikke spiller pænt sammen med Wordpress, og det ville egentlig ikke overraske mig, jeg er dog ret sikker på at de større Wordpress sites i DK benytter Varnish, heriblandt http://bloggersdelight.dk/

www.commercegruppen.dk er en Wordpress med en del plugins.

Den ligger på vores server hos Interxion i ballerup med følgende setup:

Varnish / Nginx / PHP-FPM / APC & WP Super Cache.

Bloggers Delight bruger Varnish. - Og et par cluster nodes... ;-)

Svar: Sådan forbedrede jeg performance med 680 gange - Lær om hjemmesiders hastighed og performance

Kim Tetzlaff - Kim Tetzlaff ApS — Wed, 27 Mar 2013 09:41:32 GMT

Kasper Bergholt:

Kim Tetzlaff - KTJ-Media.dk:

Kasper Bergholt:

Problemet med Pingdom Tools er, at der ikke tages højde for eksekvering af scripts (herunder Java). Du får kun stats for, hvor lang tid, det ta'r at downloade filerne -- ikke hvor lang tid det ta'r at eksekvere dem.

Derudover svinger Pingdom Tools afhængigt af, hvor mange der bruger tjenesten på et givent tidspunkt.

Jeg er derfor gået over til HttpWatch -- og kører så 20 el. 30. test per url/site/konfiguration.

Sidst jeg lavede en komparativ test af W3 Total Cache, Hyper Cache og WP Super Cache faldt testen ud til WP Super Caches fordel.

det er ikke så relevant at du ser på den fulde loadtid, eksekvering af javascripts mm. når det reelt er html caching du skal sammenligne, og ikke alt muligt andet. Det er nemlig den eneste lighed der mellem de forskellige plugins du har testet og ikke mindst jeg har testet... så at pingdom ikke tager højde for det er i denne sammenhæng ikke relevant.

HTML caching og måling på denne, sker FØR javascripts, billeder mm bliver målt på. det er en fin test du har lavet, men det er blandt andet også på grund af ovenstående, at din test ikke er så valid som den kunne have været, da du netop ikke ser udelukkende på effekten af html caching, men den fulde loadtid.

Prøv at læse denne test af 3 forskellige caching plugins, herunder også WP Super Cache og W3TC. Den ser netop på effekten af html caching og ikke alt muligt andet. da det netop er den eneste lighed der er mellem de plugins. Og denne test går i dybden.

MVH Kim Tetzlaff

Jeg kan godt følge dig. Men jeg vil til enhver tid foretrække real-life test fremfor syntetiske test. Men begge dele har selvfølgelig deres berettigelse.

Den reelle loadtid er det, brugerne oplever -- dem, der bouncer, forlader indkøbskurven el. ikke konverterer for sidens loadtid ikke er optimal -- i min optik er det den vigtigste parameter at måle på, når man foretager loadtests.

Og du kommer jo ikke udenom, at Pingdom svinger afhængigt af, hvor mange brugere der bliver serviceret i et givent øjeblik.

Kasper Bergholt:

Overordnet set har du et tekno-centrisk approach, mens jeg har et bruger-centrisk approach.

Det er fint nok at du mener som du gør, men nu har jeg testet de plugins fra mange forskellige vinkler, ikke kun ud fra en vinkel. Rent faktisk har jeg testet fra 5 vinkler, som alle ser på effekten af de plugins. Og ser man helt teknisk på det, er der al mulig grund til at vinderen er blevet som den er her: test af 3 forskellige caching plugin

hvilket jeg også forklarer i testen.

I din test ser du ud fra den fulde loadtid, for at sammenligne nogle plugins hvis eneste lighed er page caching / html caching. Det kan man altså ikke da der selv i det testværktøj du benytter dig af er mange ting der spiller en rolle for udfaldet af den fulde loadtid. fx lavede du testen 10 gange, men hvor hurtigt efter hinanden lavede du testen, clerede du browsercachen hver gang, lavede din computer andre ting både i baggrunden og i browseren og meget mere.

Yderligere kan det teknisk set ikke lade sig gøre at PHP metoden er hurtigere eller har bedre performance end htaccess og statisk html, som jo er de indstillinger du har testet med.

Og jeg har nu engang brugt 5 forskellige værktøjer, inklusiv set fra brugerens og yderligere fra serverens side. det vil sige over 250 tests udført... Og der var der en klar vinder.

Pingdom Tools er et fint værktøj til at teste, så længe at man som med så mange andre testværktøjer, ved hvordan man bruger det og hvad man skal kigge på.

MVH Kim

Svar: Sådan forbedrede jeg performance med 680 gange - Lær om hjemmesiders hastighed og performance

Anonymous — Wed, 27 Mar 2013 09:32:49 GMT

Nils:

Kasper Bergholt:
Problemet med Pingdom Tools er, at der ikke tages højde for eksekvering af scripts (herunder Java). Du får kun stats for, hvor lang tid, det ta'r at downloade filerne -- ikke hvor lang tid det ta'r at eksekvere dem.

Javascript er vel clientside scripts ? Så eksekveringen er relevant når content er loaded i browseren. Og dermed særdeles afhængig af Client side ressources.

Det har ingen betydning for loadtiderne(Server Side -> Load Time -> Client Side). Men betydning for bruger oplevelsen.

Helt enig. Og ja, jeg interesserer mig primært for brugeroplevelsen. Ligesom fx Google SiteSpeed tool gør.

Svar: Sådan forbedrede jeg performance med 680 gange - Lær om hjemmesiders hastighed og performance

Nils — Wed, 27 Mar 2013 09:29:41 GMT

Kasper Bergholt:
Problemet med Pingdom Tools er, at der ikke tages højde for eksekvering af scripts (herunder Java). Du får kun stats for, hvor lang tid, det ta'r at downloade filerne -- ikke hvor lang tid det ta'r at eksekvere dem.

Javascript er vel clientside scripts ? Så eksekveringen er relevant når content er loaded i browseren. Og dermed særdeles afhængig af Client side ressources.

Det har ingen betydning for loadtiderne(Server Side -> Load Time -> Client Side). Men betydning for bruger oplevelsen.