Hejsan alla glada! :D
Jag håller på att bli smått tokig, jag bytte för ett tag sedan (när jag nu senast var här och skrev) ut min scoutkårs hemsida från joomla till drupal (6).
Men nu så verkar sidan börja bli segare och segare för varje dag som går. Den har aldrig varit lika snabb som joomla var, och nu börjar folk klaga lite på det.
vi börjar med att säga att hemsidan är http://www.hv.ssf.scout.se
Sidan tar ca ~3sek att ladda när man är inloggad som administratör via FF
2850,47 ms. enl drupal (via devels debuginfo längst ner på en enskild sida, utan några temorära filer)
Snittet ligger nu på ca 1,3 sek enligt statisk modulen som medföljer (440 träffar på förstasidan) och enligt devel på 2,789 (nystartad, så 14 träffar bara)
via ett program, Fiddler, så tar sidan totalt nästan 7 sek att ladda innan alla bilder är inne
om man går in på sidan igen, dvs man har alla bilder, så tar sidan lite mer än 5 sek att ladda enl progamet.
I IE så verkar sidan ha tokfnatt, även med bilder osv hämtade så tar det enskilda gånger ca 10 sek att hämta, annars runt 3
Jag vet faktiskt inte vad som är fel, jag är mest förvirrad just nu :\
och jag har försökt söka på nätet, men det har inte gett några fina resultat
hittade http://groups.drupal.org/node/19478 men det gav inte mig så mycket, då det inte finns några paneler på vår sida.
Den ställer 182 frågor till databasen på 252 ms, så vad den gör resten av tiden är för mig en gåta :/
"Bygger upp" sidan med hjälp av frågorna? Det saknas ca 2,7 sek som den gör någonting okänt under..
Vad som då kan göra sidan segt:
Vi använder URL alias, så det är en hel del sådana frågor iofs så det tar väl lite tid, är detta något som man borde då stänga av?
Sen har jag sett massa "skuma" frågor typ:
SELECT s.lid, t.translation, s.version FROM locales_source s LEFT JOIN locales_target t ON s.lid = t.lid AND t.language = 'sv' WHERE s.source = 'En <em>omröstning</em> är en fråga med ett antal tänkbara svarsalternativ. När en <em>omröstning</em> väl har skapats tillför den en enkel fortlöpande räknare över antalet röster som erhållits på respektive svarsalternativ.' AND s.textgroup = 'default'
Gör den ens nått värdefullt?
Varför frågar den om någonting som jag inte har en aning om vad det är då den redan har texten som den borde vilja ha?
Så det jag vill ha sagt med detta, vad kan jag göra för att opitmera mera?
Den slår redan ihop alla css/js filer till en, cacheläget är inställt på normal.
Jag tycker ju personligen att i standard utförandet så borde drupal klara av att cacha en "liten" hemsida.
Har hittat en modul, Boost, men täntke ändå skriva här först innan jag installerar. För problemet borde ju finnas kvar även om man installerar den modulen, så täntke ha en så bra grund som möjligt :)
När jag ändå ställer en fråga, kommer en liten fråga
filhantering i drupal?
Vad borde man använda?
Vi använder just nu IMCE, men det är lite segt att hålla på mot den, sen blir ÅÄÖ oftast fel..
Finns det någon annan vettig hanterare som fungerar med tinymce, eller på något lätt sätt ändå gör att en användare kan få en länk och klistra in
spec sättet den hanterar bilder på är trevligt tex.
Ta hand om er alla!
//Joel Martinsson
Comments
Boost är absolut att
Boost är absolut att rekommendera, det kommer att snabba upp din sajt avsevärt. Boost fungerar dock enbart för icke inloggade användare, ifall du vill cacha sajten även för inloggade användare kan jag rekommendera modulen Authcache.
I övrigt kan jag rekommendera att avaktivera statistik-modulen, den är väldigt tung och kan i sig tynga ner sajten en del.
Tackar :) ska kolla lite på
Tackar :)
ska kolla lite på det då
mjo, men sidan var seg redan innan statistikmodulen, så det märks ingen skillnad :P
Hej Joel! Kul att du kör
Hej Joel! Kul att du kör Drupal!
Underskatta inte vikten av sk frontend performance, dvs bilder, grafik mm. Ladda ned YSlow-addonen till Firefox och se vad den rapporterar. Du kan antagligen snabba upp din sajt genom att aktivera Drupals funktion (admin/settings/performance) för att slå samman (aggregate) CSS och JS. Du kan också spara nedladdningstid genom göra om grafik till s k sprites.
YSlow analyserar din sajt och ger rekommendationer om allt detta.
Jakob Persson – Leancept – Results-only digital and marketing consultants – Personal blog
Jag gjorde en rapport med
Jag gjorde en rapport med YSlow åt dig:
http://www.mediafire.com/file/yoymh3jzn0m/yslow.pdf
Jakob Persson – Leancept – Results-only digital and marketing consultants – Personal blog
Hej på dig med Jakob :D ja,
Hej på dig med Jakob :D
ja, hörde ju att det skulle vara bra av någon ;)
Jo, provat tillägge, men det var rätt svårt att förstå vad dom menade med tex ETags då jag försökt googla, men inte fått nått exempel på hur man skulle fixa det. Sen visar ditt test F, medans jag få A inloggad, B utloggad :P
Nä, jag vet det där med bilderna, men om du kollar på denna bild:
http://www.hv.ssf.scout.se/fel/tider.jpg
övre grafen är allt utan cache, undre med
Gjorde ett par tester till med cache (då den blev så hög), ett av testerna kom under 1 sek, resten låg bortåt 12, och det var bara drupals huvudfil som tog mest tid.
På tal och Drupal och
På tal och Drupal och prestanda, det skulle vara kul att höra om någon lekt med Pantheon/Mercury. Det ska ju vara riktigt snabbt sätt att köra Drupal enligt vad de påstår. Gärna med ett Sverige-perspektiv då.
Vi kör redan en del av
Vi kör redan en del av Mercury-stacken på flera av de webbplatser vi byggt. Vi har sedan länge använt Memcache och APC för opcode-cachning och någon form av reverse proxy cache (Squid eller Varnish) på riktigt tunga sajter. Problemet med skalbarhet är att man normalt inte behöver skala för den regelbundna trafiken utan måste hantera spikar då trafiken ökar mångfaldigt. Av denna anledning är det viktigt att lasttesta och även göra ett gott arbete vad gäller frontend – t ex använda CDN för att möjliggöra parallellisering och minska antalet begäran till webbservern med aggregering och sprites.
Om du är nyfiken rekommenderar jag boken High Performance Websites som är skriven av samma person som skapade YSlow.
Jakob Persson – Leancept – Results-only digital and marketing consultants – Personal blog
Om man inte har behov att
Om man inte har behov att klara av spikar i första hand eller för den delen riktigt hög trafik, utan bara vill ha en hyfsat snabb sajt som bara har måttligt med besökare vid normaltrafik, är det overkill att jobba med liknande lösningar eller är det något varje Drupal-installation borde sträva efter?
De webbplatser jag jobbar med har klarat sig rätt bra med ett vanligt webbhotellskonto likt Binero, men det kanske inte är blixtrande snabbt alltid. Fördelarna är framförallt ekonomiska (vilket för små projekt kan vara avgörande) men även för att jag tycker att jag saknar kunskaperna som krävs för att drifta virtuella servrar själv. (Eller drifta kanske är fel ord, men att ansvara för serverinstallation, konfigurering och uppdateringar.)
Har ni även testat att placera installationer i "molnet" som hos Amazon?
Olika behov
Olika webbplatser har olika behov. "Måttligt" med besökare och "normaltrafik" säger inte så mycket om trafiken. Om sajten dessutom har många delar som gör den trög kan det påverka en hel del, hur mycket man bör jobba med prestandan. Jag tycker att alla sajter med från ett par tusen besökare om dagen bör se över en cachningsstrategi.
Med ett par sajter i drift kan du nog tjäna på att drifta själv. Eller snacka med någon som kan hjälpa dig med det. ;) Fördelarna är numera också högre placering på Google, ju snabbare sidladdning du har. Ett ganska stort incitament för de flesta!
Mercury finns, vad jag vet, bara tillgänglig som en AMI i Amazon's AWS-molntjänst.
Tobias Sjösten
ETag är ett sätt för
ETag är ett sätt för webbservern att skapa en unik identifierare för dina statiska filer, vilket den skickar med i HTTP-svaret till webbläsaren. Klienten använder sedan ETaggen för att fråga webbservern om filen ändrats sedan senast. Om inte så kan den lokalt cachade filen användas och om den har ändrats så hämtas den som vanligt, med en ny ETag.
"408cf9-6783-46a2f7e5eecc0" är ETaggen för din logga. Eftersom en ETag (i Apache) kan utgöras av tre olika delar, separerade av -, så ser vi att din webbserver använder dem alla tre. Om du bara använder en maskin så rekommenderar jag att du fortsätter använda ETag men konfigurerar Apache så att endast "modified time" och "file size" används, i din .htaccess eller vhost-fil:
FileETag MTime SizeNästa steg är Expire-headern. Din webbserver skickar just nu bara "Last-Modified", vilket gör att webbläsare blir tvungna att fråga ("If-Modified-Since") efter varje liten fil, vid varje sidladdning. Om du istället slår på mod_expire:
$ sudo a2enmod expires.. och sedan lägger till följande, eller liknande, regler i din .htaccess eller vhost-fil:
<IfModule mod_expires.c>ExpiresDefault "access plus 1 months"
</IfModule>
.. så slipper webbläsaren fråga efter statiska filer mer än en gång! Det kan spara en massa requests och eftersom alla filer sällan laddas ned parallellt, och Internet har en del latency, så kapar du en del request-fläsk.
Gzip slår du på genom att aktivera modulen deflate i Apache 2 eller gzip i Apache 1:
$ sudo a2enmod deflate.. och sedan lägger till följande regel i din .htaccess eller vhost-fil:
<IfModule mod_deflate.c>AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript
</IfModule>
Boost-modulen är riktigt trevlig. Speciellt tillsammans med Views ny-gamla cache-plugin! Det är dock synd att cacha till databasen, så jag rekommenderar att du kollar in CacheRouter-modulen (eller Memcache för den delen) för att kunna stoppa cachen på annat ställe. Till och med filbaserad cache (med CacheRouter) ökar prestandan om du inte har tillgång till något mer fancy, som Memcached eller APC.
CDN är overkill men du skulle kunna kolla in Fredrik Jonssons blogginlägg om statisk filserver. Det du vill uppnå är att skicka filer över en annan domän (samma server går dock bra) eftersom klienterna då slipper inkludera alla cookies som Drupal sätter, i anropet. Kakorna gör requests-paketen mångfaldigt mycket större och det bantar vi gärna ner.
Slutligen bör du kolla över din page.tpl.php och se ifall du inte kan flytta ned javascripten till slutet. Sidan kommer totalt ta lika lång tid att ladda in men besökaren kommer förhoppningsvis känna skillnad eftersom sidan visas snabbare.
Hoppas något av det här hjälper!
Tobias Sjösten
Liten observation
gallery2/main.php är "riktigt" långsam och den verkar generera samma sak hela tiden, några små css statements.
Dessutom satt explicit till no-cache
Tack så hemskt mycket för det
Tack så hemskt mycket för det tobiassjosten!
Ska kolla hur mycket som är påslaget, annars får jag flörta lite med han som har hand om servern :P
@jonne_jvl, cachen borde vara avstängd nu, inte helt säker, får kolla lite :/
Dock så ska det såklart uppstå bieffekter:
* För mig som administratör så är css en lite fel, men dock inte för andra inloggade användare, så det kan ju bero på admin_menu
* Tinymce slutar fungera om man cachar css/js filer, har sökt efter detta, men inte hittat något bra svar :(
dock såg jag att den modulen har bytts till wysiwyg (http://drupal.org/project/wysiwyg), så kanske löser sig, man får hålla tummarna (a)
tack alla såhär långt :D
Jag upplever att det går snabbare nu iaf!
Testa att validera dina
Testa att validera dina css-filer innan du slår på cachen. Om något är fel så kan märkliga saker inträffa när de cachas.
//Pontus Nilsson, Digitalist
Och cron!
Det kan vara värt att nämna att servrar som inte har cron-funktioner kommer få Drupalsajter (och en del annat) att må dåligt efter ett tag. Hörde någon säga att "att inte köra cron är som att inte låta din Drupalsajt gå på toaletten", och sånt kan ju bli jobbigt i längden.
Jämfört med många av de andra tipsen i den här tråden är det ett enkelt tips, men ändå en viktig sak att få med.
//Johan Falk, NodeOne
Rekommenderad för guide!
Den här diskussionstråden innehåller så mycket bra information att den har taggats som en blivande guidesida. Om du vill skriva en guide på svenska Drupalforumet kan detta alltså vara ett bra val!
//Johan Falk, forumadministratör