nicht angemeldet
APC - shared cache
Moin,
in einer nginx/php-fpm Umgebung würde ich gerne PHP's APC Cache nutzen, um nicht nur sehr schnell sondern auch "gemeinsam" auf Variablen zugreifen zu können.
Mit den children/worker Prozessen, wie sie php-fpm dynamisch verwaltet, bin ich mir nicht sicher, ob der Speicher ohne weiteres für alle Prozesse zur Verfügung steht oder am Ende mehrere voneinander getrennt (verwaltete) Speicher entstehen.
Hat PHP für diesen Anwendungsfall eine sichere Lösung?
Grüße
-
Moin!
in einer nginx/php-fpm Umgebung würde ich gerne PHP's APC Cache nutzen, um nicht nur sehr schnell sondern auch "gemeinsam" auf Variablen zugreifen zu können.
Mit den children/worker Prozessen, wie sie php-fpm dynamisch verwaltet, bin ich mir nicht sicher, ob der Speicher ohne weiteres für alle Prozesse zur Verfügung steht oder am Ende mehrere voneinander getrennt (verwaltete) Speicher entstehen.Hat PHP für diesen Anwendungsfall eine sichere Lösung?
Wenn du eine Lösung auch für die Zukunft haben willst, solltest du APC nicht mehr nehmen. APC wird ab PHP 5.5 nicht mehr existieren, denn das wichtigste Feature, der Opcode-Cache, wird jetzt von PHP direkt mitgeliefert, allerdings ist es der Zend Optimizer. Dieser hat allerdings keinen Userland-Cache.
Nimm was aktuelles: Memcached, Redis oder jeden sonstigen Memory-Cache.
Übrigens ist "gemeinsam auf Variaben zugreifen" ein problematisches Szenario, denn Variablen werden irgendwann mal verändert müssen dann bei allen aktualisiert werden - und das erfordert immer irgendeine Art von Locking oder sonstigem Tracking der Veränderung. Es ist also mindestens mal sehr kompliziert. Was genau hattest du dir denn da drunter vorgestellt?
- Sven Rautenberg
-
Moin,
das sind keine guten Neuigkeiten, da ich auch andere Projekte mit dem APC nutze, wo m.E. Memcache, Redis etc. "übertrieben" wären, da ich gerade mal 1-15MB im RAM mit schnellem Zugriff brauche und mehr oder weniger als gemeinsamen Zwischenspeicher nutze.
Wenn du eine Lösung auch für die Zukunft haben willst, solltest du APC nicht mehr nehmen. APC wird ab PHP 5.5 nicht mehr existieren, denn das wichtigste Feature, der Opcode-Cache, wird jetzt von PHP direkt mitgeliefert, allerdings ist es der Zend Optimizer. Dieser hat allerdings keinen Userland-Cache.
Was genau hattest du dir denn da drunter vorgestellt?
Vereinfacht gesagt ginge es im aktuellen Script um Counter. Für jede Minute des Tages genau 1 Counter, maximal 24*60 INTEGER Werte, die spätestens am Folgetag überschrieben werden.
Die Anwendung sieht ein Quota vor, welches als "queries per sec" definiert ist und sich aus dem Durchschnitt der "queries per 1._ minute" anhand des Werts der vorherigen und bereits angebrochenen Minute ermitteln lässt.
Z.B. würde bei einer Ausführung zur Uhrzeit 23:59:30 mit 2 READs geprüft werden, ob das Quota bereits überschritten wurde: ($counters["23"]["58"]+$counters["23"]["59"])/90>max_queries_per_second; //90sec, da die queries von 23:58:00-23:58:59 und 23:59:00-23:59:30 berücksichtigt werden. Falls OK, wird die Query ausgeführt und es folgt ein WRITE/UPDATE: $counters["23"]["59"]++;Das Locking macht mir hierbei keine Sorgen.
Fände es sehr übertrieben, wenn hierfür ein redis oder memcache aufgesetzt werden müsste. War APC nicht eigentlich auch für solche Fälle vorgesehen?Gruß
-
Moin!
das sind keine guten Neuigkeiten, da ich auch andere Projekte mit dem APC nutze, wo m.E. Memcache, Redis etc. "übertrieben" wären, da ich gerade mal 1-15MB im RAM mit schnellem Zugriff brauche und mehr oder weniger als gemeinsamen Zwischenspeicher nutze.
Es gibt ein Projekt "APCu", den APC-Usercache als separates Modul weiterzuführen. Sämtliche Funktionsnamen ändern sich von apc_* zu apcu_* - und das Release ist derzeit noch beta.
Wie toll das dann maintained wird, muss sich zeigen. Ich persönlich würde allerdings nicht mehr unbedingt auf APC setzen. Standard-PHP-Installationen werden den Zend Opcodecache haben, und wenn man irgendeine Art von User-Cache benötigt, muss man sich so oder so irgendwas installieren. Ob das nun APCu ist, oder Memcached, dürfte ziemlich egal sein.
- Sven Rautenberg
-
-