Andreas Korthaus: /PERL Performance-Frage - Parsen

Beitrag lesen

Hallo!

Na, irgendwie habe ich das Gefühl, daß bei so einer Anwendung ein Massenhoster nicht gerade geeignet ist. imho wäre es Zeit sich zu überlegen, ob man nicht mit einem eigenen Server dann schon besser fährt. xDSL und Co. sind ja auch nicht mehr sooo teuer, daß man diesen Schritt nicht überlegen sollte.

Ja, das ist schon richtig, zum ienen Muß der Server der Webseite mit eingebunden werden, und ob man unbedingt den Webserver einer Internetseite selbst betreiben sollte ist fraglich, denn dazu braucht es erheblich mehr als die Hardware und einen SDSL-Zugang!

Wenn die Synchronisation nahc längerer Offlinezeit läänger braucht, dann sollte das eigentlich jedem klar sein. Und wenn Resourcen wirklich ein Problem darstellen, könntets DU ja in Deinem Synchronisationsschript Grenzen einbauen, sagen wir mal immer in 200er Schüben (wobei diese Zahl jetzt willkürlich ist), und die Synchronisation so oft wiederholen, bis alles da ist.

Gute Idee! So werde ich das zur Not machen, muß aber estmal mit "live-Daten" testen udn mir dann was entsprechendes überlegen.

Warum ich über die 2. Möglichkeit(multipart/form-data) nachdenke, ist da ich die Daten hier als Binästring übertragen kann, z.B. gzip, was über 80% Einsparung bedeuten würde.

Wobei Du bedenken mußt, daß die Verkleinerung der übertragenen Daten gleichzeitig auch erhöhten Rechenaufwand (de-/komprimieren) und Speicherplatz (komprimierte Daten und entpackte) bedeutet. Es ist eben abzuwägen, was mehr schmerzt.

Naja, das komprimieren dauert wirkich nur Sekundenbruchteile. Was schon etwas langsamer ist ist die zusätzliche Verschlüsselumng die ich auch noch einbauen muß, vermutlich läuft es auf symetrisches GPG hinaus. Wenn bei der Übertragung 10 KB eingespart werden, sind das bei  ISDN 1-2 Sekunden, das die engste Stelle denke ich, daher sollte ich wohl auch hier ansetzen.

Also meint Ihr man kann das Anfangs gepostete Script nicht mehr beschleunigen?

Irgendwie geht immer noch etwas. Aber ich vertrete da eher den Standpunkt, daß man sich erst kratzen soll, wenn es juckt.
Versuche einen Protottypen zu schreiben, der mit Beispieldaten handiert, um zu sehen, wie lange es wirklich dauert, und ob Du damit leben kannst.

Ja, daran arbeite ich. Ich hatte nur gedacht, wenn ich denn von vorn herein schon ein möglichst performantes Script verwende ist das ja auch nicht verkehrt!

Nur was noch dazu kommt, die aufgerufene Import-Funktion muß ja auch jedesmal erst mit einem SELECT ermitteln ob der Datensatz vorhanden ist und dann wieder in einer foreach-Schleife aus dem Daten-Array ein UPDATE oder ein INSERT machen und ausführen, da wird das ganze schon erheblich langsamer!

Gut an dem kommst Du wahrscheinlich sowieso nicht vorbei, egal wie Du es anstellst, wozu sich also darüber Gedanken machen.

Naja, eine Idee habe ich schon:
Ich speichere ein Flag zu jedem Datensatz in jeder Tabelle, und zwar ob bereits auf Master eingetragen oder nicht. Meinetwegen 0 heißt "noch nicht gespeichert" und 1 entsprechend.
Wenn dieses Flag auf 1 Steht generiere ich ein Update, wenn es auf 0 steht generiere ich ein Insert. Gleichzeitig generiere ich mit den Inserts Updates für den Client, das die Flags auf 1 gestellt werden, wenn die Inserts erfolgreich waren.  Die Inserts und Updates schreibe ich erstmal in einen String, den ich dann mit dem Kommandozeilentool mysql im Stapelmodus an MySQL schicke.

So kann ich das ganze zumindest auf dem Master erheblich beschleunigen. Leider geht das nicht anders herum, da der Master nicht über jeden Client so viele Informationen speichern kann.
Das ganze Problem könnte ich lösen, wenn ich einfach eine Spalte mit "Erstellzeitpunkt" einfügen würde, denn mit dieser Information, + der ClientID + Timestamp + Zeitpunkt der letzten Synchronisation habe ich alle Infos die ich brauche.
Das habe ich eigentlich anfangs ausgeschlossen, da ich bei "normalen" INSERTs in der Anwendung keine Rücksicht auf die Synchronisation nehmen wollte. Aber das funktioniert sowieso nicht, zumindest in meinem Fall werde ich die IDs(CHAR, bestehend aus ClientID.DatensatzID) ja mit einem anschließenden Update einfügen, um eindeutige IDs zu generieren, dazu würde ich dann eh eine Insert-Funktion schreiben, und da könnte ich auch direkt die Erstellzeit mit einfügen.
Das Problem ist das das ganze alles nur in meinem Kopf ist, ich bisher nur kleine Teile ausprobiert habe, da ich Angst habe alles doppelt und dreifach zu machen. Aber langsam sollte ich wohl mal eine Version umsetzen, denn nur daran kann ich sehen ob das im Betrieb gut funktioniert und einfach zu implementieren ist.

Viele Grüße
Andreas