Re: PHP und Zeitdauer einer Funktion

Ralf Bertoldi schrieb:

> ich stehe mit folgendem Problem etwas auf dem Kriegsfuss und weiss
> nicht wo ich suchen bzw. ansetzen soll.
>
> Ich habe eine PHP Routine die eine Datei ausliesst und dann Stück für
> Stück in eine mySQL Datenbank einliesst.

Was für eine Datei? Wie liest du die Daten (Code)?

> Das mache ich in einer Schleife solange was da ist (while..)

> Da viele 1000 Datensätze eingelesen bzw. aktualisiert werden bekomme
> ich ein Zeitproblem. Ich kann zwar auf meinem etwas betagten Testserver
> rumtricksen aber das ist nicht das was ggf. der Kunde möchte.

Vermutlich machst du viele 1000 einzelne INSERTs. Die kannst du in
Gruppen (zB von je 100) [1] zusammenfassen:
INSERT INTO tbl_name (a,b,c) VALUES(1,2,3),(4,5,6),(7,8,9),...
Damit wird das Skript etwa (natürlich nicht ganz) 100mal so schnell.
Außerdem kennt MySQL verzögerte INSERTs [2]. Für dein Skript werden die
Daten dann praktisch in Nullzeit[tm] eingetragen. Das macht natürlich
nur dann Sinn, wenn du nicht aus logischen Gründen warten musst, bis die
Übertragung vollständig ist.

> Wo wäre der Ansatz eine "Fortschrittsanzeige" also Feedback zu erhalten
> und sehr lange Operationen sicher lauffähig zu gestalten...

Optimiere erst mal den Transfervorgang; das ist wesentlich einfacher und
effektiver als eine Fortschrittsanzeige mit einem zustandslosen
Protokoll zu realisieren.

[1] http://dev.mysql.com/doc/refman/4.1/en/insert.html
[2] http://dev.mysql.com/doc/refman/4.1/en/insert-delayed.html

MfG
Niels

xpost & f'up2 dclp.datenbanken

--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · E-Commerce · Mambo Content Management |
------------------------------------------------------------ ----

Re: PHP und Zeitdauer einer Funktion

Niels Braczek schrieb:
> Ralf Bertoldi schrieb:

> Vermutlich machst du viele 1000 einzelne INSERTs. Die kannst du in
> Gruppen (zB von je 100) [1] zusammenfassen:

und, bei/vor jedem dieser inserts
* die Zeit weiter "raufdrehen" die das Script läuft: set_time_limit(5)
* eine Nachricht ausgeben: echo ...
* und den Buffer flushen: ob_flush oder von vorneherein abdrehen mit
ob_end_clean.

Btw glaube ich, dass man kritische Importiersachen eher über Cronjobs
oder anders automatisiert ablaufen lassen sollte und dem Benutzer auf
seinen Wunsch nur den Status zeigen sollte ...

Michael

Re: PHP und Zeitdauer einer Funktion

Hallo Niels,

das f'up ist in diesem Falle etwas Fehl am Platze.. kannst Du aber
nicht wissen. Die Datenbanken sind nicht der Knackpunkt sonder PHP und
IE, etc..


Niels Braczek wrote:
> Was für eine Datei? Wie liest du die Daten (Code)?

Ja, ich parse "delimited" Dateien und Grafik Dateien...
XML insert's habe ich nicht versucht, da ich nicht weiss inwieweit
mySQL 4.x XML kapiert.. meiner rudimentären Kenntnis nach nicht..
SQL Scripting geht AFAIK auch nicht..

> Vermutlich machst du viele 1000 einzelne INSERTs. Die kannst du in
> Gruppen (zB von je 100) [1] zusammenfassen:

Ja, ich fasse die Inserts zusammen mal 100 mal 1000... je nach dem ob
ich die Last Autoinc's brauche oder nicht..

> Außerdem kennt MySQL verzögerte INSERTs [2]. Für dein Skript werden
> die Daten dann praktisch in Nullzeit[tm] eingetragen. Das macht
> natürlich nur dann Sinn, wenn du nicht aus logischen Gründen warten
> musst, bis die Übertragung vollständig ist.

Delayed Inserts gehen nicht immer, siehe oben.. ab und an brauche ich
die Auto's..

> Optimiere erst mal den Transfervorgang; das ist wesentlich einfacher
> und effektiver als eine Fortschrittsanzeige mit einem zustandslosen
> Protokoll zu realisieren.


... echtdaten: um 20.000 Record's einzufügen/upzudaten brauche ich ca.
100.000 Abfragen. Diese sind unumgänglich da die Daten absolut blind
kommen. Im aller schlechtesten Falle kommen nochmal ca. 60.000 Grafiken
dazu die Serverseitig bearbeitet werden müssen. (ImageMagic, etc..)

Das parsen der Dateien ist ein Klaks...

Daher wäre die Fragestellung ob z.B. 20.000 inserts, 100.000 Abfragen
und 60.000 mal Bildbearbeitung auf einem einfachen Server in 30
Sekunden abgehandelt werden kann IMHO gegenstandslos... es geht einfach
nicht.
Ich bin leider gezwungen mit diesen Werten zu rechnen, obwohl ich bis
jetzt nicht über 12.000 rausgekommen bin.. aber >20.0000 stehen im Raum.

Ich könnte einen Cronjob anschmeissen der das macht...
Keine Ahnung wie PHP via .sh angeworfen auf derartige Ausführungszeiten
reagieren....

Zur Zeit favorisiere ich die Updates zu teilen in kleinere Einheiten
damit Ausführungszeiten für alle beteiligten (IE, PHP) in allgemein
gültige Grenzen kommen...

PHP und mySQL müssen in Version 4.x angesprochen werden!
Über mySQL mache ich mir keine Gedanken... die paar 10 oder 100
tausend Datensätze sollte die schon adäquat verwaltet bekommen.

Aber die Möglichkeit, mySQL wird primär via WEB Interface irgendwie
gefüttert, grosse Datenmengen (egal was!) zu bestücken bereitet mir
echte Kopfzerbrechen. Keine Feedback Funktionen... Timeout's aus den
Browsern.. PHP...

Ich bin echt kein PHP Guru und mySQL ist für mich immer noch eine WEB
Datenbank um ein paar tausend WEB-Shop Artikel oder Internetseiten zu
verwalten... daher steht die Fragestellung wie grosse Datenmengen
zwischen Client und Server gehandelt werden wenn nur PHP zur Verfügung
steht.... und das ohne Kommunikation. One-way TCP-IP ?... neee, das
geht nicht...


Niels, das ist nicht gegen Dein Posting. Dein Ansatz war absolut
korrekt! Es geht wirklich nur um Feedbackfunktionen bei der Ausführung.

Wie handelt man zeitintensive Operationen zu einem Client der im
Internet hängt...?

absolut ratlos.....

ralf