nicht angemeldet
Prost Neujahr!
Vielleicht lasst ihr auch mal so durch blicken wie eure Fachlichen Pläne aussehen?
Plan für die nächsten Tage: Weiterentwicklung meines Perl-Moduls zum Speichern von Objekten in einer Binärdatei hinsichtlich Optimierung von Speicherbedarf und Performance. Es geht darum, einen Kompromiss zwischen RAM und CPU zu finden und so sieht mein Plan jetzt vor, das Lesen der Binary und das Managen der Binary, ausgehend von einer Baisklasse, in getrennte Submodule auszulagern:
Basisklasse: Ostore
Leseklasse: Ostore::Fetch
Schreibklasse: Ostore::Manager
Die Subklasse zum Lesen haben ich soeben fertiggestellt, Synopsis:
use Ostore;
tie my %h, 'Ostore::Fetch', '/home/dev/tools.bin';
print $h{'/tools/'}{title}, "\n", $h{'/tools/'}{descr};
Ostore.pm unterstützt das Speichern von sehr großen Werten zu Objektattributen, d.h., die Objekte (HTTP-Reponse-Objekte) haben neben den Attributen title, descr usw, auch den body als Attribut, hier steckt z.B. ein komplettes Template drin, auf jeden Fall alles was später zwischen <body> und </body> stehen soll.
Die Instanz der Klasse Ostore::Fetch liest nicht den kompletten Dateiinhalt in den Hauptspeicher sondern erstellt lediglich einen Hash of Hashes, in dem als Index zwar alle Objektnamen samt Attributnamen enthalten sind, anstelle des Wertes jedoch nur Offset und Length. Über diese beiden Angaben wird erst mit print $h{'/tools/'}{title}; über das Handle in die Datei gegriffen und der Wert gelesen, was sehr schnell geht auch bei großen Dateien von einigen 100MB. In der Praxis ist die Binary natürlich kleiner, 2500 Objekte belegen beispielsweise ca. 25MB in der Datei.
Je nach Verhältnis zwischen Anzahl der Attribute und Länge der Werte ist der Index, der zum Lesen erstellt werden muss, mindestens 100x kleiner als die gesamte Binary, i.d.R. ist der Index 1000x kleiner, das haben meine Tests ergeben.
Zum Managen von Web-Content muss jedoch die Binary komplett in den Hauptspeicher gelesen werden, das kommt jedoch nicht so oft vor und wird mit Class Ostore::Manager realisiert.
Warum das Alles? Manager und Fetch habe ich derzeit in zwei Modulen liegen, mein Ziel ist es, beides zusammen nur noch in einem kompakten Modul zu haben. Das Manager-Modul wird ein optionales LOCK_EX ermöglichen und ebenfalls eine Tie-Klasse sein: Kein Hantieren mit Objekten und Methoden, sondern ein einfacher Zugriff über einen gebundenen Hash in der main-Klasse.
Perl ist wunderbar, OOP und perltie jedoch ist eine Offenbarung ;)
Hotti
Matthias Apsel