Caching in PHP

Hallo Allerseits!

Ich saß vorhin da und hab weiter an Klassendiagrammen in UML geschraubt und wie immer versucht schon jetzt möglich perfomante Lösungen zu suchen. Es ist schon länger angedacht Caching zu nutzen, aber eigentlich kenne ich mich damit nicht aus. Also hab ich mich dann mal informiert, um nicht wegen Unwissen jetzt schon Mist zu bauen. ;)

Naja, aber die Ausbeute war zwar wie immer interessant (lernt ja doch immer was), aber nicht wirklich zufriedenstellend, denn wenn ich das bisher richtig sehe ist die Lage so:

Caching kompletter Seiten ist kein Problem und dafür bestehen bereits automatisierte Software wie APC oder eAccelerator. Bisher stand fest, dass wir eAccelerator nutzen, doch bisher sieht die Software für mich so aus:

Man installiert und konfiguriert die Software und danach wird automatisch gecacht, was als lohnenswert erkannt wird. Direkt beeinflussen kann ich das nicht bzw. explizit Variablen speichern / laden ist nicht drin. Zumindest hab ich bisher keine gegensätzliche Dokumentation gefunden. :/

Über APC hab ich was auf php.net gefunden und das soll ja auch mit PHP6 rein, aber:
In Wikipedia steht, es sei ein optimierer wie eAccelerator und optimiert automatisch ganze Siterequests.
Jedoch ist es laut php.net die "Ursuppe", ich kann also einzeln Variablen speichern, laden ... bla bla also alles selbst managen.

Soweit, so gut. Wäre gut wenn mir das jemand be- oder widerlegen könnte. ;)
Nun zu dem was ich ganz spezifisch suche:

Wir planen ein Browsergame, was quasi komplett OOP sein soll, daher gibt es natürlich auch ein paar Klassen, die sich quasi nie Ändern (zB. Rechtesystem mit Gruppen von Rechten, welche sich eig. nur selten ändern). Die Optimierungsidee wäre also, speziell genannte Klassen zu cachen und zu gegebenen Zeitpunkt zu referenzieren.

Diese Funktionalität scheint APC der Dokumentation von php.net aus zu können, da wir aber eAccelerator nutzen wollten, würde es mich stark interessieren, ob dort vergleichbares geht? Bzw. ob APC sowohl die automatische Optimierung übernimmt und zusätzlich noch manuelles Caching erlaubt.

Wie gesagt, kenne mich bei Caching noch garnicht aus. Soweit ich erlesen konnte geht für OOP PHP (also Version >5.0) nur APC oder eAccelerator, aber vielleicht übersehe ich ja einen ganz anderen Ansatz?

Rege Diskussion ist sehr erwünscht. ^.^

Mit freundlichen Grüßen
Bloodredangel

Besitzt du Zugriff auf die Entwicklerforen?

Wenn ja:

http://www.galaxy-news.de/groups/2_entwickler/forums/5167_optimale_datenspeicherung_caching.html

dort stehen schon ein paar Dinge.

lg

Du darfst bei deinen Überlegungen nicht das Cachen einer Serverantwort an den Client
und OpCodeCaches vermischen.

Beim Caching gibt es verschiedene Ansätze. Die Hauptaufgabe von APC, eAccelerator und Co ist erstmal den OpCode zu speichern, damit dein Skript nicht bei jedem Aufruf neu interpretiert werden muss. Dafür musst du nichts machen, außer es zu installieren und der Effekt ist enorm.

Der nächste Schritt ist es Daten selber zu cachen. Frei nach dem Motto "cache everything" ist es sinnig Daten zu holen, aufzubereiten und dann zu cachen, solange sie nicht für jeden Request individuell erstellt werden. Dafür bieten sich Frameworks an, die dir den Verwaltungsaufwand abnehmen. Bei vielen Frameworks hast du sogar die Wahl, welche Cache-Engine verwendet werden soll, z.B. simpel in Dateien oder im Hauptspeicher über einer der zahlreichen Schnittstellen (APC, MemCache...), wie beispielsweise hier beim ZF: http://framework.zend.com/manual/en/zend.cache.backends.html.

Dass eAccelerator und Co. den Overhead verringern ist mir bewusst und wie gesagt, sowas werden wir definitiv nutzen. By the way: Dazu muss man Fast-CGI aktiviert haben oder?

