Hallo,

Wobei eine andere Möglichkeit eben auch wäre, beim Start des Servers EINMALIG sämtliche Daten in den Arbeitsspeicher zu laden und dort zu halten. Dann werden bei jedem Request die Daten immer direkt aus dem Arbeitsspeicher geladen, und man benötigt überhaupt keinen Plattenzugriff mehr. Je nach Anwendungsszenario kann ich mir das schon sinnvoll vorstellen.

Es hat bei mod_perl den Nachteil, dass der Server neu gestartet werden muss, wenn es bei den Daten Veränderungen gibt. Bei meinem FW gehts hauptsächlich um die Routing-Table, bisher hatte ich einen statischen und einen dynamischen Anteil dafür. Mit meinem neuen Konzept ist die RT nur noch dynamisch (optional mit der Möglichkeit, per Konfiguration etwa für temporäre Zwecke, einen statischen Teil anzuhängen).

Dynamisch: Die Tabelle wird minimal und bei jedem Request neu erstellt. Sie enthält nur noch das, was für eine Response tatsächlich gebraucht wird, das ist zunächst der Name der Subklasse, hinzukommen alle für die Response konfigurierten Attribute (title, descr, usw) und ein paar weitere Einträge (URLs mit Attributen fürs Menu und den virtuellen Ordner, in dem sich die Antwortseite befindet).

Ein etwaiger MEM-Cache würde im Prinzip so nach und nach ein vollständiges Abbild der RT im Hauptspeicher erstellen.

Ich gehe von einer frisch gestarteten Datenbank aus.
Wenn ich ALLE Daten aus einem Flatfile lese, dauert es so lange, wie eben das physische Einlesen von der Platte dauert.
Wenn ich ALLE Daten aus einer Datenbank lese (SELECT * FROM... or whatever), so muss die Datenbank

• Meinen Datenbank-User authentifizieren
• Meine Abfrage ("SELECT * FROM...") parsen
• Die Rechte für diese Abfrage prüfen
• Einen Ausführungsplan erstellen (gut sollte in dem Fall trivial sein, also full-table-scan)
• Die benötigten Datensegmente bestimmen und diese von der Platte in den Arbeitsspeicher laden
• Eine Antwort zusammenbauen und diese wieder an meine Anwendung schicken.

Das KANN also schonmal nicht so schnell sein, wie wenn ich es direkt aus einer Datei lade.

Bis zu eine bestimmten Größe der Datei, abhängig vom Algorithums, vom IO-Vermögen des Systems, ist das tatsächlich so. Auf meinem derzeitigen Server schätze ich diese Grenze auf ca. 5MB (ab da wäre MySQL schneller). Mit Indizierten Dateien habe ich auch schon experimentiert um den Hauptspeicherbedarf zu verringern, was jedoch keine Vorteile bringt; das läuft auf ein Neuerfinden einer DB-Engine hinaus ;)

Was anderes ist es natürlich, wenn ich dieselbe Abfrage MEHRFACH stelle. Hier kann man davon ausgehen, dass die Datenbank das Abfrageergebnis in irgendeiner Form cached, sprich, das Ergebnis bereits im Arbeitsspeicher vorliegen habe.

MEM-Cache in Verbindung mit mod_perl. Mit einer Möglichkeit zum Flush (ohne Serverneustart).

Jedenfalls ist es in den größeren Plattformen, in denen ich mich berufsbedingt herumtreibe, üblich, Connection Pools zu verwenden, weil da der Overhead für den Verbindungsaufbau sehr wohl ins Gewicht fällt.

Alternative hierzu wären DB-Klassen, deren Sourcen bereits beim Apache-Start kompiliert werden (mod_perl). Da sind auch die Statements sauber vom übrigen Code getrennt.

Schöne Grüße.