Hi, sorry dass ich damit noch mal nerve...
Wie Ihr ja wisst, baue ich einen Chat ...
Bisher schreibe ich ich Chat-Nachrichten in eine Textdatei...
Aber das ist der reinste Performancekiller da jedesmal auf die Festplatte zugegriffen werden muss!
Hat jemand eine Idee? Bitte nicht wieder irgendwelche Verweise auf Ralfchat, GTchat oder Strat-Chat sondern sachliche Hinweise. Wenn ich nur Links suchen würde, würd ich bei google suchen und nicht in ein Forum schreiben. Vielen Dank im Vorraus

hmmm...
immer dann, wenn du daten in einer variable speicherst, dann "speicherst" du in den Arbeitsspeicher...
so einfach ist das

Verwende ein Linux-System mit viel Arbeitsspeicher, denn das cacht von vornherein seine Festplattenpartitionen großzügig.

Nun schreibst Du in Dateien, wie Du das gewohnt bist. Tatsächlich schreibt Betriebssystem den Kram schnell in den Cache und liest auch wieder von dort. Wenn Zeit bleibt, weil Du gerade nicht schreibst oder liest, schreibt das Betriebssystem dann auch auf die Platte.

wie wäre es mit einer ramdisk?
dann hast du quasi das zugriffsinterface eines dateisystems und
die geschwindigkeit des arbeitsspeichers (minus einem vernachlässigbarem overhead).

das bringt aber andere probleme mit sich ...

[quote=kabel,14.03.2004, 22:04]wie wäre es mit einer ramdisk?
[...]
das bringt aber andere probleme mit sich ...[/quote]
...etwa dem zuvor noch effektiverem Plattencache ein wenig Speicher geraubt...

wie waere es, wenn du das ganze mit POE machst? dann hast du den overkill der externen kommunikation nicht, sondern kannst intern kommunizieren...

kannst Du mir das erklären?Was fürn overkill meinst Du?

s/overkill/overhead/

wenn du mehrere prozesse hast, musst du informationen zwischen den einzelnen prozessen hin und herschieben, was du ueber das dateisystem machst. es ist jedoch (von Perl aus gesehen) ewig langsam, eine Datei zu oeffnen, den inhalt zu lesen oder zu schreiben und wieder zu schliessen. Besser ist da eine Datenbank oder shared memory.

Wenn du nur einen prozess als server hast, der sich um alle clients kuemmert, kannst du die informationen ganz einfach ueber variablen uebergeben (z.B. objekte, arrays oder hashes), und da du da voellig intern bleibst, ist das um einiges schneller. ein problem dabei ist, dass es da recht schwierig ist, mehrere client-requests quasi-parallel abzuarbeiten; ich habe fuer den Chat auf meiner HP HTTP::Daemon gewaehlt, weil mir das viel arbeit abnimmt. die loesung, die mir von der theorie her am besten gefallen wuerde waeren threads (HTTP::Daemon ist leider nicht thread-safe) mit shared variablen, aber als ich das probiert habe (letzten fruehling mit perl5.8.0), stiess ich auf arge memoryleaks. aber das soll sich mit 5.8.2/3 schon verbessert haben. Eine andere Moeglichkeit waere, sich in einem prozess/thread selbst um die parallelisierung zu kuemmern, indem man den clients immer nur kleine haeppchen rausschiebt, und so moeglichst parallel arbeiten kann. dafuer wuerde ich POE (link siehe oben) verwenden...

Ist open(2) auf modernen Unices tatsaechlich so viel schlechter? Hier ist ein Beispiel-Benchmark fuer das Lesen aus einer Datei und aus einem Shared-Memory-Bereich mittels IPC::ShareLite:

Und das Ergebnis:

Das Ergebnis aendert sich signifikant zugunsten von Shared-Memory, wenn das ShareLite-Objekt nur einmal erzeugt wird (aber vielleicht wuerde ein offen gehaltenes Filehandle und ein seek() an den Anfang wieder die open()-Variante nach vorne bringen). Natuerlich gibt es weitere Parameter wie die Groesse des auszutauschenden Buffers, Locking muss vielleicht noch eingefuehrt werden etc.