Datei Schreiben/lesen, wann wirds kritisch ? (Bsp. dieses Forum)

[Steffen Wawryniuk]

Hi,

hab mal ne Frage: ab wann wird es kritisch ne Datei per Perl/CGI zu lesen bzw. schreiben.

ich meine ab wann dauert es ZU lange bzw. beansprucht den Server zu stark.
Am Beispiel dieses Forums, hier wird wenn ein neuer Beitrag geschrieben wird ja die gesamt index.shtml geöffnet und auch wieder geschrieben.

ab wieviel Zeilen (mal angenommen jede Zeile <250 Zeichen) wird es kritisch ?

Oder gibt es da überhauptkeine komplikationen ?

Nur zum Hinweis mein Script läuft auf Schlund&Partner Servern.

thx für Eure antworten.

P.S: damit zusammen stellt sich bei mir auch die Frage:  Was passiert wenn USER A das Script aufruft und die Datei geschrieben wird. und genau in diesem Augenblick USER B die Datei ließt ?
Noch schlimmer wenn USER C AUCH NOCH die Datei schreibt. gehen da Daten verlohren ?

cu
Steffen

[Patrick]

Hallo Steffen!

Die Perl-Cracks unter uns werden Dir sicher die Fragen besser beantworten können als ich. Nur soviel: Derzeit testen AlexBausW für SELFSPEZIAL ein Perl-Skript, das in der jetzigen Fassung aufgrund von Abfragen im gesamten Netz sehr viel Serverzeit beansprucht. Lokal zum Beispiel, bricht mein Webserver die Ausführung regelmässig (try again later)...

P.S: damit zusammen stellt sich bei mir auch die Frage:  Was passiert wenn USER A das Script aufruft und die Datei geschrieben wird. und genau in diesem Augenblick USER B die Datei ließt ?
Noch schlimmer wenn USER C AUCH NOCH die Datei schreibt. gehen da Daten verlohren ?

Hier kannst Du schon selbst eine Antwort finden, in dem Du in der Archivsuche das Stichwort "file locking" angibst...

Das Problem, dass Nachrichten an falschen Stellen und/oder überschrieben worden waren aufgrund des von Dir beschriebenen Schemas kann man eben durch file locking verhindern.

Bis danndann
PAF (patrickausfrankfurt)

<img src="/selfaktuell/extras/selfcomm.jpg" alt=""> http://www.atomic-eggs.com/selfspezial/guests/advguest.cgi?view

<img src="http://www.atomic-eggs.com/selfspezial/atomicegg.gif" alt="Atomic Eggs - die humosophische Seite" style="cursor:hand;" onMouseUp="window.location.href='http://www.atomic-eggs.com/'" onmouseover="status='http://www.atomic-eggs.com/';return true;" onmouseout="status='';return true;">

[speedy]

Hi Steffen ,

es haengt natuerlich schon von der Serverperformance ab. So hast Du z.B. auf einem Schlund-Server sicherlich weniger Ressourcen als auf einer dedizierten Kiste. Ich arbeite auf einem Cobalt-Server mit noch ca. 30 weiteren Webpraesenzen. Auf der Kiste hab ich ab und zu ein Logfile zu "sortieren" (ohne weiteren Kommentar) welches 8MB und groesser ist. Dies schafft der Cobalt in ca 90. Sekunden (das alleinige Lesen geht noch schneller). Ich wuerde sagen: probieren macht schlau. Installier Dein Skript doch einfach mal auf dem S&P-Server und schau was passiert.

Du kannst eine Datei auch zum "anhaengenden Schreiben" oeffnen, damit musst Du nicht die gesamte Datei in eine Variable lesen und dann komplett wieder zurueckschreiben. Dies duerfte auch bei sehr grossen Dateien keine Probleme verursachen. Mehr dazu findest Du in SELFHTML.

