Hallo Uwe, hallo "die anderen alle" Ich benutze Firefox und diese größeren Vorschaubilder als "Popup" gehen mir (gelinde gesagt) auf den Senkel Eine zeitlang sind sie deaktiviert, dann (ohne erkennbaren Grund) sind sie immer wieder da. Der Haken an entsprechender Stelle ist und bleibt ungesetzt. Wenn ich in die Einstellungen gehe und diese dann wieder verlasse, sind die größeren Vorschaubilder auch wieder weg. Kein "Beinbruch", aber ein Stück weit nervig... kann man da mit einfachen Mitteln was gegen unternehmen?? Ein Thumbnail in den Mini-Version reicht mir, ich sehe keinen Gewinn in einer weiteren (etwas) kleiner gerechneten Version... Gruß, Thorsten |
das könnte eine Nebenwirkung eines Problems sein, mit dem ich seit Tagen kämpfe. Sicher bin ich mir da nicht, aber es klingt wie ein weiterer Fall von längst ungültigen Daten, die zurück ins Leben kamen.
Ich hab' mittlerweile einen Fix, aber will nicht ausgerechnet am Abend den Webserver neustarten müssen.
btw: Sollte hier noch jemand APC als Cache für PHP verwenden, und einen zwischen verschiedenen PHP-Prozessen geteilten (shared) Cache vom Typ "user" verwenden: Das klappt nicht, da die Entwickler "shared" komplett mißverstanden haben.
apc_smc.c, in 3.0.14:
sma_segments = apc_shm_create(NULL, i, sma_segsize);
da dürfte nicht NULL stehen, das führt nämlich zu IPC_PRIVATE und damit eben nicht "shared".
Gruß, Uwe (und verdammt, das funktionierte mal)
Das interessiert jetzt wahrscheinlich keinen, aber ich schreib' mir trotzdem mal den Frust von der Seele.
APC (Alternative php cache) ist ein Cache für PHP. Darin können Anwendungen zum Beispiel Daten zwischenspeichern, die sie teuer gewonnen haben, und dann wesentlich schneller beim nächsten Lauf aus dem Cache holen - das lohnt sich so circa ab Daten, die eine Millisekunde Herstellungszeit gekostet haben.
Irgendwelche Daten zusammenbasteln macht das Forum ziemlich häufig, zum Beispiel landeten bei einem Aufruf der Startseite rund 140 Objekte im Cache. Ohne Caching dauerte das rund 0.7 Sekunden, mit Caching 0.25 (wobei zusätzlich prozessinterne Caches wirken).
Damit das alles keine unerwünschten Nebenwirkungen hat, müssen alle laufenden Prozesse denselben Cache benutzen (damit ein Prozess, bei dem Daten geändert wurden, die alten Kopien derselben auch aus den Caches der anderen Prozesse löschen kann).
Und soweit ich das testen konnte, funktionierte das auch... ahem. Das Problem mit dem Testen solcher Sachen ist allerdings, daß die Probleme Auslastungs-, timings- und zufallsabhängig sind. Und wahrscheinlich hatte ich beim Testen nie die Situation, daß zwei oder gar drei Caches aktiv waren, während ich mal etwas geändert habe.
Nun, mit einer sauberen Konfiguration von APC bekommt man es hin, daß APC nicht einen Cache pro Prozess verwendet, sondern einen gemeinsamen Cache aller Prozesse. Dazu muß man apc_file_mask=/apc.shm.XXXXXX setzen. Oder so. Das steht so auch in der Anleitung. Aber in der Anleitung steht so vieles, zum Beispiel
das:
[indent2]
If you prefer to use mmap instead of the default IPC shared memory support,
add --enable-apc-mmap to your configure line.
[/indent2]
... und das ist schlicht und einfach völlig falsch. Der Default ist nämlich --enable-apc-mmap, und wenn man "IPC shared memory" haben will, muß man --disable-apc-mmap verwenden.
Das muß man natürlich wissen. Ja? Wirklich? Hätte ich das wissen müssen?
Irgendwann habe ich begonnen zu merken, daß irgendetwas nicht stimmte und gelegentlich alte Daten wiederauferstanden. Ich hab' zuerst mal im Forumscode gesucht, bis ich mir sicher war, daß der Fehler woanders sitzen muß, und mir dann APC näher angesehen und mit --disable-apc-mmap neu übersetzt.
Soweit, so gut, apc_cache_info('user') sagte nun klar und deutlich "IPC shared".
Problem gelöst? Ach, iwo, schön wäre es gewesen.
"IPC shared" auszugeben und "IPC shared memory" tatsächlich zu machen sind zwei total verschiedene Paare Schuhe.
Denn tatsächlich ist das, was APC macht, "IPC private memory". Und das wird gleich durch zwei verschiedene Effekte verursacht:
- * apc_shm_create verwendet ausdrücklich IPC_PRIVATE, wenn man nichts übergibt, woraus sich ein IPC-Schlüssel erzeugen läßt (und das ist, was passiert). Das habe ich am Montag gesehen, und mich schon erheblich "gefreut".
- * apc_shm_attach löscht das IPC-Speichersegment. Die Entwickler haben da absolut nicht verstanden, was sie tun, denn danach kann kein anderer dieses Segment nutzen (es ist nicht mehr erreichbar außer für Prozesse, die das in diesem Moment schon offen haben, und das ist nur der aktuelle Aufrufer). Das habe ich gestern gesehen.
Gestern war meine Freude absolut grenzenlos, denn das heißt, daß der ganze APC-Kram bisher noch nie "shared memory" genutzt hat. Und nach den bisherigen Erfahrungen mit der Library hatte ich keinerlei Lust, der Erste zu sein, der in dem Bereich nach Fehlern sucht.
Also habe ich gestern mal eben mein eigenes Cachesystem auf Basis der dcache-Library (http://www.ohse.de/uwe/dcache/) gestrickt, man hat ja sonst nichts zu tun. Das tut jetzt erst mal, wenn auch der Overhead etwas hoch ist.
Ich bin mir ja relativ sicher, daß PHP-Libraries kein Müll sein müßten, aber irgendwie sind sie's doch recht häufig, und wenn ich mir die Namen der APC-"lead"-Entwickler angucke, graut es mir.
Kopf hoch!
Monika