[PHP] (Laravel) Apache (op VPS) 6x trager dan local php

[afraca]

Ik heb hier een leuke applicatie gebouwd in Laravel. Er moet best wel het een en ander ingeladen worden, en een framework komt natuurlijk altijd met wat overhead. M'n setup voor lokale ontwikkeling is:

-- server via 'php artisan serve' (dus ingebouwde php server)
-- database is mariadb , niks spannends aan gebeurt, default instellingen

sessions en cache allemaal simpelweg via files.

Voor een homepage view krijg ik met Barry's debugbar dan een application response van 115ms meestal ongeveer. Dit is dus los van de afbeeldingen en dergelijke. Via de Chrome developer tools zit de applicatie op 120ms , en het geheel met afbeeldingen en dergelijke op 1.32 seconde.

Dan denk je al natuurlijk, wtf doe je met die afbeeldingen.... Tja, ik ben ook maar een backend-developer

Nu het verhaal op de server dus.
Applicatie (via developer tools in browser): 650ms ongeveer (weinig schommeling)
Totaal: tussen de 1.8 en 2.2 seconden.

Major bummer natuurlijk. Apache komt natuurlijk met een berg aan spannende opties, die het allemaal moeilijk te vergelijken maken. Maar je verwacht dat zo'n dedicated server wel wat sneller zou zijn. Dus wat zit allemaal in die htaccess dan? Bovenste deel is van:
https://github.com/h5bp/s...lob/master/dist/.htaccess

code:

# ------------------------------------------------------------------------------
# | ETag removal                                                               |
# ------------------------------------------------------------------------------

# Since we're sending far-future expires headers (see below), ETags can
# be removed: http://developer.yahoo.com/performance/rules.html#etags.

# `FileETag None` is not enough for every server.
<IfModule mod_headers.c>
    Header unset ETag
</IfModule>

FileETag None

# ------------------------------------------------------------------------------
# | Expires headers (for better cache control)                                 |
# ------------------------------------------------------------------------------

# The following expires headers are set pretty far in the future. If you don't
# control versioning with filename-based cache busting, consider lowering the
# cache time for resources like CSS and JS to something like 1 week.

<IfModule mod_expires.c>

    ExpiresActive on
    ExpiresDefault                                      "access plus 1 month"

  # CSS
    ExpiresByType text/css                              "access plus 1 year"

<*knip* zie link hierboven> 

    ExpiresByType image/svg+xml                         "access plus 1 month"

</IfModule>

# ------------------------------------------------------------------------------
# | Filename-based cache busting                                               |
# ------------------------------------------------------------------------------


<IfModule mod_rewrite.c>
    <IfModule mod_negotiation.c>
        Options -MultiViews
    </IfModule>

    RewriteEngine On


    # Remove prefix from asset files
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^[a-f0-9]{10}(.+)\.(css|js|eot|ttf|woff2?)$ $1.$2 [L]

    # Redirect Trailing Slashes...
    RewriteRule ^(.*)/$ /$1 [L,R=301]

    # Handle Front Controller...
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^ index.php [L]
</IfModule>

<Limit DELETE>
  Order deny,allow
  Allow from all
</Limit>

Niet hele spannende dingen dus. Maar ik hoor u denken, waar is de gzip compression bijvoorbeeld. Nou, die staat server-wide aan, geverifieerd met externe tools.

Dus wat mis ik hier?


---- edit:
Volgens Google Pagespeed tools is er op die afbeeldingen nog 38kb te besparen overigens.

--- edit2:
De database op de server draait op dezelfde machine. Het is een vps bij cloudvps.

[Barryvdh]

Staat opcache aan? Php artisan optimize gedraaid?

[afraca]

Optimize gedraaid. En opcache zou toch niet een verschil tussen lokaal en live moeten opleveren? Ik zal zo even een edit plaatsen als ik het antwoord erop heb.

[Barryvdh]

