CentOS / Directadmin server optimaliseren

[eerdepeer]

Ik werk met verschillende VPS'en en een eigen VPS development omgeving. Het draait allemaal op CentOS (meerendeel CentOS 6.x) en DirectAdmin custombuild. De VPS'en zijn voornamelijk geschikt voor "gewone websites" en niet geoptimaliseerd voor zwaardere shops als Magento.

Behalve de development omgeving, die draait op een i7 met SSD en 12GB RAM toegewezen. Echter is deze omgeving bijzonder langzaam. De homepage (die in de voor Magento geoptimaliseerde VPS omgeving in 2 seconden laadt) doet er op de dev server wel 15 tot 20 seconden over.

Het lijkt me dat de server binnen 5 seconden de pagina zeker zou moeten kunnen laden. Daarom denk ik dat er iets aan de hand is, of dat ik verkeerde instellingen, voor Apache, MySQL, etc. Hoe kan ik de bottlenecks opsporen en elimineren?

Dit heb ik al geprobeerd (maar de meeste acties zijn zonder noemenswaardig effect):

1. PHP geupdate
2. MySQL geupdate naar
3. OPcache aangezet
4. APC geïnstalleerd
5. Firewall (LFD/CSF) tijdelijk uitgezet
6. Vrij geheugen nagekeken (er is zat vrij)
7. Swap geheugen wordt niet gebruikt
8. Er is zat schijfruimte

CentOS release 6.5 (Final) draait in de laatste versie van Virtualbox op een OS X server.

Huidige versies:
Apache 2.4.10 Running
DirectAdmin 1.45.4 Running
Exim 4.76 Running
MySQL 5.6.19 Running
Named 9.8.2rc1 Running
sshd Running
dovecot 2.2.13 Running
pure-ftpd 1.0.36 Running
Php 5.5.14 Installed

[Kevin Bentlage]

Ik zou beginnen om APC (of OPCache) uit te schakelen aangezien het beide Object Cachers zijn, ze doen dus allebij hetzelfde en kunnen daarom misschien conflicteren met elkaar. Daarnaast wordt APC officieel niet meer ondersteund op PHP 5.4 en hoger en kan voor problemen zorgen (ik zie dit de laatste tijd veel gebeuren i.c.m. Magento shops en de nieuwere PHP versies).

Verder kun je eens kijken om in je php.ini de memory_limit en max_execution_time te verhogen (als dit nog niet gebeurd is).

Daarnaast lijkt me 15 - 20 seconden wel heel erg lang, en duid dit eerder op een probleem in de code of een library die iets probeert te laden wat niet lukt. Wat wordt er allemaal op de homepage uitgevoerd aan DB queries etc? Misschien kun je daar eerst eens naar kijken. En heb je al in de Apache error_log gekeken of je vreemde errors voorbij ziet komen waar je iets mee kan?

Verder is het voor ons handig om te weten of de standaard cache van Magento aan of uit staat? Dit kan ook aanzienlijk schelen.

[eerdepeer]

APC staat uit sinds de upgrade naar php 5.5.14 met OPcache.

De settings van wat je aanhaalt staan nu op:
memory_limit = 512M
max_execution_time = 1000

Ik heb geen idee of dat nog (veel) hoger moet staan met 12GB toegewezen RAM.

Het klopt dat het misschien niet helemaal een eerlijke vergelijking is, aangezien caching (omdat het op een development omgeving staat) uitgeschakeld staat. Maar de SSD en de vele malen hogere hoeveelheid RAM zou er volgens mij wel voor moeten zorgen dat het een eerlijkere vergelijking is.

In apache error log zie ik wel diverse meldingen die naar php pagina's van de shop verwijzen met "Message Cached script" en "Message Added key". Bijv:

Fri Aug 29 16:02:15 2014 (5266): Message Cached script '/home/**/domains/**/public_html/app/design/adminhtml/default/default/template/system/config/js.phtml'
Fri Aug 29 16:02:15 2014 (5266): Message Cached script '/home/**/domains/**/public_html/app/design/adminhtml/default/default/template/system/shipping/applicable_country.phtml'

Verder herhalende notices, zoals:

[Fri Aug 29 16:06:01.946931 2014] [mpm_prefork:notice] [pid 5433] AH00169: caught SIGTERM, shutting down
[Fri Aug 29 16:06:03.003733 2014] [ssl:warn] [pid 5540] AH01909: www.example.com:443:0 server certificate does NOT include an ID which matches the server name
[Fri Aug 29 16:06:03.005337 2014] [suexec:notice] [pid 5540] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Fri Aug 29 16:06:03.053858 2014] [auth_digest:notice] [pid 5541] AH01757: generating secret for digest authentication ...
[Fri Aug 29 16:06:04.003834 2014] [ssl:warn] [pid 5541] AH01909: www.example.com:443:0 server certificate does NOT include an ID which matches the server name
[Fri Aug 29 16:06:04.004440 2014] [lbmethod_heartbeat:notice] [pid 5541] AH02282: No slotmem from mod_heartmonitor
[Fri Aug 29 16:06:04.004528 2014] [:notice] [pid 5541] mod_ruid2/0.9.8 enabled
[Fri Aug 29 16:06:04.024015 2014] [mpm_prefork:notice] [pid 5541] AH00163: Apache/2.4.10 (Unix) OpenSSL/1.0.1e-fips PHP/5.5.14 configured -- resuming normal operations
[Fri Aug 29 16:06:04.024082 2014] [core:notice] [pid 5541] AH00094: Command line: '/usr/sbin/httpd -D SSL'

[xentos]

Je kan een tester gebruiken op je website om te weten wat traag zit te laden. Het kan zijn dat je pagina bijvoorbeeld snel laadt en de statische bestanden juist slecht, of juist andersom.

Een thread hoort opnieuw te starten aangezien ze klaar staan om een actie uit te voeren en daarna opnieuw gestart wordt voor de volgende actie.

Het lijkt er ook op dat de server certificaat is ingesteld, normaal kan het geen kwaad tenzij je https gebruikt.

Persoonlijk denk ik dat er een compabiliteit probleem is met een module. Je kan proberen de slotmem module te deactiveren en apache/php opnieuw te starten
------

Uit ervaring kan ik zeggen dat een dev server op bijvoorbeeld Windows veel langzamer is dan een productie server op bijvoorbeeld Linux. Dit kan een paar tot honderd keer zijn. Ik heb zelf een project gehad waarbij efficiëntie van het script belangrijk was, en op een normaal directadmin installatie(zonder extra configuratie) was het 20x sneller. Deze heeft geen SSD tegenover de PC

Je kan een kijkje nemen bij je configuratie omdat MYSQL wellicht een domein pointer die problemen heeft. Als het database op lokaal staat probeer eens '127.0.0.1'

APC staat uit sinds de upgrade naar php 5.5.14 met OPcache.

De settings van wat je aanhaalt staan nu op:
memory_limit = 512M
max_execution_time = 1000

Ik heb geen idee of dat nog (veel) hoger moet staan met 12GB toegewezen RAM.

Het klopt dat het misschien niet helemaal een eerlijke vergelijking is, aangezien caching (omdat het op een development omgeving staat) uitgeschakeld staat. Maar de SSD en de vele malen hogere hoeveelheid RAM zou er volgens mij wel voor moeten zorgen dat het een eerlijkere vergelijking is.

In apache error log zie ik wel diverse meldingen die naar php pagina's van de shop verwijzen met "Message Cached script" en "Message Added key". Bijv:


Verder herhalende notices, zoals:

[ju5t]

Waarom zou je de memory_limit en max_execution_time verhogen? Begrijpen jullie wel wat dit doet? Wat los je daarmee op? Als je script niet zoveel geheugen nodig heeft zet je hiermee de deur open voor mogelijke memory leaks en max_execution_time is natuurlijk nooit de oplossing voor een script wat 15 seconden loopt. Die 1000 seconden had ik als ik jou was zo snel mogelijk terug geschroefd naar de standaard 30 seconden. Meer heb je 99% van de tijd écht niet nodig.

APC is trouwens gewoon beschikbaar voor PHP 5.4, pas vanaf 5.5 is dit vervangen door opcache, maar dat maakt nu niet uit. Er zitten trouwens nog wel wat bugs in opcache waardoor sites soms fouten geven, maar die moet je tegen komen in de log files.