Auf Unix-Servern (und ich glaub auch NT) kann man Dateien locken um Sie vor mehrfachem Zugriff zu schuetzen. Hier duerfte das Archiv mit dem Begriff "flock" oder "file locking" einiges hergeben.

Hier noch ein Link, damit Du Dich intensiver mit PERL beschaeftigen kannst:
http://www.phy.uni-bayreuth.de/~btpa25/perl/perl_main.html Eine sehr gute Online-Einfuehrung in Perl, die Dir sicherlich auch mit File locking weiterhelfen kann.

Viele Gruesse
  speedy

[Patrick]

Hallo Steffen und speedy!

es haengt natuerlich schon von der Serverperformance ab. So hast Du z.B. auf einem Schlund-Server sicherlich weniger Ressourcen als auf einer dedizierten Kiste. Ich arbeite auf einem Cobalt-Server mit noch ca. 30 weiteren Webpraesenzen. Auf der Kiste hab ich ab und zu ein Logfile zu "sortieren" (ohne weiteren Kommentar) welches 8MB und groesser ist. Dies schafft der Cobalt in ca 90. Sekunden (das alleinige Lesen geht noch schneller). Ich wuerde sagen: probieren macht schlau. Installier Dein Skript doch einfach mal auf dem S&P-Server und schau was passiert.

Hier noch mal ein Beispiel zur Verdeutlichung: die Vielposterstatistik durchsucht die index-Datei des Forumsarchivs. Diese ist derzeit ca. 80MB groß.

Die Visitenkartensuche durchsucht die Datei whowhere.html, die derzeit etwa 52 KB groß ist.

Hinzu kommt, dass die Ausgabe der Vielposterstatistik in einer Tabelle erfolgt, was das Rendern der Seite noch verlangsamt. Wenn der Seitentitel jedoch in der Titelleiste erscheint, kann man davon ausgehen, dass das Perl-Skript seine "Arbeit" erledigt hat. Der Rest bis zum Erscheinen der Namensliste ist reines Browser-Arbeit.

Suche nach "Alexander" bei den SELF-Visitenkarten: ca. 3 Sekunden

Vielposterstat mit "alle Teilnhemer" aufrufen: ca. 68 sekunden bis zum Erscheinen des Titels, über 3 Minuten bis zum Rendern der Tabelle mit der Namensliste (7117 Zeile) mit dem IE 5.5

68 Sekunden, um 80MB durchzustöbern ist eigentlich gute Arbeit, oder was meinen die Profis?

Vielposterstats: http://www.atomic-eggs.com/selfspezial/sstattop.html
Visi-Suche: http://www.atomic-eggs.com/cgi-bin/suche.pl

Bis danndann
PAF (patrickausfrankfurt)

<img src="/selfaktuell/extras/selfcomm.jpg" alt=""> http://www.atomic-eggs.com/selfspezial/guests/advguest.cgi?view

<img src="http://www.atomic-eggs.com/selfspezial/atomicegg.gif" alt="Atomic Eggs - die humosophische Seite" style="cursor:hand;" onMouseUp="window.location.href='http://www.atomic-eggs.com/'" onmouseover="status='http://www.atomic-eggs.com/';return true;" onmouseout="status='';return true;">

[Steffen Wawryniuk]

68 Sekunden, um 80MB durchzustöbern ist eigentlich gute Arbeit, oder was meinen die Profis?

Wie stehen die 68s  im Bezug zu den bei Schlund & Partner angegebenen 6s Prozessorzeit ?
is die reine Prozessor Zeit noch was anderes ?
das CGI-Script wird doch auch nicht beendet bevor die Datei komplett eingelesen ist.
Also dürfte bei meinem Script das einlesen auch schon nicht länger dauern als ca. 5,9999 sek. oder wie ?

thx für eure hilfe
cu
Steffen

[Steffen Wawryniuk]

Hi,

danke erstemal schon für die Antworten...

das mit 'flock' wußte ich nicht, also thx werde ich implementieren