afraca schreef op maandag 15 juni 2015 @ 12:13:
Optimize gedraaid. En opcache zou toch niet een verschil tussen lokaal en live moeten opleveren? Ik zal zo even een edit plaatsen als ik het antwoord erop heb.

Wel als die lokaal wel aan staat en op productie niet

Maar kunnen natuurlijk meer factoren zijn, zoals hoeveelheid geheugen, snelheid van de schijf/CPU etc.

[Jogai]

Lokaal gebruik je een SSD? En op je vps niet?

[afraca]

Hehe, dat is zeker waar. Maar op beide stond het dus uit.

En wat betreft hardware factoren: geheugen en cpu is geen issue, voor beide machines is nog bergen van speelruimte. Op beide systemen is voor zover ik weet geen SSD.

edit: voor het timen heb ik live ook even op 'local' environment gezet, waarmee ook de Debugbar geladen word.

edit2: work - in -progress.

[ Voor 38% gewijzigd door afraca op 15-06-2015 13:32 ]

[Barryvdh]

Trage disk I/O waarschijnlijk. Je kan om simpel te testen eens wat die() breakpoints zetten op bepaalde punten (zoals voor het inladen van compiled.php, net erna etc), totdat je iets raars tegenkomt qua timing.

Maar heb je Opcache nu aangezet? Want dat scheelt wel veel. Zeker als je het compiled.php bestand gebruikt, want dat zal dan gecached worden, in plaats van 100 losse bestanden inladen vanaf schijf.

Het kan natuurlijk ook zijn dat er iets anders heel traag is (mysql verbinding ofzo), maar dat zou je dan bij andere sites ook wel hebben waarschijnlijk.

[afraca]

Booting kost 440ms op de vps. Ik heb wel een compiled.php , dus daar had ik eerlijk gezegd dan best wel een speedup mee verwacht als jouw hypothese klopt.

Ik ben nu bezig met opcache aangeslingerd krijgen, ik zal binnenkort rapporteren hoeveel effect dat heeft.

M'n collega's zijn niet zo heel erg van 'best practices' maar meer 'get shit done', ik hoop dat ik Laravel nog snel krijg anders gaat het nog vrij boeiend worden.

[afraca]

Spannende boel. Opcache sloopt de hele Laravel site....

Ik heb het geisoleerd tot dit:
bestand: bootstrap/start.php

PHP:

$app = new Illuminate\Foundation\Application;

Die laat de applicatie stil crashen.

(Chrome: ERR_EMPTY_RESPONSE )

edit: dat is niet helemaal waar, nu komt hij er wel opeens langs.... dit is vervelend...

[ Voor 15% gewijzigd door afraca op 15-06-2015 15:09 ]

[Barryvdh]

afraca schreef op maandag 15 juni 2015 @ 15:06:
Spannende boel. Opcache sloopt de hele Laravel site....

Ik heb het geisoleerd tot dit:
bestand: bootstrap/start.php

PHP:

$app = new Illuminate\Foundation\Application;

Die laat de applicatie stil crashen.

(Chrome: ERR_EMPTY_RESPONSE )

Wel dezelfde PHP versie/modules ook?

[afraca]

Op de server 5.5.25 , lokaal 5.6.3 (zonder opcache)

Het probleem is eigenlijk een seg fault met:
opcache zend_mm_heap corrupted

Veel antwoorden zeggen dat je het moet uitschakelen voor CLI. Dat heb ik al gedaan, maar in de applicatie blijft de segmentation fault.

edit: Het blijft een boeiende situatie..... Door een bugged terminal in phpstorm was de ini in eerste instantie geschreven met een memory_limit van 12mb voor Opcache. Het boeiende is dat als de memory limit gehaald word, alle sites die NIET Laravel gebruiken blijven doorwerken.

Dat kan te maken hebben met het groot aantal bestanden dat Laravel inlaad, of de relatief grote stack size...... Nu de limit naar 256 gezet, maar zonet ging dat weer niet goed. Toen maar een 'fast_shutdown=1' uit de ini gehaald, geen idee of het nu goed gaat.

