HTTP Request erzeugt neue selbe PHP Struktur

[MB]

Moin Community,

wie kann man geladene Settings z.B. Config::set( 'foo', 'bar' ) beim nächste HTTP Request zur verfügung stellen sodass sie nich mehr gelade werde müssen. Erzeugt ein HTTP Request jedesmal eine widerholt die selbe PHP Struktur??? Wie siehts mit Cache aus? Lehrt der Interperter die PHP Scripte nach dem sie abgearbeitet wurden?

vlg MB

[Regina Schaukrug]

Aus Deiner Frage geht nicht genau hervor, was Du meinst. Aber meine Messungen zeigen, dass PHP 7 (und hhvm) über ausgefeilte Cache-Methoden verfügt. Zum Beispiel sinkt bei einigen Skripten, z.B. mit "großen Includes", die einen in PHP formulierten Array (also ganz ähnliche Daten wie Du sie zeigst) enthalten, die Zeit für die Ausführung bei einem zeitnahen Reload von z.B. 45 auf 3 Millisekunden. Das ist enorm.

[MB]

Moin Regina,

Aus Deiner Frage geht nicht genau hervor, was Du meinst.

Sorry ich formuliere es anders. Ich ziehe zur erläuterung meine Frage ein Framework hinzu. Bei einem HTTP Request werden intern vom Framework aus PHP-Skripte gestartet. Nach abarbeitung dises requests in Skripten scheint es so, das diese Skripte intern einfach "vergessen" haben, das sie aufgerufen wurden. Das viel mir bei einer fehlerhaften Message Klasse auf die dafür soll informationen im Front End dem Besucher zugeben wie "Email versendet", "sie sind nicht angemeldet" usw.

class Test {
  static count = 0;
  public function add() {
    self::$count++;
  }
  public function show() {
    return self::$count;
  }
}

Diese Test Klasse wurde jedes Mal vom Framework aufgerufen und gibt mit echo am Ende Test::show() die statische zählvariable count zurück. Die dann nach jedem Request um eins hochgezähl wurde. Tut es aber nicht. Jedesmal am ende 1.

Ich hoffe es klärt sich.

vlg MB

[Regina Schaukrug]

Klare Sache: Ein Request, ein Programmaufruf. Damit eine Neuinstanzierung des Objekts und damit ist die Eigenschaft "count" des Objekts wieder erst Null und, nach einem Aufruf von $o->add(), dann Eins.

Du musst den Counter also speichern. Entweder per "Nutzer" (dann in einer Session) oder in einem hinreichend nicht flüchtigen Speicher, welcher das erneute Abarbeiten des Skriptes überlebt. Also in einer Datei, in einer Session oder eben im Arbeitsspeicher. Was davon das Richtige ist hängt von der Aufgabe ab.

[dedlfix]

Tach!

wie kann man geladene Settings z.B. Config::set( 'foo', 'bar' ) beim nächste HTTP Request zur verfügung stellen sodass sie nich mehr gelade werde müssen.

Nicht so ohne weiteres. Und du solltest erst dann Maßnahmen abseits des Standard erwägen, wenn die Beeinträchtigungen spürbar sind. Sowas erzeugt auch eine höhere zu meisternde Komplexität im System.

Erzeugt ein HTTP Request jedesmal eine widerholt die selbe PHP Struktur??? Wie siehts mit Cache aus? Lehrt der Interperter die PHP Scripte nach dem sie abgearbeitet wurden?

Jeder Request wird unter PHP erneut bearbeitet, inklusive Parsen des Script-Codes und Ausführen von Anfang an, und damit werden auch Konfigurationsdateien neu gelesen. Selbst wenn du eine Session zum Zwischenspeichern nimmst, muss die Datenhaltung dafür gelesen und am Ende geschrieben werden.

Caches gibt es eine ganze Menge, angefangen vom Dateisystem-Cache, weiter bei Cache-Systemen wie Memcached, bis hin zu PHP-Erweiterungen à la Zend Opcache.

Einige sind transparent (ohne dass man außer dem Aufsetzen und Konfigurieren noch was am PHP-Code machen muss), andere muss man gezielt verwenden (Memchached).

dedlfix.

[MB]

Moin dedlfix

Ok danke für die Erklärung. Hilft mir.

vlg MB

[Rolf b]

Hallo dedlfix,

Jeder Request wird unter PHP erneut bearbeitet, inklusive Parsen des Script-Codes und Ausführen von Anfang an, …

Ist das mit dem Parsen IMMER so? Im Falle eine CGI Scripts sicherlich, aber ich dachte, fastcgi und mod_php gewinnen ihre Vorteile gerade daraus, dass sie den erzeugten Pseudocode für Folgerequests cachen. Ich war der Meinung, dass genau daher der von „Regina Schaukrug“ gemessene Geschwindigkeitsgewinn stammt.

Dass alle Variablen weg sind, inclusive statischer Klassenvariablen, klar, das ist in PHP so, und das ist auch gut so. Statische Variablen werden von allen Anwendern geteilt, und wenn die requestübergreifend sichtbar wären, würde man bei Parallelausführung von Requests auf einem multithreaded server böse Race Conditions produzieren.

Rolf

[dedlfix]

Tach!

Jeder Request wird unter PHP erneut bearbeitet, inklusive Parsen des Script-Codes und Ausführen von Anfang an, …

Ist das mit dem Parsen IMMER so? Im Falle eine CGI Scripts sicherlich, aber ich dachte, fastcgi und mod_php gewinnen ihre Vorteile gerade daraus, dass sie den erzeugten Pseudocode für Folgerequests cachen.

Ja, ist immer so. Die genannten Methoden sorgen nur dafür, dass PHP selbst nicht auch noch geladen werden muss.

Ich war der Meinung, dass genau daher der von „Regina Schaukrug“ gemessene Geschwindigkeitsgewinn stammt.

Da braucht er einen OP-Cache. Und seit 5.5 soll auch der Zend Opcache in der Standardinstallation dabei sein, muss wohl aber aktiviert werden. Hab mich damit noch nicht beschäftigt.

dedlfix.

[MB]

wie ist es mit ob_start bezogen auf fortführende requests und caches?

vlg MB

[dedlfix]

Tach!

wie ist es mit ob_start bezogen auf fortführende requests und caches?

Da gibt es keinen Zusammenhang. ob_start() puffert die Ausgabe. Der Puffer wird spätestens zum Request-Ende aufgelöst und ausgegeben.

dedlfix.