Ankündigung

Einklappen
Keine Ankündigung bisher.

Überlegungen zum Thema Performance

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

  • Überlegungen zum Thema Performance

    Hallo zusammen,

    ich mache mir gerade ein paar Gedanken zum Thema Performance. Bei einem großen Projekt, welches auf verschiedenen Systemen ausgerollt wird, soll die Performance verbessert werden.
    Üblicherweise wird das ganze in Windows-Umgebungen mit IIS und PHP 7.1 FastCgi installiert (ich weiß, das ist nicht optimal), aber die Optimierungen sollen zumindest auch dort greifen.

    Folgende Überlegungen habe ich dazu schon angestellt bzw. umgesetzt und gebenchmarkt:
    • Datenbank-Optimierung (Überfllüssige und langsame Queries, Caching, Prepared-Statements)
    • Mögliche Opcache-Einstellungen und Verbesserungen
    • Kritische Programmstellen optimieren (Lazy-Loading, XDebug-Tracing)
    • Composer-Autoloading optimieren (--no-dev --optimize)
    • Php-Userland-Caching Backends für teure Berechnungen (Redis, Apcu, PhpFilesCache, FilesystemCache)

    Aktuelle Erkenntnisse anhand der Traces:
    • Der composer autoloader ist relativ langsam - Allein das die autoload.php (insbesondere die darin geladene autoload_static.php) in der optimierten Fassung geladen wird, dauert mir zu lange (Durchschnittlich 20ms)
    • PHP Sessions sind je nach Konfiguration langsam - Das Schreiben und Laden der Session bei jedem Request ist langsam, wenn die Session im Dateisystem liegt (und nicht z.B. Redis verwendet wird)
    • Ich habe nicht immer ein schnelles Caching-Backend (Redis kann nicht überall installiert werden)
    Fragen:
    • Ich möchte gerne den composer autoloader verbessern. Gibt es neben --optimize und --no-dev vielleicht undokumentierte Optimierungsmöglichkeiten, die ihr kennt? Überlegungen dazu:
      • Wäre es vielleicht möglich, da sich die Datei autoload_static.php nur bei einem rebuild des autoloadings über composer ändert, das ganze in die PHP compiletime zu verlagern? Verwendet man const statt define für die Definition von Konstanten, ist das viel schneller, insbesondere bei großen Mengen von Konstanten. Leider kann man mit const nur numerische arrays und keine assoziativen arrays erstellen.
    • In bestimmten Fällen KANN ich kein Redis als Caching-Backend nutzen (oder Backends, die die Installation eines Fremd-Produkts erfordern) und möchte gewährleisten, dass ich einen möglichst schnellen und portablen Cache anbieten kann. Welches überall nutzbare Caching-Backend würdet ihr empfehlen und warum? Überlegungen dazu:
      • Ich habe z.B. die Symfony-Caching-Backends zur Verfügung (Apcu, PhpFilesCache, FilesystemCache). In einigen Fällen sorgt der Apcu für Abstürze und 500er - Fehler Windows halt... Der PhpFilesCache sieht interessant aus, da er den opcache nutzt, leider ist er nicht unterstützt, da die Funktion opcache_invalidate trotz aktiviertem opcache nicht existiert...(Wieso das eigentlich?)
      • Lohnt es sich eventuell, einen shmop-Cache zu implementieren, damit der Cache im Shared-Memory (also im Ram) liegt, statt auf der Platte? Die extension wäre verfügbar...
    • Kann man über einen custom session_save_handler die Sessions in den Ram verlagern, ohne dass man eine Ramdisk anlegen muss?
    • Gibt es generell eine Möglichkeit, PHP compiletime Hashmaps zu speichern? (ähnlich const X = [1,2,3]
    • Gibt es weitere Performance-Überlegungen oder Artikel, die ihr empfehlen könnt? (gern auch die Standardsachen, was ich schon weiß, kann ich ja ignorieren

    Vielen Dank und viele Grüße
    Fynder - http://www.fynder.de - Tutorials zum Thema Technik


  • #2
    Wenn Du schon mit derartigen Mikro-Optimierungen startest, wäre es nicht sinnvoller, auf Linux-Systeme umzusteigen - Allein das viel schnellere Dateisystem macht schon einen Unterschied.

    Oder ein In-Memory-Filesystem.
    Könnt ihr einen vorgelagerten Cache verwenden (Varnish o. ä,)?
    Vermeidet ihr ORMs?
    Kommt eine ganz andere Programmiersprache in Frage?
    Habt ihr den opCache überhaupt aktiviert?

    Das kommt mir viel sinnvoller vor, als am autoloading rumzufrickeln.

    Und wieso schreibt ihr Arrays in Konstanten? Das klingt nicht gerade nach sauberer Programmierung.

    Kommentar


    • #3
      Hey, es hat ja doch jemand geantwortet

      @xm22:
      Vielen Dank erstmal für die Rückmeldung.

      Zu deinen Fragen:
      • Ja, Linux wäre sinnvoller. Leider nicht kurzfristig möglich, zu große Menge an Legacy Code um das zeitnah einzuplanen (Groß-/Kleinschreibung wird ignoriert, Backslashes an verschiedenen Stellen hart reinkodiert und andere Spielereien, die wesentlich ekliger sind)
      • In-Memory-Filesystem wäre auch sinnvoller, allerdings ist das in den meisten Umgebungen nicht einfach machbar
      • Vorgelagerter Cache ist nur sehr bedingt möglich, es sind hauptsächlich live-Daten
      • Ja, kein ORM im Einsatz - Queries werden häufig auf Schwachstellen geprüft, Datenbank wird regelmäßig optimiert (Indizes, Partitionierung, etc.)
      • Über eine andere Programmiersprache denke ich nach (Go ist mein Favorit )
      • Ja, Opcache ist aktiviert und meiner Ansicht nach auch richtig konfiguriert
      • Arrays werden nicht in Konstanten geschrieben, es ging mir darum, das Problem zu veranschaulichen - Konstanten werden in zur Compile-Zeit definiert, Variablen zur Runtime. Große Mengen davon (z.B. bei Übersetzungen oder Classmaps) verlangsamen das Programm, wenn auch nur wenig. Könnte man das in die Compile-Time verlagern, würde das (vielleicht) Zeit sparen, obwohl der Opcache schon aktiv ist

      Beispielsweise wird in der composer-autoload-classmap ungefähr 6000 mal eine doppelte String-Verkettung gemacht, statt eine wegzulassen oder es ganz "auszuschreiben" (was natürlich wegen der Portabilität nicht überall geht, aber mit einem Flag wäre es sicher kein Problem):
      HTML-Code:
      'GuzzleHttp\\RequestOptions' => __DIR__ . '/..' . '/guzzlehttp/guzzle/src/RequestOptions.php',
      Da dieser Teil automatisch generiert wird, wäre es sicher nicht falsch, hier jede Optimierungsmöglichkeit auszuschöpfen... davon würde jedes composer-Projekt profitieren und das wären sicher eine Menge

      Trotzdem vielen Dank, ich schau mich mal weiter um Wenn ich was bahnbrechendes finde, mache ich einen Pull-Request im Composer-Projekt, aber das ganze sieht schon ziemlich gut überlegt aus.



      Fynder - http://www.fynder.de - Tutorials zum Thema Technik

      Kommentar


      • #4
        ich mache mir gerade ein paar Gedanken zum Thema Performance. Bei einem großen Projekt, welches auf verschiedenen Systemen ausgerollt wird, soll die Performance verbessert werden.
        Treten denn Probleme bei der Performance auf?

        Lassen sich diese nicht an den entsprechenden Stellen behandeln?
        Ich kann mir dein Szenario gerade nur schwierig vorstellen, gerade im Web geht ja eigentlich alles immer recht schnell. Wenn du jetzt an allen möglichen Ecken in der Umgebung um das Projekt herum nach Verbesserungen suchst muss das System ja generell träge sein, oder?
        Relax, you're doing fine.
        RTFM | php.de Wissenssammlung | Datenbankindizes | Stay fit

        Kommentar


        • #5
          VPh
          Performance "Probleme" sind immer ein Thema für sich - ab wann würdet ihr denn von Performance-Problemen sprechen? Ich für meinen Teil halte Response-Zeiten von 1,5 Sekunden schon für ein Performance-Problem. Je nach menge der gleichzeitigen Nutzer sind auch 25 User gleichzeitig das Maximum, was ich erreichen kann. Es handelt sich nicht um eine Cloud-Anwendung sondern um eine On Premise Software (die vorab mit Source-Guardian verschlüsselt wird), daher ist das schon in Ordnung, aber es könnte schon besser sein.

          Ich lese mich gerade ein bisschen in "PeachPie" ein, damit wollte ich mich mal ein wenig beschäftigen, falls es jemanden interessiert, damit lässt sich PHP in die .NET-Umgebung kompilieren - PHP wird nicht mehr benötigt: https://www.peachpie.io/getstarted

          Ob das schneller ist, wird sich erst später herausstellen
          Fynder - http://www.fynder.de - Tutorials zum Thema Technik

          Kommentar


          • #6
            Zitat von Andreas Beitrag anzeigen
            ... sind auch 25 User gleichzeitig das Maximum, was ich erreichen kann.
            Das ist ein Scherz oder?

            Zitat von Andreas Beitrag anzeigen
            ...eine On Premise Software (die vorab mit Source-Guardian verschlüsselt wird),
            Daher der Versuch an den Symptomen etwas zu ändern.

            Irgendwo habe ich mal gelesen dass Google als Vorgabe einen Seitenaufbau von 200ms favorisiert.
            Unter normalen PHP Scripten in normal genutzter Umgebung sollte dieser Wert immer zu schaffen sein.

            Kommentar


            • #7
              Zitat von Andreas Beitrag anzeigen
              Performance "Probleme" sind immer ein Thema für sich - ab wann würdet ihr denn von Performance-Problemen sprechen? Ich für meinen Teil halte Response-Zeiten von 1,5 Sekunden schon für ein Performance-Problem.
              Kommt drauf an auf was sich die 1.5 Sekunden beziehen. Für ein Bericht oder eine Statistik ist das akzeptable. Wenn das die allgemeine Response Zeit ist, ist das definitv zuviel. Dann ist aber die Classmap von Composer das völlig falsche Thema in der Diskussion.

              Kommentar

              Lädt...
              X