Mit Frameworks bzw. Extensions geht das sicher, ja. (Also APC, Memcached, ...)
Aber eigentlich hatte ich gehofft mein Problem möglichst einfach zu lösen, also mit einer bereits in PHP eingebauten Funktion. Ein Framework wollte ich bewusst meiden, da wir unser eigenes basteln / nutzen und ich nicht ein riesiges Framework für eine Funktionalität haben möchte.

Weiterhin bleibt für mich die Frage: Kann ich per Caching (egal ob Framework, Schnittstelle oä.) auch instanzierte Klassen speichern? Also so, dass ich sie direkt so referenzieren kann, ohne serialize und unserialize.

Danke soweit!
MfG Bloodredangel

Ohne jetzt einen Flame lostreten zu wollen:

Ihr benötigt für eure Wünsche einen "Application-Server". PHP ist leider momentan nicht in der Lage dies sinnvoll anzubieten.

Ihr benötigt aber exakt einen solchen um eine Serialisierung/Marshalling zwischen zwei Requests zu vermeiden.

Original von Bloodredangel

Mit Frameworks bzw. Extensions geht das sicher, ja. (Also APC, Memcached, ...)
Aber eigentlich hatte ich gehofft mein Problem möglichst einfach zu lösen, also mit einer bereits in PHP eingebauten Funktion. Ein Framework wollte ich bewusst meiden, da wir unser eigenes basteln / nutzen und ich nicht ein riesiges Framework für eine Funktionalität haben möchte.

Wie bereits gesagt wurde - ihr sucht was anderes, und das werdet ihr mit PHP nicht finden & erreichen.. zumindestens, wenn du dich hier richtig ausgedrückt hast.

Ich bin allerdings der Meinung, dass bezgl. des Frameworks das euer Problem ist. Ein Framework ist eben wie ein Baugerüst oder ein Fundament: Es hilft ungemein, sorgt sich um vieles und man braucht sich um vieles nicht mehr zu kümmern. Baut man alles selber, muss man zwangsläufig auch alles selber bauen. Und klar, wählt man das Fundament zu klein oder zu groß, dann geht das Vorhaben irgendwann zumindestens technisch in die Binsen.

Will heißen: Wenn ihr nicht ein verdammt gutes Framework habt und/oder nicht in der Lage seid, dass "Feature-Gap" mit eigenem Know-How und Zeit zu füllen - warum muss es ein eigenes sein? Ich finde, diese Frage sollte man sich zwischendurch immer wieder stellen. Ja ja, das 1 Millionste Rad kann besser sein, aber man hat daran länger gebaut als an dem ganzen Auto..

Weiterhin bleibt für mich die Frage: Kann ich per Caching (egal ob Framework, Schnittstelle oä.) auch instanzierte Klassen speichern? Also so, dass ich sie direkt so referenzieren kann, ohne serialize und unserialize.

So rein prinzipiell: Klar, PHP kann doch auch Objekte serialisieren (gibt es dazu nicht sogar "magische Methoden"?). Aber wie auch immer du es anlegst, es wird ein RUmgewürfele mit Serialisieren, Deserialisieren, Nachladen, Überprüfen.. das kann man nicht mit einem Lebenszyklus (und einer Performance) auf 'nem dafür gemachten System (Hallo, Framework..) vergleichen.

Naja ich meinte damit schon die magischen Methoden. ;)

Vielleicht verstehe ich nicht recht was ihr meint, welche Probleme löst ein Application-Server?
Und Frameworks erleichtern doch auch nur durch in PHP programmierte Funktionen die Arbeit oder sehe ich das falsch? Sind die so viel mächtiger als was eigenes?

Die Sache ist halt, es bis jetzt nur 5 Klassen betrifft. Ich bin halt am Überlegen wie hoch der Aufwand ist:
Falls (manuelles) Caching einfach ist, würde ich es nutzen.
Falls es jedoch ein ziemlich großes Ding wird, würde ich dann lieber doch die Klassen einfach neu erstellen. Gerade beim Rechtesystem ist dazu nichtmal eine erneute Datenbankanfrage notwendig, denn das muss ich so oder so abfragen (um sicher zu gehen, dass die Daten aktuell sind). Nur neu instanzieren.