ne 8MB große Datei.... UPS soschlimm ... davon gehen ich nochnichtmal aus....

nochnichtmal 1MB sondern ca. 500 Zeilen mit je ca. 300-500 Zeichen.  Das dürfte doch keine Probs machen !?

Wegen Probieren, mach ich ja schon, blos Vorsorge is immer besser als...

also thx anyway
cu
Steffen

P.S: wegen bearbeitungszeit beim schreiben, also mit S&P hatte ich bis jetzt nur gute Erfahrungen.

[Peter Squentz]

nochnichtmal 1MB sondern ca. 500 Zeilen mit je ca. 300-500 Zeichen.  Das dürfte doch keine Probs machen !?

Noch einmal: Die Anzahl der Zeile ist irrelevant. Schon bei einer Zeile kann es zu einem gleichzeitigen Schreibzugriff kommen und dann geht es auf jeden Fall schief. Die Wahrscheinlichkeit steigt zwar mit wachsenden Zugriffen und wachsender Programmlaufzeit. Aber was schiefgehen kann, geht bekanntlich auch schief.

Peter

[Steffen Wawryniuk]

nochnichtmal 1MB sondern ca. 500 Zeilen mit je ca. 300-500 Zeichen.  Das dürfte doch keine Probs machen !?

Noch einmal: Die Anzahl der Zeile ist irrelevant. Schon bei einer Zeile kann es zu einem gleichzeitigen Schreibzugriff kommen und dann geht es auf jeden Fall schief. Die Wahrscheinlichkeit steigt zwar mit wachsenden Zugriffen und wachsender Programmlaufzeit. Aber was schiefgehen kann, geht bekanntlich auch schief.

Peter

Hi Peter,

Sorry evtl. habe ich mich für Dich ein wenig unverständlich ausgedrückt...

Dies was du beantwortest war das 2. Problem/Frage,

die 500 Zeilen mit je ca. 300-500 Zeichen beziehen sich auf mögliche überlastung des Servers (ich hab bei S&P ja die Bechränkung auf 6sek Prozessorzeit)

cu
Steffen

[Klaus Mock]

Hallo,

Also Prozessorzeit ist was anderes als reale Ausführungszeit. Wenn Patrick für 80MByte ca. 70 Sekunden braucht, um alles zu durchforsten, dann wird sicherlich weniger Prozessorzeit angefallen sein. Wieviel genau, ist schwer zu sagen, außer es werden Benchmarks davon gemacht. Hauptsächlich hängt das von der Rechnerauslastung ab, also genauer wieviel Prozesse zu einem bestimmten Zeitpunkt verarbeitet werden wollen.

Du darfst auch nicht vergessen, daß bei der Statistik auch sicherlich einiges an Rechenkram dazukommt. Ich denke 6 sec Prozessorzeit ist eigentlich schon recht lange für die ausführung eines scripts, welches nicht gerade 80MByte Daten nach allen Regeln der Kunst durchwühlt.

Filelocking ist in jedem Falle notwendig, wenn quasi gleichzeitig gelesen und geschrieben werden soll. Sollte Dir das Schreiben zu lange dauern, so daß zu viele Leseprozesse gesperrt werden, dann kannst Du auch in eine zweite Datei reinschreiben, welche dann erst nach dem Beenden des Schreibvorganges auf den anderen, eigentlich zu verwendeten, Namen umgenannt wird. Ist nur so eine Idee.

Grüße
  Klaus

[speedy]

Hi,

Ich denke 6 sec Prozessorzeit ist eigentlich schon recht lange für die ausführung eines scripts, welches nicht gerade 80MByte Daten nach allen Regeln der Kunst durchwühlt.

ich denke auch das 6 sec. Prozessorzeit ziemlich viel sind fuer ein Skript, das eine kleine Textdatei lesen und schreiben soll. Beim Ergebnis der Forumssuche wird immer eine Systemtime eingeblendet, die selten mehr als 1-2 Sek. betraegt obwohl die Suche wesentlich laenger dauert.

