Dansk WordPress – ressourceforbrug
De fleste der følger min Twitter strøm har nok bemærket at jeg igennem mere end en uge har kæmpet med at få nogle WordPress blogs til at fungere ordentligt på en ny dedikeret server.
For at gøre en rigtig lang historie kort er jeg kommet dertil hvor jeg ikke længere vil benytte den danske version af WordPress.
Efter masser af forskellige tests, har jeg fundet frem til at den danske udgave af WP koster en hel del på ressourceforbruget på serveren. Et så stort forbrug at det på ingen måde (for mig) kan retfærdiggøre at bruge det. I stedet kan jeg direkte via mit tema lave lidt omkodning og få en “dansk” blog i brugernes øjne. Dertil kan jeg sagtens leve med at min administration (wp-admin) er på engelsk.
For de tekniske kan jeg sige at blot ved at skifte fra DK til EN har jeg kunne reducere min php memory_limit fra 32M til 8M på flere forskellige blogs uden at få Allowed memory size exhausted fejl – det er noget af en markant forskel i mine øjne.
Udover det vil kræve mindre af din server/webhost at generere en side for brugeren, vil det også kunne give dig en hurtigere blog da du undgår en masse data skal igennem oversættelses delen.
Hvis ikke hastighed på dine hjemmesider er høj prioritet lige nu for dig, så bør du nok overveje at bruge lidt kræfter på det snarest. Hurtigere hjemmesider er en del af den ranking faktor Google benytter. Så tænker du i SEO kan du ikke komme uden om at optimerer hastigheden også.
Jeg vil rigtig gerne høre hvis andre har lavet nogle lignende tests og kan bekræfte dette markante ekstraforbrug ved at benytte andre sprog end EN.
Og kan lige nævne at man ret nemt selv kan teste sin blog uden at bruge skulle anstrenge sig for meget.
I din wp-config.php kan du ændre
define (‘WPLANG’, ‘da_DK’);
til
define (‘WPLANG’, ”);
(Om der er andre ting der er anderledes i EN/DK versionen, andet end selve MO filen, ved jeg ikke.)
Spændende. Jeg måtte straks teste.
Ved automatisk opdatering hos noget af min billighosting har jeg nemlig oplevet en fejl under opdatering og en besked om exhausted memory. Det var i DK-versionen.
En hurtig ændring i wp-config senere opdaterer den nu fejlfrit fra dashboardet.
Jeg skal måske nok lige rende en blog eller to over og overveje, om jeg bare skal bruge den engelsksprogede version på dem fremover.
Tak for at dele din test – og hvis man skal se på den positive side, så er det da rart, at der kom bare en lille smule godt ud af alle dine kvaler med din nye server.
Som mangeårig oversætter af kommerciel software, så har det i en del år undret mig, at oversættelsen af fri software også blot har fungeret efter fri-princippet. Selve tankegangen har jeg det fint med, men når man ved, hvor mange kræfter der bliver lagt i testarbejde og alverdens sager for at sende et kommercielt produkt i luften, så har det forbavset mig, hvis det ville virke fejlfrit blot at oversætte nogle ressourcefiler.
Så på sin vis glæder det mig (lidt skadefro skal man vel være en sjælden gang), at så nemt går det så tilsyneladende heller ikke. 🙂
Jeg er i gang med at konfigurere min første “rigtige” blog med WordPress, hvor jeg den anden dag satte WPLANG til da-dk for at udnytte danske versioner af nogle plugins, men til min store overraskelse medførte det også, at selve WordPress blev autoopdateret til dansk. Bloggen ligger heldigvis kun lokalt indtil videre, så det må vist også blive den engelske version, jeg skal bruge, og så selv stå for lokaliseringen (så er der godt nok ikke så meget hobby over det mere, når nu det også er det jeg laver hele dagen :-).
Så tusind tak for tippet og din omfattende kamp for at få serveren til at køre.
“For de tekniske kan jeg sige at blot ved at skifte fra DK til EN har jeg kunne reducere min php memory_limit fra 32M til 8M på flere forskellige blogs – det er noget af en markant forskel i mine øjne.”
Hvordan har du testet det? Bare sådan af ren nysgerrighed…
Hej Rudi. Det har jeg gjort er at ændre min php.ini fil hvor memory_limit kan sættes.
Dog kan det også gøres via din .htaccess ved at indsætte
php_value memory_limit 32M
For at finde ud af hvad din nuværende memory_limit er, kan du checke din phpinfo indstillinger.
Bemærk at du via din .htaccess kun kan gå ned i ram ressourcer, men aldrig over det der er specificeret i php.ini der administreres af din webhost.
Yeps, det er præcis exhausted memory man oplever hvis der ikke er nok RAM allokeret i forhold til det WP kræver.
Ja er dejligt at nu have muligheden for direkte at kunne lege med sådanne ting og kunne måle på det direkte på serveren. Er kommet noget klogere ud af denne lange ude 🙂
I alle årene har jeg kun kørt med den engelske version af WP. Jeg ved ikke hvorfor, men noget sagde mig, at det var bedst. Sjovt at ens instinkt kan ramme rigtigt på noget så teknisk.
Og tillykke med at du nu har fået løst de problemer!
Uha Claus – jeg ved hvor meget du har siddet og svedt – jeg sad selv med nogle gange til langt ud på natten. Da jeg så din blogpost på forsiden af Zooka, viste jeg du havde vundet kampen. Som du skrev til mig kl. 01.30.. du giver ikke op så let.. Næ, men det gør du heller ikke. De Herre, jeg kan garanterer jer for, at Claus har gennemgået alt hvad der om muligt kan gennemgås i WP. Du har min fulde respekt!
Tak for jeres kommentarer 🙂
@Zooka: Ja det var lækkert du gad hjælpe med nogle test og råd – Vi fik bla Zooka bot til at lave nogle test af Snyd.dk på 2 forskellige hosts samtidig for at checke loadtider mv.
Du er god at have i baghånden når du oven i dit venlige væsen også kan tage Zookabot med til festen 😀
Ekstremt spændende læsning — som alti, Claus!
Jeg er fluks gået i gang med at kigge på ressourceforbrug på mit site.
Jeg bruger følgende værktøj, så også gi’r lidt andre informationer end ramforbrug:
Jeg har ikke nået at sammenligne med en engelsk udgave endnu.
Hvilken version af WordPress kører du? 2.9.1?
Jeg kører pt. med en php memory_limit på 32mb — og alt kører fint og hurtigt. Hvis jeg ikke kæmper om ressourcer med andre, er der vel ikke noget i vejen med at holde fast ved den indstilling? Eller?
Alt godt,
Kasper
@Kasper, tak tak 🙂 Ja det er seneste version jeg har testet med. (2.9.1)
Og ja hvis din blog kører fint med den limit er der ingen grund til at ændre det – bloggen bliver ikke hurtigere af du hæver den. Men hvis du smider flere Plugins på og har DK versionen af WP, vil du måske opleve (exhausted memory) på et tidspunkt. Så hold alt øje med bloggen efter der er installeret nye plugins.
Et sted som Unoeuro har fx. som standard 128M i memory_limit – den er så høj så ingen vil opdage at deres ressourcer løber løbsk, men er også dejligt nemt for den normale blogger at man ikke skal tænke i ram forbrug.
Der er, i min verden, ikke noget odiøst i at have mem limit på 32MB.
Jeg vil mene du skal kigge på et cache plugin, eller noget mod_php, hvis der ikke er andre klienter på din server, eller suphp hvis der er.
xCache og Zend er også noget der trækker i den rigtige retning.
Mange standard (og engelske) plugins kan dårligt fungerer med 8MB mem limit.
Det kommer selvfølgelig an på hvad man vil.
Nu du har fået dig en dedikeret server, skal du jo også bruge den.
Tak for hurtig respons! 🙂
God pointe med antallet af plugins, og deres tyngde.
Kender du — eller andre i tråden — til tabeller for merbelastning ved øgning i antallet af samtidige brugere?
Jeg har foretaget en minianalyse af to forskellige wordpress-projekter, der kører med samme serverløsning (Surftown), dog med forskel i php-versionerne.
Hvis monitoreringsplugin’et er til at stole på, så er der ikke den store forskel i ressourceforbruget.
Screenshots kan ses her:
http://kasperbergholt.blogspot.com/2010/02/ressourceforbrug-wp-dansk-vs-engelsk.html
Med ønske om en dejlig mandag til alle!
Kasper Bergholt
Hmmm… yderst interessant artikel. Det kan måske forklare hvorfor jeg synes mine 3 WP blogs er langsomme? Havde nu ikke lige bemærket at det skulle være sket ved overgangen til de danske versioner. Men det var da et forsøg værd at skifte en af dem tilbage til engelsk 🙂
Hold da op…. Testede lige kort og fik en halvering af loadtid pr side, det virker altså bare lovende.
Jeg sad faktisk og undrede mig i weekenden over at en .dk blog havde så meget dårligere performance i forhold til en .com, begge er sat nærmest identisk op, altså lige bortset fra hosten (US og DK).
I første omgang gav jeg den danske host skylden – det var det så ikke, eller i hvert fald ikke helt 🙂
Thanks for sharing!
@Jan Skinnerup —
Hvis jeg var dig, ville jeg forsøge at udelukke evt. andre flaskehalse inden — database, php query-eksekveringstid, osv., inden du skifter version.
Er hastighedsnedsættelsen generel — eller er der tidsmæssige udsving fx? — det kunne indikere, at der er for meget load på de servere, hvor du hoster.
Go’ arbejdslyst!
@j1s: Du misforstår mig vist. Jeg går ind for at tune tingene ind og ikke bare lade ting løbe løbsk.
Situationen er at jeg skal bruge den server til mange sites (Plesk 100 licens), men efter bare en håndfuld DK blogs begyndte ressourcerne at forsvinde og det endte også med nedbrud pga. alt rammen var spist.
Jeg har så fundet den største synder (WP-DK) der fik mine blogs til at suge 4 gange så meget RAM, bare for at oversætte et par ord hist og her – Det er jo åndsvagt!
Jeg skriver på intet tidspunkt at memory_limit permanent skal nedsættes til 8M – jeg har min på 64M nu, netop for at have lidt at løbe på. Men i en test proces hvor jeg har skulle finde RAM syndere var det en af metoderne, og WP-DK viste sig at være den absolut største synder mht. RAM frås – det er hele pointen 🙂
Ved ikke lige hvilke plugins du benytter, men jeg har altså kunne få alle dem jeg skal og vil bruge (15+ stykker) til at virke perfekt på WP-EN med 8M. Det er til en blog med op til 8000 daglige unikke / 40000 sidevisninger. Der begynder ressourceforbrug pr session altså at betyde noget i min verden.
@Klaus, velbekommen 🙂
@Jan: Der er rigtig mange ting der kan gøre en blog langsommere. For mange og (dårligt kodet) plugins kan virkelig trække ned i hastigheden – nogle plugins er virkelig dårlige.
Selv deaktiveret plugins kan ligge og trække ressourcer, så har du plugins du ikke brugere mere, så deaktiver og slet dem helt.
Fx. anbefaler jeg alle der vil have en bedre blog at få renset ud i deres template – fjern og erstat alle unødige php kald – se evt. mere her: https://yoast.com/site-speed-tools-suggestions/
@ Kasper & Claus
Ja, det er en generel langsommelighed. Jeg har dog mit theme mistænkt for at være hovedsynderen. Mine blogs har nemlig ikke altid være langsomme 😉
Jeg har installeret W3TC på alle mine blogs, og der er ingen plugins installeret som ikke også er i brug. Og stadig synes jeg ikke det kører fantastisk hurtigt.
Men I kan jo selv surfe forbi og se hvad I synes. Mit navn er linket til mig “main blog”.
Skal dog også siges, at jeg for nyligt installerede Firefox – sådan for sjovt. Og den virker til at eksekvere websites NOGET hurtigere end IE.
@Jan: Ja teamer kan i den grad godt betyde noget for loadtiden. Jeg har flere eksempler på nogle temaer tager 2-4 sek mere pr sideload end mere simple temaer.
Udover de fif der står i forrige link jeg sendte i kommentaren, kan temaer sagtens komme med flere sprog og sin egen lille oversættelses fil (.mo) – Det er sikker tilfældet i dit tema også.
Du kan ret nemt spotte om der bruges oversættelse i dit tema ved at kigge temafilerne igennem og se om der er tilfælde af
Men Jan du er velkommen til lave en admin bruger på din blog til mig, så kan jeg lige hurtigt skimme den igennem og se om der er ting du kan forbedre.
Umiddelbart tænkte jeg på en mængde galleri-plugins, fx Nextgen eller andre upload-agtige plugins.
Jeg ved ikke om jeg misforstod, måske udtrykte jeg blot begejstring for cache muligheder på en dårlig måde.
Det er et af de steder hvor man kan hente rigtig meget hastighed udover at konfiguere Apache eller man nu måtte bruge.
Hvorfor valgte du egentlig Plesk, om man må spørge?
@j1s: Jeg bruger allerede forskellige caching muligheder og har tidligere skrevet flere forskellige blogposts om det her på bloggen. (Se evt. https://da.clausheinrich.com/hurtigere-wordpress-blog/ )
Ja der er forskellige plugins der absolut vil gå langt over 8, 16 og selv 32M i memory limit. Nexgen er godt eksempel.. TDOmini forms er et andet eksempel der også suger.
Men igen må jeg understrege at ved at bruge WP-DK versionen krævede flere af mine blogs ca. 34M pr sidevisning, mens præcis den samme side med WP-EN skulle bruge mindre end 8M for at generere siden.
Det er sådan set bare der hele pointen ligger – er det kæmpe ekstra ressourceforbrug værd for folk derude, for at få DK versionen af WP, hey så fint nok.
Jeg vil dog hellere leve uden DK i dette tilfælde, have hurtigere sider og kunne få flere sider på min server uden at skulle smide endnu mere RAM i.
Plesk valget er blot fordi jeg har hørt godt om det og fordi det var det min nuværende host benyttede. Har ikke haft tænkt nærmere over det punkt må jeg indrømme.
Jeg kiggede lidt mere på problemet med det større forbrug af hukommelse på den danske version, og kan se på flere blogge, at det samme problem gælder for andre sprog også.
Jeg lavede derfor en compare af filerne i dansk og original WP, og det er helt tydeligt, at de primære ændringer er opslag i .mo-filerne:
Engelsk streng:
Dansk streng:
Næsten alle strenge i den lokaliserede version er omskrevet til at bruge __() eller _e() til at lave opslag i .mo-filerne, så som Claus allerede er inde på, er det nok der, hunden ligger begravet.
Hvis man har et plugin, der understøtter oversættelse (og det gør de fleste vel nok), så er de sikkert også overfyldt med __() og _e(), og der vil formentlig være en del hukommelse sparet, hvis man bruger tid på at omkode det.
Jeg har ikke kigget nærmere på, om man automatisk får opdateret til en “oprindelig” version, hvis man fjerner sprogkoden i WPLANG, eller om man så blot beholder en lokaliseret version på engelsk. I princippet ville man jo sagtens kunne have en version på engelsk, som stadig bruger de lokaliserede filer, som laver opslagene – der vil blot ikke blive returneret en ny værdi.
Det er altså heller ikke nok blot at bruge editoren til evt. at rette strenge til dansk i plugin-filer i stedet for at bruge en eventuel .mo-fil, da funktionerne til opslag efter oversættelser stadig vil findes i filerne.
Præcis Johnny – godt du kunne forklarer det lidt bedre end jeg. Det er nemlig ikke DK specifikt men hele ordbogsdelen der kommer med i bloggen via /wp-includes/promo/* – Jeg har dog fokuseret på DK da det er det mest nærliggende på en dansk blog 🙂
Ja der er flere steder denne lokalisering finder sted.. Bla også i temaer. eksempel fra functions.php på et tema jeg har her:
//load_theme_textdomain( ‘artsee’, ABSPATH . ‘/wp-content/languages’ );
//$locale = get_locale();
//$locale_file = ABSPATH . “/wp-content/languages/$locale.php”;
//if ( is_readable($locale_file) )
// require_once($locale_file);
Jeg har dog // quoted det ud så den ikke gør brug af oversætteren i temafilerne.
Og samtidig omskrev jeg også alle __( og _e( til helt ren tekst, så vi undgår et helt unødigt opslag pr streng til ordbogsdelen.
At enkelte plugins så selvstændigt benytter deres egen oversætter fil, er mere tricky at rode med, pga rettelser overskrives ved updates.
Det er her vi nok blot skal gå efter de lavthængende æbler, der er store og saftige 🙂
Rigeligt med ram og en opcode cache kan også løse problement.
Har ligesom Rosenstand valgt at køre med den engelske helt fra start.
Dog hovedsageligt fordi, at jeg bare foretrækker alt på engelsk – også styresystem, browser etc. Kan bare ikke fordrage nogle af de danske udtryk plus det ofte er nemmere at finde hjælp og tutorials på engelsk.
Hov… kom helt væk fra denne tråd igen. Men jeg tror jeg fundet “løsningen”.
Jeg tror nemlig ikke det var min host og/eller system der var specielt langsom. Jeg tror det var min gamle IE7 der var problemet. Det opdagede jeg, da jeg prøvede Firefox. Så opgraderede jeg til IE8… og vupti… så var det noget hurtigere over hele linjen.
Det forklarer også, hvorfor nogle af de hastighedsmålinger jeg lavede ikke stemte overens med min egen opfattelse af “verden”. Det er der hermed rådet bod på 🙂
Jeg benytter Simplepress forum, der kræver at man skriver sprog i WPLANG i config filen for at sprogfilen til forummet anvendes. De foreslår at man sletter .mo filen i languages mappen i WP. Har det samme effekt i WP mon, som helt at undlade da_DK i congfig’en?
@Bo: Både og. Ved at slette .mo filerne vil oversættelserne ikke blive fuldført, men serveren vil dog stadig lave et lookup efter denne .mo fil.
Mit klare råd vil være at manuelt omskrive ens tema og manuelt indsætte de danske ord/sætninger, i stedet for sprogversionen.
Eksempel:
kan blot omskrives til
Kommentar
Hej Claus,
Har du tilfældigvis været igang med testing af dette i den nye 3.0?
Jeg bruger selv den engelske og vil nok altid gøre det. Til gengæld er der kunder, som specifikt efterspørger at få det på dansk og som udgangspunkt skal det jo så gerne leveres 🙂
Hejsa Steen,
Nej jeg har valgt ikke at springe på 3.0 endnu med de mere seriøst blogs. Af princip venter jeg altid lige et par patches/opdateringer for at få de mest grælle fejl rettet.
Men jeg vil godt lige smide en update når jeg en dag får testet den nye WP version.
Jeg forstår hvis kunden godt vil have det på dansk – mange vil nok gerne give en lille smule ekstra loadtid for at få det sådan, og det er ganske ok.
Det ville være fin service 🙂
Hvis jeg selv kommer igang med 3.0 (venter helst af samme årsager), og jeg bliver klogere herpå, så smider jeg gerne en kommentar.
Ved du Claus – eller andre – om problemet stadig er lige så stort med langsommelige blogs, hvis man benytter dansk sprog på dem…?
@Christian: ved jeg faktisk ikke da det vil kræve en ny test. Personligt bruger jeg altid den engelske udgave og laver blot de danske rettelser jeg har behov for direkte i mit tema.
Når jeg finder tiden vil jeg lave en test på de 2 versioner.
Men ja måske der er andre derude der har testet på WP 3.2.x