Drupal 5 och cachning
På en Drupalsajt jag jobbat med uppstod problem rätt omgående när den gick live. Vi fick "Unable to connect to database server" på grund av "User xxx already has more than 'max_user_connections' active connections.". Tanken var att slå på Drupal 5:s inbyggda cachning, men allt stressades fram så det hanns inte med precis i starten.
Sajten i fråga har bara anonyma besökare, så vi räknade med att cachningen skulle hjälpa oss och det gjorde den när vi väl slog på den. Lite för bra dock. Vi hade nämligen en del PHP-kod i block som anropade andra system för informationsinhämtning och vi inkluderade filer i mallarna. Och allt detta cachades alldeles för bra.
Jag har försökt gräva en del i hur man ska lösa detta bra, men inte hittills hittat någon klockren lösning. Helst skulle vi vilja kunna styra så att vissa inkluderingar och vissa block inte cachas alls. Däremot ska det mesta av innehållet i själva Drupal i övrigt vara cachat så långt det går (t.ex. alla Views som plockar fram information ur noder).
Vi kan förstås lösa det genom t.ex. iframes eller - som vi redan delvis gör idag - via javascript-anrop på sidan när den väl laddas hos besökaren, så kopplingen mot Drupal aldrig sker. Men smidigare vore det att enkelt kunna exkludera vissa bitar helt enkelt, så man får en något sämre cachning, men ändå långt bättre än ingen cachning.
Någon som har god erfarenhet kring detta och har några goda råd?
Ical feed
max_user_connections
Vill bara poängtera att cachen inte kommer att minska antalet anslutningar som görs till MySQL (såvida ni inte använder filecache eller memcache). Däremot kommer förmodligen varje anslutning att vara öppen under kortare tid, så det totala antalet anslutningar vid en bestämd tidpunkt bör ändå bli lägre, vilket kan visa sig lösa problemet.
Jag har ingen färdig lösning för problemet med dynamiska block och sidcachen, men en tanke jag fick var om man på något sätt kan få applikationen som genererar innehållet i de blocken att meddela Drupal när innehållet ändras så att cachen kan rensas. Men det bygger på att det är innehåll som är relativt statiskt.
Ah, näe vi använder bara
Ah, näe vi använder bara Drupal 5:s inbyggda cache (ställt på "Normal"), den räcker bra för tillfället upplever vi. Jag har inte djuptdykt i hur den fungerar (t.ex. visste jag inte det där med att den inte minskar antalet anslutningar - men vi har i alla fall inte råkat på problemet vi hade först, efter att vi slog på cachen).
Jag var lite inne på samma spår, men en del av informationen behöver vara helt aktuell (t.ex. kollar vi om besökaren är inloggad i ett annat system på samma sajt) så vi lutar åt en javascript-lösning för tillfället, alternativt en iframe, för den informationen eftersom det är kritiskt att den blir helt rätt.
Tack för det snabba svaret.
Uppföljning
När det gäller cachade sidor och inkluderad kod löste vi det med ett litet js-anrop som laddar in koden som måste vara icke cachad.
Men något prestandaproblem fanns aldrig i Drupal. Sidorna ligger på en kraftfull server med mycket minne, så vi var förvånade över att det blev problem alls. Det visade sig dock att problemen främst kom från vBulletin-forumet på samma sajt. Vilket var udda för det hade fungerat bra innan. Efter ytterliggare problem och mer felsökning hittades att det var sessiontabellen i MySQL som inte tömdes korrekt och när den blev full fick man max_connections och sen gick hela servern ned.
Skälet till det i sin tur var att cron-scriptet inte kördes som det skulle, som skulle rensa tabellerna regelbundet. Det visade sig efter ytterliggare en tids felsökning att vår kod för omdirigering i .htaccess-filen i rooten också skrev om ett anrop till cron-filen, så istället för att /cron.php kördes (vilket var en del av vB) så kördes /drupal/cron.php eftersom vi styrde om alla generella förfrågningar till /drupal/ där själva drupalfilerna ligger. När vi skrivit ett undantag för cron-filen löste sig problemen och allt återgick till det normala. Puh. :)
Det känns i alla fall bra att Drupal inte var den skurken det först verkade som, för jag hade inte väntat mig några större prestandaproblem, så jag blev förvånad när sajten gick ner.