Aber die Karte (auch verwaltet in Klassen) und ein Gebäudemanagement mit Grundmenge benötigter Ress etc. erzeugen beim Neuaufbau halt auch immer eine Datenbankabfrage. Letzendlich ist ja noch zusätzlich die Frage, wiviel Latenz das serialize / unserialize erzeugt.

Bis jetzt hört es sich so an, als lohnt sich zwar eAccelerator, aber manuelles Caching wird zu aufwendig.
Oder ich binde APC ein und wir nutzen eAccelerator fürs Automaische und APC fürs Manuelle oder sehe ich das falsch?

MfG Bloodredangel

Original von Bloodredangel

Naja ich meinte damit schon die magischen Methoden. ;)

Vielleicht verstehe ich nicht recht was ihr meint, welche Probleme löst ein Application-Server?
Und Frameworks erleichtern doch auch nur durch in PHP programmierte Funktionen die Arbeit oder sehe ich das falsch? Sind die so viel mächtiger als was eigenes?

Da kann ich vielleicht was dazu beitragen. :)

Ich hab zwei Jahre lang ein eigenes Framework entwickelt, weniger weil ich es gebraucht habe, sondern eher weil ich tiefergreifend lernen wollte (OOP, API Design vor allem).

Mein Framework hat in der Zeit 150 Klassen bekommen und wurde stillgelegt...

Ich nutze jetzt Zend Framework (bzw. arbeite mich darin ein) und dieses kann selbst in den Bereichen die ich auch unterstütze bedeutend mehr und hat zudem um die 1800 Klassen, also wesentlich mehr Funktionaltiäten. Natürlich nimmt man davon in der Regel nicht alle Klassen, sondern nur ein paar Module, aber dennoch war der Unterschied bei mir recht groß. Wenn man noch die ausgiebigen Tests durch die große Verbreitung ansieht.

Also man braucht unglaublich viel Zeit und Know How um diesen Vorsprung den Zend zum Beispiel hat durch ein eigenes Framework aufzuholen und dass sich die Arbeit lohnt sollte es schon mehr können bzw. das was man braucht besser unterstützen.

Ich denke viel lohender wäre da eigene Erweiterungen für Zend Framework zu schreiben und da wo man es nutzen kann die fertigen Sachen zu nehmen.

Die Sache ist halt, es bis jetzt nur 5 Klassen betrifft. Ich bin halt am Überlegen wie hoch der Aufwand ist:
Falls (manuelles) Caching einfach ist, würde ich es nutzen.
Falls es jedoch ein ziemlich großes Ding wird, würde ich dann lieber doch die Klassen einfach neu erstellen. Gerade beim Rechtesystem ist dazu nichtmal eine erneute Datenbankanfrage notwendig, denn das muss ich so oder so abfragen (um sicher zu gehen, dass die Daten aktuell sind). Nur neu instanzieren.

Was spricht denn dagegen zum Beispiel Zend_Cache [1] zumindest anzuschauen und vielleicht auch zu nutzen? Die Komponente ist glaub von keiner Anderen abhängig und kann somit auch völlig alleine verwendet werden.

[1] http://framework.zend.com/manual/de/zend.cache.html

Bis jetzt hört es sich so an, als lohnt sich zwar eAccelerator, aber manuelles Caching wird zu aufwendig.
Oder ich binde APC ein und wir nutzen eAccelerator fürs Automaische und APC fürs Manuelle oder sehe ich das falsch?

Manuelles Cachen lohnt sich immer dann wenn die Abfrage der Daten relativ lange dauert (Zum Beispiel das Auslesen einer XML Datei oder das Holen der Daten aus der Datenbank), die Daten im Gegensatz dazu nicht zu umfangreich sind (da dann der Vorteil des Caches nicht mehr spürbar wird) und vor allem die Daten öfter gelesen werden müssen und sich seltener ändern.

Wie gesagt, informiere dich nochmal genau über die verwendeten Begriffe.