maar wat betreft de snelheid:
die was ongeveer naar 350ms gedaald. Beter dus, maar nog niet heel fascinerend snel...... In de compile.php heb ik nog een stuk of 8 bestanden gezet, maar weet niet of dat echt zoden aan de dijk zet.

edit: omdat de applicatie zelf bij het timen nog steeds 400ms gebruikt, en de applicatie identiek is, zal het wel aan de hardware liggen, de harde schijf in dit geval. Ik zal eens informeren hierover, maar denk niet dat daar veel invloed op uit te oefenen is..

[ Voor 70% gewijzigd door afraca op 15-06-2015 17:22 ]

[xleeuwx]

Het is hoe dan ook al oneerlijk om 2 verschillende versies te vergelijken van PHP

Daarnaast zou je nog even op beide machines met PHP kunnen kijken wat de disk speed is:
Bijv. http://stackoverflow.com/...disk-io-in-php-with-mysql

[TheNephilim]

Je zou voor de gein eens een Droplet bij DigitalOcean aan moeten maken. Ik heb daar een (kleine) Laravel app draaien op de goedkoopste Droplet met Centos 7 icm. nginx+php-fpm, en mariadb.

Deze is toch echt niet langzaam en word dagelijks gebruikt door meerdere gebruikers tegelijkertijd, ik heb het nog nooit gemeten overigens (omdat het gewoon zo snel aanvoelt).

[afraca]

Er draaien op die vps heel wat websites, een paar custom in elkaar gezet, een paar op wordpress. Die halen wel gewoon netjes een response van 20-100 ms. Maar de 'booting' sequence zoals gemeten door Barry's debugbar is 450ms. De application tijd (dus onze code) 20-30ms.

(natuurlijk kleine overhead ivm debug=true, maar dat zal nooit > 20 ms zijn)

Als antwoord op xleeuwx:
Verschillende benchmarks geven een performanceverschil van max 10% tussen de php versies, dus daar verwacht ik geen gekke dingen. Over je mysql benchmarking: daar twijfel ik een beetje over. Op zich zijn de queries gecached, dus op de frontpage 0 queries. Maar, er word wel altijd verbinding gemaakt bij booten, wat misschien nog langzaam kan zijn?

Als antwoord op TheNephilim:
Die droplet zal ik eens opperen. Ik heb zelf ook een vps. Maar het is een beetje tricky met company code


Het mysterie blijft een beetje overeind nog helaas: de server kan misschien langzamer zijn dan ideaal is, maar er draaien 10 sites gewoon heel erg prima op, met niet heel gekke configuraties. Als een wordpress site daar 50ms haalt, dan moet Laravel dat ook gewoon kunnen. Heeft Wordpress niet 70 bestanden te includen, en als disk access langzaam is zou een dergelijke Wordpress site ook langzaam zijn.

edit: Net nog even een vanilla wordpress site geprobeerd, 130ms op pingdom.net, dus zonder cache plugins.

edit2: We hebben wel 143 routes

code:

php artisan routes | wc -l

Het dispatchen naar een route zou nog even kunnen kosten, maar de homepage is de tweede route in die lijst.

edit3: Dat zou niet zo'n groot verschil zijn. Ik heb als test het even teruggebracht tot ~25, maar geen verschil. Op zich vrij logisch, maar ja....

edit4: Een volledig kale Laravel installatie is 117 milliseconden. Dat is niet gek snel, maar wel weer 3.5x sneller dan de site waar ik het over heb.
Verschil is dan de service providers die wij hebben.

edit5: Nieuws.... Door wat te commenten in app/config/app.php met service providers, bleek de LessyServiceProvider een beetje lastig te doen. Die draait in live ook gewoon altijd te controleren.

[ Voor 22% gewijzigd door afraca op 17-06-2015 11:49 ]