Gruesse
speedy

[Steffen Wawryniuk]

Filelocking ist in jedem Falle notwendig, wenn quasi gleichzeitig gelesen und geschrieben werden soll. Sollte Dir das Schreiben zu lange dauern, so daß zu viele Leseprozesse gesperrt werden, dann kannst Du auch in eine zweite Datei reinschreiben, welche dann erst nach dem Beenden des Schreibvorganges auf den anderen, eigentlich zu verwendeten, Namen umgenannt wird. Ist nur so eine Idee.

Grüße
  Klaus

Hi,

habe mich jetzt mal im Forums-Archiv mit 'flock'  belesen, doch irgendwie waren da 3 Meinungen meinungen zum sperren.

das die DATEI XYZ  zum schreiben gespert is is ja klar... (soll auch so sein)
aber zum lesen fand ich 3 verschiedene Meinungen.

die 1. auch zum lesen is die Datei gespertt
2. das Script versucht automatisch WIEDER drauf zuzugreifen
3. Datei darf gelesen werden

Was is denn nun richtig in bezug zum LESEN (nicht schreiben) von 'geflocketen' Datein ?

mfG  
Steffen

[Klaus Mock]

Hallo,

Was is denn nun richtig in bezug zum LESEN (nicht schreiben) von 'geflocketen' Datein ?

use Fcntl ':flock';

sub lesen
{
open(IN,$filename) or ExitWithError();
flock(IN,LOCK_SH);

hier auslesen

close(IN);
}

sub schreiben
{
open(OUT,">$filename") or ExitWithError();
flock(OUT,LOCK_EX);

hier rausschreiben

close(OUT);
}

Nur wenn Du auch beim Lesen ein flock() mit LOCK_SH machst, verhinderst Du, daß ein anderer Prozeß danach den File überschreibt, _während_ Du gerade rauslesen willst. Es verhindert jedoch nicht, daß andere Prozesse auch lesend zugreifen.

beim Schreiben soll aber niemand anders auf die Datei zugreifen, deßhalb ist es notwendig auch beim Lesen flock() aufzurufen, weil dieserr PRozeß ja sonst nicht weiß, ob die Datei nicht gerade gesperrt ist.

Dieser ganze Lockingmechanismus beruht allein darauf, daß alle Prozesse, welche auf die Datei zugreifen wollen, miteinander kooperieren.
Tom Christiansen hat das im Perl Kochbuch recht anschaulich mit einer Ampel verglichen. Wenn die Ampel auf rot steht (flock(LOCK_EX)) heißt das nur, daß keiner über die Kreuzung fahren _soll_ (Zugriff auf die Datei). Wenn irgendein Bastard sich aber einen Dreck drum schert und in die Kreuzung einfährt (kein flock() benutzt), dann kanns auch mächtig krachen ;-)

Grüße
  Klaus

[FrankS]

Hallo!

Als Ergänzung zu Klaus' Posting:

Der 2. Parameter beim flock kann folgende Werte annehmen.
LOCK_SH = 1
LOCK_EX = 2
LOCK_NB = 4
LOCK_UN = 8

LOCK_SH, shared lock
Datei ist gesperrt fürs schreiben, alle können lesen, ein flock(FH,4) eines Prozesses B wird blockiert, bis lock von Prozess A beendet wird

LOCK_EX, exclusive lock
Datei ist gesperrt füe alle anderen, nur der "Eigentümer" des lock darf zugreifen (schreibend und lesend). Alle anderen Prozesse werden bei flock(FH,1) oder flock(FH,2) blockiert.

LOCK_NB, non-blocking request
Datei wird gesperrt, es wird aber nicht gewartet, bis ein eventueller lock eines anderen Prozesse auf diese Datei beendet wird.