> Oder ich binde APC ein und wir nutzen eAccelerator fürs Automaische
> und APC fürs Manuelle oder sehe ich das falsch?
Öhm - ja...
http://en.wikipedia.org/wiki/PHP_accelerator
Die Beschleunigung durch APC oder eAccelerator wird dadurch erreicht,
dass der kompilierte PHP-Quelltext zwischengespeichert wird (RAM o. HDD)
und bei wiederholter Ausführung das zeitaufwändige
Kompilieren nahezu vollständig vermieden werden kann.
http://de.wikipedia.org/wiki/Cache
Cache bezeichnet eine Methode, um Inhalte,
die bereits einmal vorlagen, schneller ein zweites Mal zu beschaffen.
Caches sind als Puffer-Speicher realisiert, die die Kopien zwischenspeichern.
Das sind im Grunde zwei verschiedene Paar Schuhe.

Genausowenig lassen sich alle Frameworks direkt miteinander vergleichen: Ein Zend-Framework hat andere Features wie beispielsweise CakePHP. Deswegen sind beide nicht schlecht.. nur eben nicht gleich. Und ein Application-Framework ist wieder was anderes.. und dann gibt es davon auch noch mehrere.. ;)

Ob jetzt "mehr Klassen" auch bedeutet, dass das Framework mehr/besser kann - sei mal dahingestellt (jaja, so meintest du das ja auch nicht ;)). Aber das war ein gutes Beispiel, warum es meist nicht vernünftig ist, alles selber zu entwickeln.

Aber um hier mal Butter bei de Fische zu tun.. was genau willst du denn "persistent" haben?

Zend und so muss ich mir mal Morgen ansehen. Also genaugenommen kann unser "Framework" nur das nötigste (Validatoren für int usw., Passwortsicherheit berechnen, Klassenlader und Datenbankverwaltung - das wars imho im Großen und Ganzen). Da ich bis auf Caching für alles bisher die grobe Umsetzungsidee im Kopf habe, wüsste ich noch nicht so recht, wiviel ein Framework hilft. Da heißt es wahrscheinlich ausprobieren, aber weiß noch nicht ob ich die Zeit finde probieren "einzuschieben".

Da ich wie gesagt grad nicht so mit Zeit gesegnet bin, anworte ich jetzt erstmal nur knalli ausführlich:
Es geht genau gesagt um folgende Klassen:

1) Eine Klasse "HotspotManager", welche alle "Hotspot" Klassen kennt und bei Bedarf zurückgibt (also referenzierter Array). Die Hotpots beinhalten (x,y)-Koordinate der Kartenposition, sowie Namen, welche Wege wohin führen - andere Einzelheiten wie "momentaner Besitzer" muss ich halt sowieso täglich laden, aber das geht ja. Die ansonsten genannten Attribute sind fest.

2) Eine Klasse "ConcernManager", welche alle "Concern" kennt (also die verschiedenen Hauptgruppierungen im Spiel, so wie in WoW Horde & Allianz - ändert sich quasi nie).

3) Zu den Konzerne gehören Konzerngebäude, die spezifisch für jeden Konzern sind. Die Klasse heißt vorerst "Building" und beinhaltet den Namen, lvl, Bonus, Zugehörigkeit und benötigte sowie bereits vorrätige Ressourcen für die nächste Stufe. Hier bleibt alles bis auf die "vorrätigen" Ressourcen immer fest, bis es zum lvl-Aufstieg kommt. Dann halt einmal neu laden ...

4) Ein Rechtesystem. Also es gibt "Group"s, denen sind "Right"s zugeordnet. Optimal wäre natürlich, wenn jede Group und jedes Right nur einmal besteht und die Right's halt mehrmals referenziert werden. Die Gruppen gehören dann letzendlich (möglichst auch mehrfach referenziert) zu den Usern.

5) Ich überleg auch Arenaergebnisse / Arenadaten zT. zu cachen, käme halt drauf an wie groß die Daten werden. Beinhaltet sowas wie Teilnehmer, Startzeitpunkt, Eintrittsgebühr bzw. geht es hauptsächlich um Ergebnisse (userId's in hierarschicher Reihenfolge des Gewinns, der einzelne Kampf ist eine Verlinkung des Kampfberichtes). Also im Endeffekt ein User-Array pro fertige Arena (ändert sich dann logischerweise auch nicht mehr).

Das war vorerst alles, der Rest ist nur Krimskrams und muss noch durchdacht werden ob es lohnt. ;) Aber nur dafür würde ich ungern was externes einbinden / Frameworks anlernen. Wenn ich ein Framework hernehme, dann nur um es auch noch anderweitig zu verwenden, aber wie gesagt: Mal sehen. Extern einbinden würde ich, wenns wenig "Belastung" mit sich bringt und angemessen lohnt (was auch immer das heißt *g*).

