PHP autoloading Linux vs Windows

[aex351]

Mijn PHP (5.6) applicatie maakt gebruik van autoloading binnen een eigen framework. Dit werkt door recursief door alle mappen heen te lopen (niet ideaal). Nu is het probleem dat dit op mijn Strato VPS (Linux) het wel tot 400% langzamer is in vergelijking tot lokaal (Windows). Met als gevolg dat page loads voor bepaalde pagina's kan oplopen tot 30-40 seconden. Het autoloaden van een enkele klasse en renderen van de pagina op Windows doet PHP in 0.05 seconden. In vergelijking op mijn VPS (Linux) doet PHP er 0.25 seconden over.

Nu is mijn eerste gedachte, de I/O van de VPS is te langzaam. Heb het één en ander getest, de schrijf snelheid is +200MB/s. De leessnelheid heb ik niet kunnen checken, omdat ik het niet aan de praat krijg. Desondanks doe ik nu de aanname dat het probleem hier niet aan ligt.

De configuratie van PHP op de VPS is de default zoals geleverd vanuit Plesk. Opcache staat aan. Lokaal niet. Heb verder de configuratie doorgelopen en kan geen afwijkingen vinden. Iemand een idee waardoor Autoloading zo traag werkt? Wellicht een instelling of iets dergelijks.

[mbarie]

Onderstaande is gebaseerd op aannames door visuele feedback e.a. zaken. Of het 100% zo werkt kan ik niet met zekerheid zeggen.

Volgens mij is autoloading is per definitie traag als het over je filesystem moet itereren; ik heb dat in het verleden met eigen frameworks ook gedaan en dat krijg je niet snel performant. Je kan kiezen voor een slimmere versie waarbij er eerst gezocht wordt gezocht naar een file die relatief vanaf je root zich exact bevindt waar deze volgens de namespace verwacht mag worden.

Composer (PHP Package Manager) lost dat volgens mij op door allereerst de fysieke locatie van iedere dependency te indexeren. Mocht de gevraagde file niet in de autoload index staan zal er pas teruggevallen/gezocht worden naar de specifieke file in kwestie.

[MadEgg]

Waarom symptoombestrijding? Waarom niet je auto-load algoritme aanpassen? Als je het echt op deze manier wilt doen, om wat voor reden dan ook, raad ik je aan om eenmaal bij de eerste aanroep alle mappen door te lopen en het resultaat ergens te cachen. Bij elke volgende aanroep kun je dan gebruik maken van deze cache en zal het een heel stuk sneller gaan.

Maar nogmaals: als je je je bestanden / classes logisch indeeld (PSR-0/PSR-4) kun je in een keer de juiste locatie van het bestand bepalen en hoef je niet te itereren. Dat is een stuk efficienter.

[T-MOB]

aex351 schreef op dinsdag 25 augustus 2015 @ 12:24:
Nu is mijn eerste gedachte, de I/O van de VPS is te langzaam. Heb het één en ander getest, de schrijf snelheid is +200MB/s. De leessnelheid heb ik niet kunnen checken, omdat ik het niet aan de praat krijg. Desondanks doe ik nu de aanname dat het probleem hier niet aan ligt.

Het bepalen van de lees- of schrijfsnelheid is niet zo van belang voor het inlezen van kleine bestanden. De bottleneck zit hem in seek times. Op een solid state drive is die tijd te verwaarlozen, maar op een disk met platters niet. Een 7200-toeren schijf doet 8ms over een rotatie. Alleen dat al levert je gemiddeld 4ms vertraging per seek. Als je een aantal includes hebt kun je daar een verschil van 50 en 250 ms op zich wel mee verklaren (Alhoewel ik zou denken dat het file system een ander wel zou moeten cachen, waardoor je in opvolgende page requests betere tijden zou moeten zien).

Maar dat het soms oploopt tot 25 seconden, dat lijkt me toch niet in het filesystem te zitten. Daar moet meer aan de hand zijn.

[Saven]

Kijk eens bij andere frameworks hoe zij autoloading aanpakken

[jbdeiman]

T-MOB schreef op dinsdag 25 augustus 2015 @ 13:09:
[...]


