Ankündigung

Einklappen
Keine Ankündigung bisher.

Symfony cache langsamer als nicht gecached

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Symfony cache langsamer als nicht gecached

    Hallo Zusammen

    Hat da jemand Erfahrung mit dem Symfony Cache Psr6? Für mein Storage wollte ich den zum Testen brauchen. Jedoch war ich entäuscht da mit dem Cache die Query viel langsamer ist als ohne.

    Beispiel:
    PHP-Code:
    $verifier = (new Verifier())
                    ->
    table('products', ['id''sku'], 'id')
                    ->
    table('products_lg', ['product_id''language_id''title']);

    $storage = new InMemoryStorage([
        
    'products' => [
            
    => ['id' => 1'sku' => 'rose'],
            
    => ['id' => 2'sku' => 'sunflower'],
            
    => ['id' => 3'sku' => 'viola'],
            
    => ['id' => 4'sku' => 'petunia'],
            
    => ['id' => 5'sku' => 'sanvitalia'],
            
    => ['id' => 6'sku' => 'salvia'],
        ],
        
    'products_lg' => [
            [
    'product_id' => 1'language_id' => 1'title' => 'rose'],
            [
    'product_id' => 1'language_id' => 2'title' => 'rose EN'],
            [
    'product_id' => 2'language_id' => 1'title' => 'sunflower'],
            [
    'product_id' => 2'language_id' => 2'title' => 'sunflower EN'],
            [
    'product_id' => 3'language_id' => 1'title' => 'viola'],
            [
    'product_id' => 3'language_id' => 2'title' => 'viola EN'],
        ]    
    ], 
    $verifier);

    //$storage = new JsonFileStorage($verifier, __DIR__.'/storage/');
    //$storage = new DatabaseStorage($verifier, $database->pdo());

    $cache = new \Symfony\Component\Cache\Adapter\FilesystemAdapter();

    $storage->setCache($cache);

    $start microtime(true);

    for (
    $i 1$i <= 10000$i++) {

        
    $items $storage
        
    ->table('products')
        ->
    select(['sku''title'])
        ->
    leftJoin('products_lg', function($join) use ($i) {
            
    $join->on('id''=''product_id')
                 
    //->onOr('id', '=', 'language_id');
                 
    ->where('language_id'$i);
        })
        ->
    where(function($query) {
            
    $query->whereLike('title''farn')
                  ->
    orWhereLike('desc''bb');
        })
        
    //->cache()
        
    ->get();
        
    //echo '<pre>';
        //print_r($items);    
    }

    $end = (microtime(true) - $start);
    echo 
    "elapsed time: $end";
    echo 
    '<br><br>'

  • #2
    Nun, dass der FilesystemCache langsamer ist als die Datenbank, ist für mich nur bedingt verwunderlich... während das Dateisystem IO (also Plattenzugriffe) voraussetzt, wird die Datenbank bestenfalls komplett im Arbeitsspeicher verwaltet und verfügt, sofern das nicht geht, über sehr gute IO Optimierung. Das, was bei der DB meist am Längsten dauert, ist die Verbindungsherstellung. Solange du die nicht wegoptimiert bekommst, dürfte es schwer sein, die DB zu schlagen. Es hängt auch stark davon ab, wie dein Serversystem / Testsystem aussieht...

    Ich vermute, dass wenn du einen Redis-Cache nutzen würdest (REDIS ist für sowas optimiert), dann würde das Ergebnis anders aussehen.

    Eventuell könntest du mit dem PhpFileCache (der erzeugt PHP sourcecode, statt normlaler Dateien) etwas mehr rausholen, solange die Dateien im OpCache von PHP landen (der OpCache ist auch recht flott). Aber ich nutze Filesystem-Caches tatsächlich nur sehr selten...
    Tutorials zum Thema Technik:
    https://pilabor.com
    https://www.fynder.de

    Kommentar


    • #3
      Danke für den Tip Andreas. Die implementierung des Caches kam mir eigentlich in den Sinn für den JsonFileStorage oder InMemoryStorage Queries.
      Aber auch diese sind schon echt schnell. Muss mir nochmals Gedanken über das ganze machen und weiteres Testen. Vielleicht lass ich gleich die Cache implemtierung sein.
      Ich war sowieso nie ein Fan vom Cachen.

      Kommentar


      • #4
        Die Frage ist was und warum willst du cachen? Was dauert so lange, dass du es cachen musst?

        Kommentar


        • #5
          Bis jetzt dauert es eigentlich alles schnell. Dachte nur Nice to Have und im Fall der Fälle, wäre es schon implementiert. Warscheinlich gehe ich das falsch an. Vielleicht vorher alles schreiben. Und erst bei Bedarf denn Cache implementieren.

          Kommentar


          • #6
            Zitat von strub Beitrag anzeigen
            Bis jetzt dauert es eigentlich alles schnell. Dachte nur Nice to Have und im Fall der Fälle, wäre es schon implementiert. Warscheinlich gehe ich das falsch an. Vielleicht vorher alles schreiben. Und erst bei Bedarf denn Cache implementieren.
            Man cached dann, wenn es notwendig ist. Ein Cache macht nicht alles automatisch schneller. Es kommt halt immer drauf an, wie genau er implementiert ist. Eine pauschale Lösung für alles, die man einfach nur einschalten muss, gibt es nicht. Man sollte auch nicht vergessen, dass ein Cache selber auch Ressourcen braucht. Also wenn man es ungeschickt macht, kann das sogar nach hinten losgehen und alles langsamer machen.

            Kommentar


            • #7
              Also wenn man es ungeschickt macht, kann das sogar nach hinten losgehen und alles langsamer machen.
              Stimmt deswegen bin ich kein Fan vom cachen. Mein Motto war stets, wen was langsam ist, mach dass es schneller geht
              Bis anhin hatte ich nur schlechte Erfahrungen mit dem Cachen.

              Kommentar


              • #8
                Ich würde dir empfehlen, statt experimentellem Ausprobieren mal den Profiler von xdebug anzuwerfen (https://xdebug.org/docs/profiler). Der listet dir die relative Zeitspanne, die bestimmte Dinge im Code dauern... im Grunde etwa so (stark vereinfacht):
                • index.php => 100%
                  • include init.php => 98%
                    • include autoload => 97%
                    • mysqli_connect => 3%
                  • include load_db.php => 1%
                  • include footer.php => 1%
                Am Beispiel siehst du dann recht schnell, wo du die meiste Zeit verbringst und kannst dort optimieren, wo es WIRKLICH sinnvoll ist. Der Vorgang lässt sich beliebig oft wiederholen... Alles andere ist nur rumgeraten mit guten Hoffungen.

                Zum Beispiel: Hier ist es wahrscheinlih, dass vergessen wurde, composer autoload optimizing einzuschalten. Das geht mit einer Zeile in der Konfiguration (https://getcomposer.org/doc/articles...ptimization.md). Wichtig ist, dass man sinnvoll entscheidet, wo man am Besten optimiert. Quick wins (oder auch Low hanging fruits), wo man mit 2 Zeilen 15% mitnehmen kann, sind klar, aber wenn man groß restrukturieren oder durch Caches die Logik und Wartbarkeit stark verkomplizieren muss, würde ich das überdenken. Es gibt nicht viel komplizierteres als Cache-Invalidation...

                Vielleicht hilft dir das weiter.
                Tutorials zum Thema Technik:
                https://pilabor.com
                https://www.fynder.de

                Kommentar


                • #9
                  Hi Andreas

                  Super, danke für den Tip mit xdebug, den hatte ich ganz vergessen.

                  aber wenn man groß restrukturieren oder durch Caches die Logik und Wartbarkeit stark verkomplizieren muss, würde ich das überdenken. Es gibt nicht viel komplizierteres als Cache-Invalidation...
                  Das sehe ich auch so. Bislang habe ich für meine Anwendungen noch nie einen Cache benötigt, da ich immer die Schnelligkeit in der Entwicklung auch miteinbeziehe.
                  Deshalb habe ich mich auch entschieden die Implementierung des Cache sein zu lassen.

                  Kommentar

                  Lädt...
                  X