Mit freundlichen Grüßen
Bloodredangel

> Vielleicht verstehe ich nicht recht was ihr meint, welche Probleme löst ein Application-Server?

Du kannst einfach Daten in einem Request ablegen und in einem anderen Request wieder abrufen. Entweder über statische Variablen oder über spezielle Application-Klassen:

OnWebApplicationStart()
{ Application["Map"] = new Map(bla, blubb); }

Anderer Request()
{ ... ; Application["Map"].GetField (x,y); ... }

OnWebApplicationStop()
{ Aufräumen(); }

Wie gesagt: Ist nur ein Vorschlag. Wenn ihr bei PHP bleiben wollt/müsst, wirst du um eine Serialisierung bzw. ein existentes Framework nicht herumkommen.

Genau das tut eigentlich eine Datenbank. Warum was eigenes erfinden?

> Genau das tut eigentlich eine Datenbank. Warum was eigenes erfinden?

Um genau das Abspeichern in der Datenbank zwischen zwei Requests zu vermeiden.

Sei es um eine Netzwerkverbindung nicht zu verlieren oder sei es eine umständliche Hin- und Zurückserialisierung zu umgehen.

So, hab mir jetzt mal die Syntax und genaue Speicherungsweise von memcache usw. durchgelesen. Durch noch ein paar Hinweise bin ich auch nun schlauer, dass Cachen (wie ich es möchte) nur durch Extension ermöglicht wird.

Das Zend-Framework sieht insgesamt recht gut aus, besonders die ausführliche Dokumentation gefällt mir gut und in deutsch ist es halt doch noch etwas leicht zu lesen. Wir werden nun mit großer Wahrscheinlichkeit ein Framework benutzen, welches steht noch aus.

Auf jeden Fall habe ich jetzt ziemlich gut verstanden wie und unter welchen Vorraussetzungen Caching funktioniert und kann mithilfe dieses Wissens endlich weiter Klassen planen. :)

Danke an alle! Und falls wer noch einen heißen Tip hat bzw. gern weiterdiskutieren mag: Gern!
MfG Bloodredangel

Ich will jetzt hier kein Framework schlecht reden oder ein Flamewar lostreten,
aber du solltest dir wirklich, wirklich gut überlegen,
ob du z.B. auf Zend oder ein anderes Framework setzt.
Ich hab schon viele Frameworks angesehen und teilweise getestet.
Manche verfolgen recht gute Ansätze, manche eher nicht.
Aber eins haben alle gemeinsam, sie sind übel langsam.
Es ist klar, mehr Komfort geht einher mit weniger Performance.
Und da muss man dann abwägen, ob man diesen Tausch eingehen will.
Mal als Beispiel ein simples Hello World auf der selben Maschine.
Statisches HTML 611 Transaktionen / Sekunde
Baseline PHP 606 T / s
Codeigniter 300 T / s
Zend Framework 125 T / s
Cake PHP 25 T / s
Die include trees für ein simples Hello World sind teilweise extrem.
z.B. Zend http://phpimpact.files.wordpress.com/2008/07/zend-blog-db-hor.gif
oder Cake PHP http://phpimpact.files.wordpress.com/2008/08/cake.gif
Die tollen include trees macht man übrigens mit der PECL Extension inclued und Graphviz.
Weiterhin kann es auch hilfreich sein,
mal den Apache ( oder was auch immer ) mit strace zu starten
und sich die Systemcalls anzuschauen.
Auch die Toolsammlung valgrind (memcheck, cachegrind, callgrind) kann mitunter
sehr aufschlussreich sein.

Die T/S-Werte sind aber 'was veraltet, oder? Ich meine, die wären mittlerweile nicht mehr ganz so krass, habe nämlich erst vorletzte Woche (aktuellere?) Vergleichsdaten gefunden, da wurde CakePHP, CI und Symphony "verbenchmarkt".