LOCK_UN, free the lock
Freigabe des locks, NICHT BENUTZEN!!!!. lock wird bei close(FH) implizit ausgeführt. Wird Prozess A zwischen flock(FH,8) und close(FH)  unterbrochen und ein bereits wartender Prozess B greift schreibend auf FH zu, dann...

Ein Beispiel aus dem Perl Kochbuch für LOCK_NB:
unless (flock(FH, LOCK_EXLOCK_NB)) {
    warn "can't immediately write-lock the file ($!), blocking ...";
    unless (flock(FH, LOCK_EX)) {
        die "can't get write-lock on numfile: $!";
    }
}

Gruß Frank

[Steffen Wawryniuk]

Hi,

danke an Euch beide,erstmal für die TIPS

ich denke das ich Euch jetzt aber rein Deutsch/gramati.... oder so noch immer nicht ganz verstehe bzw. noch die Frage nicht ganz beantwortet ist.

Also hier nochmal das Beispiel.:
und zwar is t mir noch immer nicht klar ob das BLOCKEN der Datei automatisch abläuft ...

also ich meine USER A ruft per Script die DATEI A zum schreiben auf,  diese wird geflockt...

jetzt kommt USER B will auch schreiben... kann/darf aber nicht....
und hier die entscheidene Frage (die mir immer noch nicht klar is...) wird das Script(Ausgabe) von USER B nun Abgebrochen mit Error  oder wartet das Script AUTOMATISCH bis USER A fertig ist und fängt dann sein schreiben/bzw. lesen der Datei an?

oder muss ich dann doch soeine Lösung mit einer Temporären Datei verwenden ???
thx nochmal

mfG
Steffen

[Klaus Mock]

Hallo,

Also hier nochmal das Beispiel.:
und zwar is t mir noch immer nicht klar ob das BLOCKEN der Datei automatisch abläuft ...

»»

also ich meine USER A ruft per Script die DATEI A zum schreiben auf,  diese wird geflockt...

»»

jetzt kommt USER B will auch schreiben... kann/darf aber nicht....
und hier die entscheidene Frage (die mir immer noch nicht klar is...) wird das Script(Ausgabe) von USER B nun Abgebrochen mit Error  oder wartet das Script AUTOMATISCH bis USER A fertig ist und fängt dann sein schreiben/bzw. lesen der Datei an?

»»

das häng davon ab, _wie_ Du lockst ;-)
wie Frank schon sagte, gibt es mehrere Werte für den 2. Parameter:
LOCK_SH = 1
LOCK_EX = 2
LOCK_NB = 4
LOCK_UN = 8

Als erfahrener Programmierer siehst Du sicherlich, daß die Werte Potenzen von 2 sind, d.h es werden Bits gesetzt. Das sollte Dich eigentlich aufhorchen lassen. Wenn solche Werte verwendet werden, gibts meist auch mögliche Kombinationen.

Wichtig sind eigentlich nur Kombinationen von LOCK_SH bzw LOCK_EX mit LOCK_NB. LOCK_NB steht, siehe perldoc, für 'non-breaking lock'. also _nur_ wenn Du eine Kombination mit LOCK_NB verwendest wartet das Script nicht, bis die Datei wieder frei ist.

das heißt im klartext und ohne schwafelschwafel:
mit flock(HDL,LOCK_SH) bzw. flock(HDL,LOCK_EX) wartet das Script bis die Datei frei ist, falls sie beim Aufruf gelockt ist, und lockst sie dann selbst.

mit flock(HDL,LOCK_SH+LOCK_NB) bzw. flock(HDL,LOCK_EX+LOCK_NB) wartet das Script _nicht_. (siehe auch das Beispiel von Frank)

Aber eigentlich steht das ja alles sowieso in der Doku
perldoc -f flock

Grüße
   Klaus

oder muss ich dann doch soeine Lösung mit einer Temporären Datei verwenden ???
thx nochmal

»»

mfG
Steffen

