Performance Tuning MySQL PHP Joomla
Houd er rekening mee dat de doorsnee shared-host niet is ingericht op databases die groter zijn dan enkele (tientallen) Megabytes. datafeeds verbruiken circa 1 Mbyte per 1000 items. Als de tabel met items te groot wordt ga je dat in de performance merken, http requests duren langer, de server krijgt ze niet weggewerkt en de http-processen stappelen zich op. Met name mod_datamenu's (de menu's/zoek versies) kunnen vrij zware query's opleveren. In het minst ergste geval schopt je hoster je de deur uit, erger is dat je bezoekers afhaken.
Op een goede shared host moet het geen probleem zijn websites met 20-40 duizen items te hebben.
Hieronder een rijtje met tips. Met (shared) is aangegeven of deze aktie op een shared host mogelijk is. De meeste tips zijn niet joomla-datafeeds specifiek maar algemeen te gebruiken.
In onderstaande wordt uitgegaan van de standaard configuratie van joomla met de prefix jos_, pas dit eventueel aan.
Website splitsen (shared)
Het splitsen van de website in meerdere is een oplossing om de database klein te houden, helaas ondersteund joomla multi-site niet lekker ( er zijn componenten voor te koop ) dus heb je hier meerdere keren onderhoud.
Joomla cache (shared)
Wat goed helpt is het inschakelen van de cache van joomla. Meestal is het inschakelen van cache voor modules geen goed plan omdat joomla dit wat knullig cached ( niet pagina afhankelijk ). De caching van mod_datamenu houdt er rekening mee dat elke pagina een andere (en zelfs meerdere) module-inhoud toont. Echter omdat de feeds uit heel veel items bestaan met heel veel menu's en submenu's komen er ook heel veel bestanden in de cache te staan. Hier heb je dus weer flink ruimte nodig op schijf. En er zijn ervaringen dat de file cache weer langzaam wordt als er veel bestanden instaan.
waarschuwing : Op een omvangrijke site (veel menu's) kan de cache heel groot worden ( Gig's) er is dan kans dat je in de problemen komt om de cachee weer te wissen !!!
sessions op none (shared)
In de standaard installatie slaat joomla de sessions op in de database. Dat zijn een aardige hoeveelheid lees en schrijf akties. Je kunt de session ook file based maken door de setting op 'none' te zetten. Dan slaat php de sessies op de disk op. Dat kan per saldo voordeliger zijn.
Nog mooier zou zijn de sessies voor de frontend uit te schakelen, of en hoe dit kan moet nog uitgezocht worden. In feite is heel het sessie verhaal onzinnig zolang men niet inlogt ( ok, ok er zijn modules en plugins die het wel nodig hebben....)
php zlib compressie (shared)
php heeft de mogelijkheid om de content (de genereerde html) te bufferen en voor versturen te comprimeren. Dit heeft het voordeel dat er minder bandbreedte nodig is. Dat is ( was met huidig breedband ? ). Als je bij je host op een budget zit met betrekking tot bandbreedte kan het een optie zijn zlib aan te zetten om te sparen.
Keerzijde is dat bij output buffering die hele content op de server blijft totdat alles gereed is, bij ongebufferde output gaat de zaak meteen de deut uit, er is dus minder geheugen nodig. Daarnaast is er voor het comprimeren op het einde extra performance van de server nodig. Het kan dus helpen zlib compressie uit te zetten.
Bij websites als deze bestaat bovendien een groot deel van de data uit niet php output ( javascript, afbeeldingen, stylesheets) en het is maar de vraag of je met zlib compressie veel bespaart.
- in php.ini zlib.output_compression = On/Off
- in .htaccess php_flag zlib.output_compression on/off
Een alternatieve manier om compressie toe te passen is via de apache server zelf. Terwijl er zelf ervaring zijn met een negatieve invloed op de performance bij php-zlib compressie, zijn er op dezelfde server positieve ervaringen met AddOutputFilterByType DEFLATE
MySQL Indexen optimaliseren (shared)
Als mod_datamenu gebruikt wordt om content aan het dataitems menu te koppelen (artikel variant) dan voert de module een zoekaktie uit op de alias in jos_content hier is geen index op:
ALTER TABLE `jos_content` ADD INDEX ( `alias` ) ;
mysql
De belangrijkste parameter om de performance van mysql te beinvloeden is geheugen. Hoe meer geheugen hoe meer mysql in geheugen kan cachen en hoe beter de performance wordt. Aangezien geheugen akties nog steeds een factor sneller zijn dan lezen en schrijven van de harddisk. Daarnaast is het zaak het geheugen binnen joomla goed toe te wijzen belangrijke parameters:
-
mysql key_buffer
-
mysql query_buffer
-
mysql table_cache
-
delay_key_write
mysql verdere tips
Nog een paar opties die je kunt overwegen om met name ruimte te besparen:
- skip-networking
- skip-bdb
- skip-innodb
Waarschijnlijk zijn er bij de installatie van MySQL een aantal voorbeeld configuraties meegeinstalleerd. zoek op de hardeschijf of google op my-huge.cnf my-large.cnf. Prima inzicht in de mogelijkheden, met aardig wat uitleg
mysql slow queries
Interresant is het om te weten waar het misgaat. MySQL heeft de mogelijkheid queries die erg lang nodig hebben te loggen met behulp van de volgende opties. In de server status via phpmyadmin kun je trouwens zien hoeveel slow queries er zijn.
- log_slow_queries
- log_long_format
En om te kijken welke queries geen index gebruiken en dus potentieel traag zijn:
- log-queries-not-using-indexes (mysql > 4.1)
Met laatste parameter kan er een flinke hoeveelheid langskomen, wellicht geen goed idee deze logging altijd aan te hebben
Waar de log-file dan staat is afhankelijk van je omgeving
my.cfg voorbeeld
Onderstaande configuratie voor mysql houd databases met bijna 200.000 items draaiende op een VPS met 786MBytes geheugen. Af en toe is het wat krap.
{include_code_listing /var/www/www.affiliatefeeds.nl/images/code/my-cfg-89.txt}
accelerators (shared ? )
Er zijn verschillende php accelerators, Zend, fastcgi en meer. Dit zou allemaal prima smaen moeten werken met joomla+datafeeds maar er is nog geen ervaring mee.
Eigen Hosting
Aan de mysql parameters sleutelen mag op een shared host meestal niet. De oplossing is dan een VPS of Dedicated Server.
Een eigen server is ook de oplossing als je joomla cache erg veel ruimte in beslag neemt.
En verder
als het nog wilder wordt ga dan denken aan meerdere servers. Aparte server voor mysql, mysql database splitsen over meerdere schijven, andere database engine (InnoDB), meerdere apacher servers, squid als proxy/load balancer. Maar bovenal meer geheugen..
Heb je tips, kommentaar of aanvullingen? Graag !