Optimierungen mit Syscalls (Stichwort PHP-Fehler"wurf"-Delay) ist reine Sache des Frameworks .- kann man selber eh nicht machen, wenn man später noch (einfach) updaten will. Entweder das Framework ist an dieser Stelle gut - oder eben nicht.

Und auch wenn man die Include/Require-Beziehungen natürlich mit externen (Cache-)Erweiterungen optimieren kann - diese zwei Dinge sind mit Sicherheit nicht die Flaschenhälse in der späteren Anwendung. Und du hast es gerade ja selber genannt.. Zend kommt auf wesentlich größere Rate als bsp. Cake - obwohl viel mehr Dateien logisch geladen werden müssen. Nun kann man Zend und Cake aber auch nicht wirklich miteinander vergleichen - in keinsterweise ;)

Du kannst ein nicht mit einem Framework vergleichen. Natürlich ist das Framework da um Dimensionen langsamer denn, welch' Überraschung, da wird mehr Code als ein einzelnes "echo" ausgeführt. Die interessante Frage ist vorallem wie gut das Framework noch unter Last und in einer Konfiguration für eine Produktivumgebung performt, und wie das eine komplette selbst gestrickte Anwendung ohne Hilfe des Framework tut.

> Du kannst ein nicht mit einem Framework vergleichen.

Exakt.

Insbesondere wenn man dies mit einem printk-Befehl vergleicht. http://man-wiki.net/index.php/9:printk

Trotzdem wird keiner auf die Idee kommen ein Browserspiel als Kernel-Modul zu entwickeln.

Nur mal zwei Ideen eingeworfen die kein Framework brauchen.

• Auf linux etwas Arbeitsspeicher mounten und die serialisierten arrays da drauf cachen.
• eine named session erzeugen und die objekte in die session ablegen.

Egal, wie und wo die Klassen gecached sind, muss es möglich sein im falle eines verlusts des caches die Daten schnell wieder zu rekonstruiern.

Ansonsten nur der Tipp, PHP in die Tonne zu treten.

Original von TheUndeadable

Trotzdem wird keiner auf die Idee kommen ein Browserspiel als Kernel-Modul zu entwickeln.

Hiermit weite ich meine Belohnung für Browsergames in exotischen Sprachen auch auf Browsergames aus, die als Kernelmodul entwickelt wurden. Wobei ich noch am überlegen bin, ob ich eine Aufnahme in den Mainstreamkernel als weitere Voraussetzung aufnehmen sollte. ;-)

Original von Bloodredangel

2) Eine Klasse "ConcernManager", welche alle "Concern" kennt (also die verschiedenen Hauptgruppierungen im Spiel, so wie in WoW Horde & Allianz - ändert sich quasi nie).

3) Zu den Konzerne gehören Konzerngebäude, die spezifisch für jeden Konzern sind. Die Klasse heißt vorerst "Building" und beinhaltet den Namen, lvl, Bonus, Zugehörigkeit und benötigte sowie bereits vorrätige Ressourcen für die nächste Stufe. Hier bleibt alles bis auf die "vorrätigen" Ressourcen immer fest, bis es zum lvl-Aufstieg kommt. Dann halt einmal neu laden ...

Auch wenn es unschön ist, könntest du die Sachen die sich nie ändern hardcoden. Code der größtenteils nur aus Konstanten besteht wird glaube ich von den diversen accelerators komplett wegoptimiert, was quasi einem Caching gleich kommt.

> Du kannst ein nicht mit einem Framework vergleichen.
Ein Hello World war das einfachste Beispiel, um zu zeigen wieviel Overhead entsteht.
> Die interessante Frage ist vorallem wie gut das Framework noch unter Last und in einer Konfiguration
> für eine Produktivumgebung performt, und wie das eine komplette selbst gestrickte Anwendung ohne Hilfe des Framework tut.
Das ist in der Tat eine interessante Frage.
Als Beispiel könnte man Magento heranziehen.
Eine wirklich komplexe eCommerce Anwendung auf Zend Basis,
in der alle gängigen Design Patterns umgesetzt wurden.
Auf dem Papier und lokalen Server sieht das alles ganz toll aus,
aber in der Praxis nicht mehr, wenn man merkt das der Shop bei 10 Usern in die Knie geht.
> Code der größtenteils nur aus Konstanten besteht wird glaube ich von den diversen accelerators komplett wegoptimiert
Ich weiss jetzt nicht genau, ob die accelerator die Verwendung von Konstanten soweit optimieren.
Gelesen habe ich davon bisher noch nichts.
Was aber auch z.B. für große hardgecodete Arrays geht, falls APC installiert ist:
if (!$foo = apc_fetch('foo')) {
    require 'foo.php';
    apc_store('foo', $foo);
}
Man kann so seine Daten in eine externe Datei hardcoden
oder einfach in die Datenbank schreiben,
da das require oder query nur beim ersten aufruf ausgeführt wird.