[Steffen Wawryniuk]

Aber eigentlich steht das ja alles sowieso in der Doku
perldoc -f flock

Grüße
   Klaus

hi,

danke nochmal, manchmal bin ich halt schwer von Kapee...
aber wegen der Perldoc... hmmm  naja okay also da kann ich dir nicht zustimmen ODER ich hab Version -3.04 Alpha

bei mir steht dat  nicht so TOLL ;-)

aber trozdem danke

mfG
Steffen

[Christoph Probst]

Hallo Steffen,

das mit 'flock' wußte ich nicht, also thx werde ich implementieren

Ich hatte auf meinem Server einige Probleme mit flock. Eine (etwas unsicherere aber
leichter zu implementierende) Alternative ist ein Lockfile.

Immer wenn ein Prozess schreiben will, erzeugt er ein Lockfile und die anderen Prozesse
pruefen ob das Lockfile besteht und warten, bis es verschwindet (denk an ein Timeout).

Noch besser ist folgendes:

Eine Datei ist gelocktet, wenn ein lock-file NICHT existiert. Denn loeschen ist ein Vorgang den
garantiert nur 1 Prozess genau 1 mal machen kann. Wenn das loeschen bei den naechsten Prozessen
fehl schlaegt ist die Datei gelockt. Wenn ein Prozess mit dem Schreiben fertig ist, erzeugt er die
Nichtlock-Datei wieder ...

Gruss Chris

[FrankS]

Hi, Steffen

ich meine ab wann dauert es ZU lange bzw. beansprucht den Server zu stark.

Darauf habe ich keine Antwort...

P.S: damit zusammen stellt sich bei mir auch die Frage:  Was passiert wenn USER A das
Script aufruft und die Datei geschrieben wird. und genau in diesem Augenblick USER B die Datei ließt ?

Das, was User B liest, ist unbestimmt.

Noch schlimmer wenn USER C AUCH NOCH die Datei schreibt. gehen da Daten verlohren ?

Ja, ohne besondere Massnahmen gehen hier Daten verloren. Es gibt verschiedene Ansätze, dies zu verhindern. Such mal im Archiv nach "flock". Damit kannst Du eine Datei sperren, nachdem sie geöffnet wurde. Damit ist sie für einen anderen Prozess (B), so dieser auch flock benutzt, gesperrt. Der Prozess B "steht" dann solange an seinem flock, bis Prozess A die Datei freigibt oder schließt. Ob dieser Mechanismus funktioniert, hängt u.a. von der Plattform (NT, UNIX...) und von der Implementierung des flock ab. Stichwort atomarer Befehl: Das flock darf nicht durch einen anderen Prozess unterbrechbar sein, der unterbrechende Prozess könnte ja auch ein flock auf die Datei machen wollen...
Verwirrung gestiftet?
Lies mal in Ruhe die Ergebnisse aus der Archivsuche. Dann wirds sicherlich klarer.

Gruß Frank

[Peter Squentz]

ab wieviel Zeilen (mal angenommen jede Zeile <250 Zeichen) wird es kritisch ?

Ab 1 Zeile wird es kritisch.

Oder gibt es da überhauptkeine komplikationen ?

Nein.

P.S: damit zusammen stellt sich bei mir auch die Frage:  Was passiert wenn USER A das Script aufruft und die Datei geschrieben wird. und genau in diesem Augenblick USER B die Datei ließt ?
Noch schlimmer wenn USER C AUCH NOCH die Datei schreibt. gehen da Daten verlohren ?

Zwangslaeufig gibt das Murks.

Peter

[speedy]

Hi Peter,

Ab 1 Zeile wird es kritisch.

Nein.

Zwangslaeufig gibt das Murks.

ich habe vergeblich versucht, mir die Sinnhaftigkeit und den Gehalt an "Hilfe" dieses Postings zu verdeutlichen... is mir nicht gelungen <g>

Gruesse
speedy