Het bepalen van de lees- of schrijfsnelheid is niet zo van belang voor het inlezen van kleine bestanden. De bottleneck zit hem in seek times. Op een solid state drive is die tijd te verwaarlozen, maar op een disk met platters niet. Een 7200-toeren schijf doet 8ms over een rotatie. Alleen dat al levert je gemiddeld 4ms vertraging per seek. Als je een aantal includes hebt kun je daar een verschil van 50 en 250 ms op zich wel mee verklaren (Alhoewel ik zou denken dat het file system een ander wel zou moeten cachen, waardoor je in opvolgende page requests betere tijden zou moeten zien).

Maar dat het soms oploopt tot 25 seconden, dat lijkt me toch niet in het filesystem te zitten. Daar moet meer aan de hand zijn.

Op zich niet een heel eerlijke vergelijking:
- Hoe is de server geconfigureerd? Als jij lokaal (bijvoorbeeld) een enorme hoeveelheid geheugen hebt geadresseerd en een SSD schijf gebruikt, is het niet realistisch dezelfde prestaties te verwachten van een server waarbij minder geheugen is geadresseerd, en waar een "conventionele harde schijf" in zit.

Recursie is sowieso erg heftig. Veel Frameworks gebruiken:
a) caching, voor dergelijke informatie. 1 keer traag, daarna is 't gecached. Kan een bestand niet worden gevonden in de cache, zoek je 'm op en cache je m.
b) Een slim mechanisme die al (globaal) weet waar het bestand waarschijnlijk gevonden kan worden, dus hoeft niet alles langs. Dit kan op basis van een logische klassenstructuur, of door op basis van klassennamen een logische bestandsstructuur indeling te maken. Dat scheelt al heel wat zoekwerk.

Als ik jou vraag verder lees zeg je dat het tot 400% langzamer is, dus 4 keer langzamer. Dat betekent bij de 30-40 seconden, dat het ook lokaal 8 tot 10 seconden kan duren? Dat is voor een applicatie erg traag.

[T-MOB]

jbdeiman schreef op dinsdag 25 augustus 2015 @ 13:22:
[...]
Op zich niet een heel eerlijke vergelijking:
- Hoe is de server geconfigureerd? Als jij lokaal (bijvoorbeeld) een enorme hoeveelheid geheugen hebt geadresseerd en een SSD schijf gebruikt, is het niet realistisch dezelfde prestaties te verwachten van een server waarbij minder geheugen is geadresseerd, en waar een "conventionele harde schijf" in zit.

De rest van het systeem doet er voor de vergelijking niet toe. Het gaat om een fysieke beperking van een draaiende schijf met een leeskop. Een ideale SSD heeft 0ms seektime. Een ideale ouderwetse harde schijf heeft gemiddeld een seektime van een halve omwenteling van de schijf. Bij een 7200rpm-schijf dus (1s/ (7200rpm/ 60s/min) ) / 2 ~ 4.1667ms. Daarbovenop komen de beperkingen aan de rest van het systeem. En eventuele caching kan de zaak versnellen.

Als ik jou vraag verder lees zeg je dat het tot 400% langzamer is, dus 4 keer langzamer. Dat betekent bij de 30-40 seconden, dat het ook lokaal 8 tot 10 seconden kan duren? Dat is voor een applicatie erg traag.

Het lijkt me ook stug dat dit alleen maar in de benadering van het bestandsysteem zit. Bij secondenwerk moet er ergens wel een fout in zittten. MIsschien kan TS zijn autoload-functie posten?

[aex351]

T-MOB schreef op dinsdag 25 augustus 2015 @ 13:45:
[...]
[knip]

Het lijkt me ook stug dat dit alleen maar in de benadering van het bestandsysteem zit. Bij secondenwerk moet er ergens wel een fout in zittten. MIsschien kan TS zijn autoload-functie posten?

PHP:

class Autoload
{
    public function load($path, $file, $exclude)
    {
        foreach (scandir($path) as $value) {
            $newPath = $path . "/" . $value;

            if (is_dir($newPath) && !in_array($value, $exclude)) {

                if (file_exists($newPath . '/' . $file)) {
                    require_once($newPath . '/' . $file);
                } else {
                    $this->load($newPath, $file, $exclude);
                }
            }
        }
    }

    public function Autoload()
    {
        spl_autoload_register(function ($class) {
            $path = 'src';
            $file = $class . '.php';
            $excludeDirectories = array(".", "..");

            if (!file_exists($path . '/' . $file)) {
                $this->load($path, $file, $excludeDirectories);
            } else {
                require_once($path . '/' . $file);
            }
        });
    }
}

Het ziet er naar uit dat het bestandssysteem op de VPS (Linux) de bestanden niet cached. Dit merk ik bijvoorbeeld doordat kijkend naar lokaal de eerste page hit 0,25 seconden kan zijn en bij een refresh 0,02. Maar op de VPS zie ik zulke verschillen niet terug.

Met betrekking tot SSD vs HDD, lokaal draai ik een 7200rpm HDD. Op de VPS zou het een HDD/SDD moeten zijn. Daarnaast kan ik inderdaad een caching maken rondom de Autoload functionaliteit om dit probleem enigzins aan te pakken. Toch wil ik weten waarom dit probleem zich op de server voordoet.

[T-MOB]

Je kunt sowieso wat winnen door te stoppen met zoeken als je het bestand gevonden hebt

[ Voor 132% gewijzigd door T-MOB op 25-08-2015 14:19 . Reden: edit toch maar in een post gezet ]

[aex351]

T-MOB schreef op dinsdag 25 augustus 2015 @ 13:59:
Je kunt sowieso wat winnen door te stoppen met zoeken als je het bestand gevonden hebt

Inderdaad

Een nieuwe test gedaan met een lege PHP bestand. Met behulp van de

PHP:

RecursiveDirectoryIterator

de "src" folder doorlopen. Lokaal 0,02 seconden en op de server 0,34 seconden. Kan dit te herleiden zijn tot een instelling of is het toch de hardware/VPS configuratie?

[T-MOB]

Verder kan het nog zijn dat je open base dir restricties aan hebt staan op de server. Zie hier wat achtergondinfo. Het komt er op neer dat open base dir php's cache uitschakeld omdat er toch elkeer gecontroleerd moet worden of je (nog) wel in een directory mag lezen.

[ Voor 13% gewijzigd door T-MOB op 25-08-2015 14:20 ]

[dcm360]

Het zou me niet verbazen als het blijkt dat jouw bestanden op een SAN staan, en niet op dezelfde server als waar de VM (of waarschijnlijk CT) op draait. Het zou een goede verklaring zijn waarom random I/O nogal traag is, en de sequentiële schrijfsnelheid wel aardig.

[aex351]

Het bleek toch een instelling te zijn. PHP's "open_basedir" was ingesteld. Hierdoor cached het bestandssysteem de bestanden niet. De oplossing in dit geval:

INI:

open_basedir="" 

[DJMaze]

http://php.net/spl_autoload nuf said

[IceM]

Is het niet beter om gewoon de PSR-4 autoloading standaard aan te houden? Dan hoef je niet te zoeken naar je files in je autoloader (beter: hoef je zelf geen autoloader te implementeren).

[Marientjuh]

Zoals al een paar keer aangehaald zou ik er ook voor gaan om de PSR-4 standaard aan te houden. Waarom het wiel opnieuw uitvinden als er al een bestande performant oplossing? Tevens een ieder ander die met je framework aan de slag gaat weet op die manier de juiste bestanden te vinden.

[aex351]

Nee, het wiel was al uitgevonden namelijk het framework dat zijn oorsprong kent ver voordat er überhaupt zoiets was was als PSR. Toegegeven PSR is een mooie toevoeging, maar voor mij nu geen optie.

[Barryvdh]

Gebruik composer, voeg classmap autoloading toe op je directory en draai composer dump-autoload. Dat scant al je php files, indexeert de classes en maakt er een autoload bestand van. Hoef je alleen de composer autoload file te gebruiken, die 1x array inlaadt ipv alle folders elke keer te scannen..