Original von Dunedan

Original von TheUndeadable

Trotzdem wird keiner auf die Idee kommen ein Browserspiel als Kernel-Modul zu entwickeln.

Hiermit weite ich meine Belohnung für Browsergames in exotischen Sprachen auch auf Browsergames aus, die als Kernelmodul entwickelt wurden. Wobei ich noch am überlegen bin, ob ich eine Aufnahme in den Mainstreamkernel als weitere Voraussetzung aufnehmen sollte. ;-)

Da fallen mir doch gleich noch mehr Dinge ein: Ein Browsergame, das auf einem selbstgebauten Server als Firmware läuft oder ein komplett in Hardware realisiertes Browsergame (sollte ja mit FPGAs möglich sein). Ansonsten kannst du ja deinen Post mal in die Lobby stellen, den kann ich nämlich nicht lesen. Hört sich interessant an, die Diskussion.

Original von buhrmi

Nur mal zwei Ideen eingeworfen die kein Framework brauchen.

• Auf linux etwas Arbeitsspeicher mounten und die serialisierten arrays da drauf cachen.
• eine named session erzeugen und die objekte in die session ablegen.

Egal, wie und wo die Klassen gecached sind, muss es möglich sein im falle eines verlusts des caches die Daten schnell wieder zu rekonstruiern.

Ansonsten nur der Tipp, PHP in die Tonne zu treten.

Hm, named sessions wäre ne Idee, aber dann müsste ich register_globals on haben - oder? Sonst kann ich ja nur eine Session verwenden und die gehört ja dem User (also brauch dann ja 2 Sessions, eine private und eine globale). Oder täusch ich mich da? Wäre super, wenn ja. ;)

