Ich arbeite mit mod_perl und datenbanken.
nun möchte ich noch einige binäre dateien verarbeiten die ich ungern in der datenbank speichern möchte, da sie noch von einigen anderen programmen genutzt werden.
Jetzt habe ich ein wunderbar schnelles mod_perl2-Script, welches jedoch jedesmal durch den Zugriff auf die Textdatei ausbremst.
Gibts irgendwie ne möglichkeit diese textdatei auch in mod_perl2 einzubinden, dass sich diese datei quasi im Arbeitsspeicher aufhält?

Wenn ich Linux benutze, müsste ich die Textdatei doch theoretisch in ein temporäres Verzeichnis packen können, oder?
Wenn das möglich ist, was für schritte sind dann notwendig, damit perl erkennt, dass sich diese textdatei in einem temp befindet?

hast du nur lesenden oder auch schreibenden ZUgriff auf die Datei?
Wie groß ist sie?

durchschnittlich ca 5 bis 10 kb! schreiben und lesen

Also ich wuerde es so machen:
Die Daten erst mal in eine Variable (dann sind sie auf jeden Fall im RAM und werden auch dort gehalten) packen.

Du schreibst das auch andere Programme die Daten verarbeiten koennen. Deswegen wuerde ich bevor die auf $data zugreifst einen stat auf die file.dat machen.
perldoc -f stat perlfunc
Dort bekommst du die mtime der Datei raus (also wann die Datei das letzte mal veraendert worden ist).

Wenn du ein richtiges Betriebssystem hat, dann werden häufig zugegriffene Dateien automatisch im RAM gecachet. Wahrscheinlich bei Linux besser als bei Windows, und bei *BSD besser als bei Linux, behaupte ich einfach so ohne Beweise zu liefern.

Die effizienteste Methode, mit mod_perl eine Datei auszuliefern, ist send_fd().

Wenn du eine Datei einlesen willst wird sie immer von Platte gelesen. Egal welches Betriebssystem du hast.

Was richtig ist das eine Datei, wenn du sie bearbeitest, nicht gleich auf die Platte geschrieben wird, sondern die Daten noch im Puffer (RAM) liegen.

Deswegen muss man z.B. auch eine Diskette oder einen USB Stick unmounten bevor man ihn aus dem System nimmt. Sonst gehen Daten verloren.

Aber wenn du eine Datei aus einam Script oeffnest wird immer ein Systemcall open() und dann ein bis mehrere read() ausgefuehrt.

Nein Neal, es gibt auch einen Lese-Cache. Linux verwendet zum Beispiel einen Grossteil des freien Hauptspeichers fuer Caches. Wenn du die gleiche Datei x-mal hintereinander liest, wird sie nur beim ersten mal wirklich von der Platte gelesen, danach kommt sie aus dem Cache im Speicher, der natuerlich wesentlich flotter ist.
Da macht auch der System-Call open und Co keinen Unterschied, denn das Caching im OS liegt dahinter.

[quote=nepos,22.02.2006, 10:04]Nein Neal, es gibt auch einen Lese-Cache. Linux verwendet zum Beispiel einen Grossteil des freien Hauptspeichers fuer Caches.[/quote]
nicht ganz ... ein Linuxsystem verwendet den restlichen zur
Verfügung stehenden Hauptspeicher als Buffer Cache. Da der
Benutzerspeicher eine höhere Priorität hat, wird der Buffer
Cache zugunsten des Benutzerspeichers verkleinert.

Quote

Linux is renowned for its fast disk access and this is mainly because of its efficient implementation of the buffer cache. The buffer cache rose and shrinks dynamically in user memory as required. (Actually, kernel memory grows dynamically into user memory to allow this - the buffer cache is still considered part of kernel memory.)

Auch hier nachzulesen: Linux Internals

@froschpopo, vielleicht könnte das Sticky Bit für dich
interessant sein, für Dateien, die von mehreren Benutzern
bzw. Skripts genutzt werden sollen und der Zugriff sehr
performant sein soll... aber vorsicht, ich habe mal gelesen,
dass es hierbei ein paar Dinge zu beachten gibt...

greez,
opi

Edit:
\n\n

<!--EDIT|opi|1140608032-->

@opi: jo, das hatte ich wohl noch unterschlagen ;)

[quote=nepos,22.02.2006, 10:04]Nein Neal, es gibt auch einen Lese-Cache. Linux verwendet zum Beispiel einen Grossteil des freien Hauptspeichers fuer Caches. Wenn du die gleiche Datei x-mal hintereinander liest, wird sie nur beim ersten mal wirklich von der Platte gelesen, danach kommt sie aus dem Cache im Speicher, der natuerlich wesentlich flotter ist.
Da macht auch der System-Call open und Co keinen Unterschied, denn das Caching im OS liegt dahinter.[/quote]

Ja ok, du hast recht. Aber ich denke das das Betriebssystem in der Zwischenzeit viele andere Sachen in den Speicherladen muss. Kommt halt ganz auf die groesse des Ram's an.

Aber das kann man ja nicht beeinflussen ob die Daten noch im Lesepuffer sind oder nicht. Wenn man die Daten in eine Programmeigenen Datenstruktur ablegt, dann ist man auf jeden Fall auf der sicheren Seite. Das wollte ich damit ausdruecken.

Ich habe z.B. einen V Server der mir meine Partition per NFS bereitstellt. Wenn ich da auf Daten zugreifen will dauert das ewig.