Improove på Twitter: "improove: Idag hade vi finbesök på KUSen. Andreas Ehn från Wrapp kom och pratade kring deras spännande startup. Vad tycker... http://t.co/DFGJnLOz"
Cache-ning av PHP-lagret för drift av Magento-shoppar är helt kritiskt. Vi jobbade tidigare mycket med eAccelerator och XCache. Detta var innan APC’s storhetstid. APC får nu anses vara mer eller mindre bransch-standard att använda som cache-lager i PHP. Detta gör att de alla otaliga accesstider för sidanrop som uppstår i PHP minimeras. Själva php-filerna cache’as i minnet och belastar aldrig disken i samma utsträckning.
Eftersom Magento är ganska krävande som plattform gör det att APC får ganska stor betydelse på plattformen. Samtidigt kan det vara svårt att veta hur man skall konfigurera APC för access mot systemet. Därför vill jag passa på att tipsa om en bloggpost från Nexcess som har en bra bloggpost i ämnet. Framför allt är det cache-volymen som är viktig där standardkonfigurationen av APC är på 30MB. Nexcess rekommenderar 256MB och i de miljöer vi driftat har vi noterat att APC använder så mycket som 120MB av cache efter bara några timmar i drift.
Efter snart två och ett halvt år av utveckling på Magento-plattformen finns det en del av systemet som vi ofta slitit vårt hår över: cache-ramverket. Så många gånger har så många problem härrört till denna till synes harmlösa funktion. I vissa fall har det orsakat allvarliga fel, framför allt vid klustrade miljöer men även i de enklaste av situationer kan cache-lösningen i Magento ställa till problem. Eftersom den är bristfälligt dokumenterad har det varit väldigt svårt att gå till botten med hur den faktiskt fungerar. Därför har Andreas Holmberg hos oss gjort ett gediget arbete med att grundligt förstå hur denna cache-plattform faktiskt fungerar. Så håll till godo, här har du vår dokumentation över hur cache-strukturen fungerar. Framför allt vill jag belysa kapitel 5 nedan som jag aldrig sett någon riktigt bra sammanställning över.
Bakgrund Magento har allt sedan första versionen fått kritik för att vara ett otroligt resurskrävande sytem. I de första versionerna kunde en sidvisning ta upp till 2 sekunder utan att någon märkvärdig logik utfördes. I grund och botten beror detta på två saker:
PHP i sig är det ganska tungt script-språk att exekvera. Mest på grund av att det är interpreterande och inte använder av bytekod som t.ex. Java eller C#.
Magento har en väldigt komplex struktur och består av flera tusen PHP-filer vilket gör det långt mer krävande att exekvera än t.ex. WordPress eller Joomla.
Man kan säga mycket om detta men jag har alltid fått lära mig att det är bättre att ett system har bra struktur än hög prestanda. Man kan alltid köpa sig bättre prestanda genom cache-ning och dyrare hårdvara men man kan aldrig köpa sig bättre flexibilitet och struktur.
Så vad göra? Jag brukar rekommendera följande åtgärder:
Vår erfarenhet är att punkt 1, 3, 4 & 5 har påtaglig betydelse för prestandan i systemet medan konfigurationerna mer är lämplig vid väldigt stora trafikmängder. Skall man välja PHP-accelerator är vårt förslag APC som vi har bäst erfarenhet av. Alla presterar ungefär likvärdig prestanda men APC har visat sig vara mest kompatibel med uppdateringar av PHP och Apache.
1. Välj rätt hårdvara och operativsystem Att snabba upp Magento handlar väldigt mycket om att snabba upp PHP generellt och därför är följande parametrar viktiga i val av hårdvara för Magento/PHP-plattformar:
Kör aldrig, aldrig Windows som operativsystem. Kör Linux eller Unix-baserade system. Linuxmiljöer vara upp till 6 gånger snabbare än windowsmaskiner.
CPU! Processorn är ofta flaskhalsen i hårdvaran eftersom varje sidvisning skall processa all kod varje gång. Ju fler kärnor desto bättre. Satsa på 8st om du har råd.
Accesstider på hårddiskarna. Eftersom det är så många olika filer som skall läsas in tenderar accesstiderna på hårddisken spela stor roll. Om du har råd: kör Solid State Disks(SSD)
Minne. Ju mer minne desto mer kan acceleratorerna cache’a. Snåla aldrig på detta. 12GB+ RAM kan vara en bra riktlinje.
2. Konfiguration av PHP/MySQL/Apache Här rekommenderar vi Magentos officiella rekommendationer om konfiguration av primärt MySQL.
3. Installera en PHP-accelerator Inga kommentarer. Installera en som passar dig. Kan bli 2-7 gånger snabbare. Detta gäller alla former av PHP-system, även WordPress. Lova att du gör detta och försök reservera minst 256MB minne för acceleratorn.
4. Magento Interna Cache För att möta kritiken om den låga prestandan i systemet har Magento byggt en egen cache-struktur som snabbar upp följande delar:
Configurationsinläsning
Översättningsfiler
Layout-konfigurationen
Block-renderingar
Collection-mängder
Attribut-typerna(EAV)
Webservice-konfigurationen
I Magento Enterprise även Full Page Cache(Egentligen Zend Server Full Page Cache).
Dessa olika cachenivåer har olika betydelse men jag skulle nog ranka de 6 första som viktigast(förutom punkt 8 som är by far den bästa). Något som ibland kan ställa till det betänkligt är den första punkten. Confiugrations-cache eftersom om ändringar i local.xml görs utanför själva systemet nollställs inte cache och därmed inte configuration och dina ändringar slår inte igenom. I vanliga fall är detta inte speciellt komplicerad utan det räcker med att radera filerna i /var/cache-mappen men vi skall senare återkomma till varför detta kan vara minst sagt komplicerat. Detta har gjort att vi på allvar har funderat på att bygga en modul som utesluter local.xml ur configurations-cachen eftersom detta skulle säkerställa att vi alltid har god kontroll över konfigurationen, något som annars har ställt till det för oss. Man vill dock inte stänga av konfigurationen helt och hållet eftersom det inte bara är local.xml som cache’as utan även alla modulers config.xml och system.xml-filer. Däremot kan det vara ett tips att stänga av just denna cache när man laborerar med inställningarna i systemet.
5. Zend Frameworks cache-struktur Detta är den del av systemet som ställt till med mest problem för oss eftersom Magento använder sig av den utan att någonstans dokumentera hur den faktiskt fungerar. Eftersom Magento till stora delar är byggt ovanpå Zend Framework finns stor potential i att använda deras olika cachemoduler men då det sällan varit speciellt tydligt hur det faktiskt fungerar kan det dels ställa till det för dig då många default-inställningar kickar in som man sällan känner till.
Zend Framework har några väldigt viktiga funktioner som man bör känna till:
Full Page Cache
Zend Two Level Cache
DB-cache
Memcache-cache
5.1. Zend Two Level Cache
Den sistnämnda läser man bland om i forum på nätet eftersom den kan ha väsentlig påverkan på prestandan i systemet. Detta eftersom den kan ersätta fillagring av datacache med lagring direkt i minnet. Dels är det bra för prestanda på en lokal maskin men kan vara direkt avgörande när man bygger ett serverkluster. Jag vill understryka att detta är riktigt, riktigt bra men ofta väldigt bökigt att konfigurera och använda. Detta främst på grund av default-inställningar i Zends Two Level Cache. Zends Two Level Cache bygger på att man använder en så kallas ”fast backend” och en ”slow backend”. Principen är att ”fast backend” andvänds i första hand och ”slow backend” i andra hand. Detta gör att man kan starta om en ”fast backend”-server som t.ex. memcache utan att det påverkar driften och stabiliteten i systemet. Problemet med detta är att om man konfigurerar memcache som primär cache(fast backend) UTAN att konfigurera en slow backend så blir lokal fillagring per automatik default ”slow backend” och eftersom ”slow backend” i regel innehåller fler nycklar än ”fast backend” så blir denna inte bara en failover utan också ett cache-steg som faktiskt alltid kommer att användas om än inte alltid.
Detta resulterar i ganska märkliga beteenden när du konfigurerar t.ex. ett serverkluster med 2 webbfrontar och använder en central Memcache-server som ”fast backend” men inte explicit konfigurerar en ”slow backend”. Då kommer en del av cache-nycklarna lagras central på memcache-servern och några lokalt i filerna på respektive webbfront. Därför är det av största betydelse att inte bara konfigurera ”fast backend” utan också definiera ”slow backend” och då skall denna också vara någon variant av central lagring. T.ex. databaslagring eller en central filmapp på en gemensam filserver. Tänk på här att om du har memcache-som cache-steg och har Configuration-cache påslaget så lagras numera local.xml-filen i memcache-servern och läses inte automatiskt ut från disk när du gör ändringar. Det räcker inte heller att radera innehållet i /var/cache utan du bör också för säkerhetsskull invalidera memcache-servern(eller rent av starta om den) och göra samma sak med DB-cache om det används. Detta blir ofta väldigt komplext och svåröverskådligt varav rekommendationen att stänga av Configuration-cache när du jobbar med inställningarna.
Tro mig. Detta kan ställa till stort förtret och det är mycket märkligt att Magento inte dokumenterat detta bättre officiellt. Som Enterprise-kund kan man dock få tillgång till en ganska hygglig sammanställning som man får tillgång till som Enterprise-kund. Vill du ha ett exempel på hur man gör en bra konfiguration av slow resp. fast backend så kan du se detta i vårt exempel här. Nyttig läsning och det tog ett tag innan vi fick allt riktigt rätt.
5.2. Zend Full Page Cache
Denna funktion är lite av den heliga gralen när man skall uppnå prestanda i Magento-installationer. Denna funktion följer med Magento Entprise och betyder helt enkelt att all output från en sida cache’as direkt i minnet på servern och det innebär att renderingarna sällan tar längre än 50 millisekunder. Denna cache slutar dock gälla så fort man lägger en produkt i varukorgen eller loggar in t.ex. Då slås den av och renderar sidorna som vanligt. I nyare versioner av Magento Enterprise är dock denna funktionalitet ytterligare integrerade i Magento och fungerar så att den bara stänger av Full Page Cache för vissa template-block i renderingen av sidor vilket betyder att prestandan ökar betänkligt även när man lägger produkter i varukorgen.
Rent teoretiskt kan du använda Zend Full Page Cache utan att köpa Magento Enterprise. Då genom att köpa en licens(från €1200) av Zend Server som är den programvara som faktiskt innehåller denna teknik. Det är delvis denna Magento säljer när man köper Magento Enterprise. Då blir den lite klumpigare framför allt jämfört med de senare versionerna av systemet där FPC är så sömlöst integrerat i Magento. Hur som helst. En direkt avgörande funktion om du på allvar vill få upp prestandan i systemet.
6. Memcache för sessionshantering
Till sist kan du boosta prestandan i systemet genom att lagra sessioner i memcache istället för på disk. Jag har varit med om sajter som haft 1.5 miljoner sessionsfiler i /var/session-mappen vilket uppstår när man har stora mängder besök, även om de inte handlar något. I mindre sajter märks inte detta i någon större utsträckning men så fort trafikmängderna ökar är det viktigt att lagra sessionvärdena mer effektivt. Det gör man enklast genom att flytta lagringen av sessioner från fil till memcache. Instruktioner för detta finns även det i vår exempelfil.
En varning dock: vi har vid ett par tillfällen varit med om att admin-inloggningen slutar fungera när man använder memcache för lagring av sessioner. Vi har inte något intelligent svar på varför detta inträffat ibland annat än att vi misstänker problem med konfigurationen. Vår bifogade exempelfil fungerar dock.
Jag vet att det råder lite delade meningar om molnet men jag måste säga att jag fascineras av idén om data på kran. D.v.s. att man betalar för det man behöver istället för att köpa datorkraft i fysiska serverpaet. Det har ju funnits några alternativ ett bra tag nu som t.ex. CentOS för Linux o.s.v. Men det är först när det blir så enkelt som Amazon gör det som det blir riktigt, riktigt intressant. I den här filmen(töntig musik men bra instruktioner) nedan kan du se hur man kontrollerar sin serverpark direkt från Firefox. Riktigt läckert.
Nästa grej blir att se om det går att installera Magento Commerce på en sån här miljö. Skall bli intressant att se vilken prestanda den kan leverera i så fall.