Probeer eens met iets als strace te kijken wat er precies gebeurd als de homepage geladen wordt.

* Misschien staan de rechten op je var/cache of var/session mappen niet goed.
* Misschien is de caching in Magento juist een fundamenteel onderdeel van de site. Menu queries kunnen heel zwaar zijn.
* Misschien is je database server niet optimaal ingericht.
* Misschien laad je teveel Apache modules in en is daardoor het geheugen gebruik te hoog.
* Misschien is er wel hardware stuk.

Het kunnen 1001 verschillende dingen zijn, maar voor je kunt ergens iets over kunt zeggen is het goed om te zien waar een proces op hangt. Met strace kun je daar inzicht in krijgen, zeker op een dev server.

[eerdepeer]

Uitstekend, ik heb max_execution_time weer teruggezet naar 30 en ga kijken wat ik met strace kan doen.
Als ik top open in terminal en dan de site laadt, dan zie ik enkel dat apache 100% cpu inneemt. Hij lijkt het daarmee zwaar te hebben. Cache is sowieso een essentieel onderdeel van Magento, maar het lijkt me dat er nog wel performance winst uit valt te halen met de hardware die ik gebruik.

[chielsen]

Je kan ook new relic installeren. kan je heel veel data uit halen. Helaas de gratis versie niet zo heel veel, maar toch al best wat.
Vraagje, als je de mysql gegevens verkeerd invult, hoe vlot krijg je dan de foutpagina te zien?

[Netbulae]

Heb je al naar de serverstatus pagina gekeken van apache (mod_status)? Kan je zien wat er gebeurt op je apache server:

http://adityo.blog.binusian.org/?p=328

[RichardVD]

Ga het bij Magento niet alleen zoeken aan de hostingkant maar optimaliseer ook de Magento shop zelf. Juiste configuratie, geen brakke modules en een template die goed in elkaar zit doet wonderen.

[frajaweb]

Mijn ervaring is dat de MySQL de bottleneck is. Zeker bij grotere vragen kan dit lang duren. De standaard settings zijn erg beperkt. Je kan eventueel de logging aanzetten, dan kun je zien hoe lang een query in beslag neemt.

[Netbulae]

Mijn ervaring is dat de MySQL de bottleneck is. Zeker bij grotere vragen kan dit lang duren. De standaard settings zijn erg beperkt. Je kan eventueel de logging aanzetten, dan kun je zien hoe lang een query in beslag neemt.

Makkelijk te fixen door MySQLTuner te draaien nadat je minimaal 24 uur de boel hebt draaien. Wel een beetje load genereren natuurlijk....

[Hosted]

Probeer anders eens Varnish (relatief eenvoudig en zorgt vaak voor een geweldige optimalisatie).

[Ramon Fincken]

Probeer anders eens Varnish (relatief eenvoudig en zorgt vaak voor een geweldige optimalisatie).

Varnish is erg leuk, maar is voor shops en andere zaken toch wel even andere koek met instellen. Tis geen klik en klaar wondermiddel.

[Hosted]

Varnish is erg leuk, maar is voor shops en andere zaken toch wel even andere koek met instellen. Tis geen klik en klaar wondermiddel.

Eigenlijk wel en is het vrij simpel, kijk eens naar http://www.unixy.net/varnish/ (als je wat wilt betalen natuurlijk).

[eerdepeer]

Bedankt voor de tips tot nu toe! Ik ben hier na mijn vakantie weer mee aan de slag gegaan.

Zoals RichardVD aangaf helpt het enorm om in Magento zelf ook eea te tweaken. Als ik caching en compiling aan zet, dan wordt schiet de waiting time omlaag naar onder de 1 seconde. Ik vraag mij af of dit niet nog verder te tweaken valt?

Verder heb ik New Relic geïnstalleerd en dat ziet er heel netjes uit. Het enige is dat ik geen echte bottelnecks kan vinden. (zie screenshot) Er is geen CPU of netwerk die naar 100% piekt als ik zwaardere taken uitvoer. Ik ga eerst maar eens mod_status instellen om te kijken of ik daar wijs uit wordt.