Das mit dem Arbeitsspeicher versteh ich nicht ganz. Meinst du sowas wie mit Shared Memory? (http://de.php.net/manual/de/book.shmop.php)

Original von Nagila Hawa

Da fallen mir doch gleich noch mehr Dinge ein: Ein Browsergame, das auf einem selbstgebauten Server als Firmware läuft oder ein komplett in Hardware realisiertes Browsergame (sollte ja mit FPGAs möglich sein). Ansonsten kannst du ja deinen Post mal in die Lobby stellen, den kann ich nämlich nicht lesen. Hört sich interessant an, die Diskussion.

Na ja, interessant ist das allemal. In dem Post ging's allerdings ursprünglich um turingvollständige Sprachen, insbesondere TeX und Postscript. ;-)

Original von Bloodredangel

Das mit dem Arbeitsspeicher versteh ich nicht ganz. Meinst du sowas wie mit Shared Memory? (http://de.php.net/manual/de/book.shmop.php)

Es wurde ja vorgeschlagen, Objekte in Dateien zu cachen. Damit das ganze schneller wird, nicht auf der festplatte sondern im arbeitsspeicher halten. Ist zwar immernoch der serialize/unserialize overhead, aber naja. Google sagt das hier http://www.vanemery.com/Linux/Ramdisk/ramdisk.html, keine ahnung obs noch aktuell ist.

Eine RAMdisk ist etwas unflexibel was den Speicherverbrauch angeht. Dann lieber via APC, MemCache oder eine Heap-Tabelle in MySQL cachen.
BTW: Serialisierung in PHP soll sehr schnell arbeiten.

Original von Klaus

Eine RAMdisk ist etwas unflexibel was den Speicherverbrauch angeht. Dann lieber via APC, MemCache oder eine Heap-Tabelle in MySQL cachen.
BTW: Serialisierung in PHP soll sehr schnell arbeiten.

Als Vergleichswert (mal in ein paar Benchmarks durchprobiert): ein serialisiertes Array zu deserialisieren ist ungefähr 3 mal so schnell wie das Array als PHP-Code interpretieren zu lassen (die Zeit den Sourcecode zu laden, z.b. via Include, rausgerechnet).

Ausnahmsweise mal etwas, was die PHP-Entwickler gut hinbekommen haben *SCNR* :D

Datenbank als Cache, vor allem bei PHP/Mysql, ist eine denkbar schlechte Idee. Apache mit mod_php arbeitet entweder bei jedem Zugriff mit einer neuen Datenbankverbindung (jedesmal overhead) oder ich konfiguriere Persistente Verbindung und riskiere Ausfälle, wenn mal ein query hängt. Ohne connection pooling würde ich eher davon abraten, und die Zahl der Datenbankzugriffe eher knapp zu halten.

Sinnvolles Einstiegscaching welches leicht umzusetzen ist wäre zum Beispiel, vorm Zug erstmal alle statischen (Binär)daten vom dynamischen Inhalt zu trennen und direkt vom Filesystem zu servieren, Bei hohem Trafficaufkommen evt. von einem eigenen Server. Mögliche Konfiguration hierfür wäre z.B. einen lighttpd vorzuhängen, der per mod_rewrite zugriffe auf .jpg, .css, .js, .gif... auf einen Ressourcenserver umleitet und somit den statischen Krempel "aus dem Getriebe" hält. Wenn solche Resourcen zudem noch mit far-future Verfallsdaten gesetzt sind und evt. etags ordentlich konfiguriert sind, dann besteht auch gute Hoffnung, dass die statischen Daten da landen wo sie hingehören, im Cache. Am besten aufgehoben im Browsercache des Clients, aber der macht das nur, wenn die Konfiguration stimmt. Die ganze Konfiguration hier auseinanderzunehmen sprengt vielleicht den Rahmen, aber googeln nach Lighttpd und mod_rewrite macht schlau, ebenso das yahoo yslow plugin, welches sinnvolle hinweise zu ungenutzten Tuningmöglichkeiten eurer Seiten bietet.

Das Lighttpd Frontend macht btw bei Application Servern noch mehr Sinn, damit statische Daten nicht den Arbeitsspeicher verstopfen. (Objektdatenbanken hassen in der Regel feiste Binärdaten, und in Mysqltabellen sind sie nicht viel besser aufgehoben)

Wem das an Caching noch nicht genug ist, der kann sich mal nach Industrielösungen als Cache umsehen, wie Varnish, oder der etwas betagte Squid.

Hab mich zwar lang nicht mehr gemeldet (Stress im Studium), aber die Sachlage hat sich eh gewaltig geändert: Wir wollen nun doch mit einem Framework (Symfony) arbeiten, wodurch wir so oder so auf optimale Perfomanz verzichten, aber die Entwicklungszeit deutlich verkürzt werden sollte. Denke, dass wir soweit auch auf ausgewähltes Caching verzichten, da Symfony ja sowieso den gesamten Database-Layer mit Propel oder Doctrine übernimmt.

Trotzdem danke für die Ideen! :)

Das bedeutet aber nicht, dass du die Vorschläge von Tron nicht realisieren kannst ;) Wenn alles in einem Verzeichnis deployed wird, geht es eben über Rewrite; ansonsten eben durch eine zusätzliche CDN-(Sub-)Domain für das Webroot.

Ok, zugegebenermaßen bin ich auf Tron nicht eingegangen, da mir zunächst zu viel unbekannter Stoff drin war. ;)

Jetzt, wo ich mich zu lighttpd & mod_rewrite belesen hab, versteh ich jetzt was er meint.
Statische Daten wollten wir ohnehin auslagern, da Symfony ja Objektorientiert die Daten abspeichert und .yml Konfigurationsdateien für Konstanten anbietet (und genau da werden die Daten auch landen).

Laut Wiki scheint lighttpd schneller zu sein als apache, das klingt ja erstmal sehr interessant und auch betreffs ETags muss ich mich dann noch belesen. ;) Stimmt schon, das [b]ordentliche[/b] cachen von Bildern, css, etc. dürfte eh die meiste Ladezeit beanspruchen. :) Also Danke an dich Tron für die hilfreichen Infos und Danke an knalli, weil ich mich sonst nicht nochmal damit auseinander gesetzt hätte. ;)

Gruß Bloodredangel