[php] n vcards erstellen, verzippen, zip speichern

K

Kampfwurst

Fleischersatz
ID: 87633
L
21 April 2006
911
146
Nabend,
ich habe vor, folgendes in Kürze zu realisieren:
Per Cronjob wird das hier besprochene Script ausgeführt. 1x in 24 Stunten. Das Script macht folgendes:
Es erstellt ungefähr 80 vcards (holt Infos aus Datenbank), packt alle in eine zip-Datei, die dann gespeichert wird, damit die User alle Adressen für ihren PIM gleichzeitig downloaden können und nicht jede dynamisch erzeugte vcard einzeln downloaden müssen.

Jetzt frag ich mich, wie ich das am besten realisiere:
Erst alle vcards erstellen, in einem Ordner ablegen und wenn das geschehen ist den gesamten Inhalt des Ordners verzippen? Oder kann ich die vcards auch alle im weitesten Sinne temporär erzeugen und in echtzeit in die zip packen?

Mir fällt grad aber folgendes ein.... Da es nur 80 User sind und auch nicht mehr werden.... und von den 80 Usern zu spitzenzeiten maximal 5 gleichzeitig online sind... wäre es sogar denkbar/klug das ohne cronjob zu machen? Also wenn ein User auf "download zip" klickt, die Zipdatei mit den vcards in echtzeit erstellt und an den user geschickt wird ohne sie zu speichern?

Hab echt keine Ahnung, was es da jeweils für Vor- und Nachteile gibt.... und ich hab genau so wenig Ahnung, wie serverlastig das zippen (bei den verschiedenen Möglichkeiten) ist.


P.S.: Hab schonmal n bisschen ganz unverbindlich gegooglet... Ich glaube aber, dass es hier einige Leute gibt, die da etwas mehr Ahnung haben. Weiß grad jemand zip-Klassen, die er mir Empfehlen kann? Oder von denen er mir vielleicht abraten würde?

Schonmal danke im Voraus und liebe Grüße
Marius
 
Die Serverlast ist ja die gleiche, wenn du alles gleichzeitig machst. Tun musst du das, was du willst, so oder so.

Die Cronjob-Frage: Sollen die vCards irgendwann benutzt werden, wenn sie kein User braucht? Ich vermute nicht, also kannst du dir den Cronjob eigentlich schon sparen.

Nachteil wäre halt, der User muss evtl. ein paar Sekunden warten, bis das Paket fertig is; mit Cronjob würde es schon im Regal stehen und du musst es ihm nur liefern. Diese "Wartezeit" liegt aber im Millisekunden- bis Sekunden-Bereich und wenn dein Server mal keinen guten Tag hat, dann kann keiner unterscheiden, ob der Server überlastet is oder du noch am Paketpacken bist.

Auf alle Fälle cachen, d.h. wenn einer das Paket abgeholt hat, speichere das Zip-File, damit du es für den nächsten, der es anfordert, nicht mehr von vorne packen musst, sondern gleich das fertige File liefern kannst.
mtime() hilft dir bei der Entscheidung, ob sich Neuschnüren lohnt oder du ihm das alte Paket überbringst.


Wegen der Echtzeit-Frage kann dir evtl. der Speicher, den PHP dir einräumt in die Quere kommen. Du brauchst ja zusätzlichen Overhead, wenn du vCards erstellst. Entweder du räumst gleich wieder auf oder du speicherst die vCards zwischen.

Ich persönlich würde zum Zwischenspeichern tendieren. So viel Festplattenspeicher belegen ein paar hundert vCards auch ned. Vielleicht kannst du auch hier, wenn du clever bist und LastModified-Angaben in der DB hast, was mit Caching drehen.
 
Tag, erstmal danke für deine Hilfe :) Werds also aller Wahrscheinlichkeit nach in Echtzeit machen.

mtime() find ich nicht bei php.net und bei mktime() weiß ich nicht, wie ichs bei der datei anwenden sollte. filetime() könnte mir da doch am ehersten behilflich sein, oder?

Nach meinem neusten Stand mach ichs so:
wenn vcards.zip älter als 24 std
dann vcards erstellen -> ./vcards; vcards zippen -> ./vcards.zip (alte ersetzen)
vcards.zip bereitstellen.

Okay so?
 
Kampfwurst schrieb:
filetime() könnte mir da doch am ehersten behilflich sein, oder?
Zum Vergrößern anklicken....
filemtime() meinte ich. Mensch, wenn man einmal ned im Manual nachguckt :doh:

Kampfwurst schrieb:
wenn vcards.zip älter als 24 std
dann vcards erstellen -> ./vcards; vcards zippen -> ./vcards.zip (alte ersetzen)
vcards.zip bereitstellen.

Okay so?
Zum Vergrößern anklicken....
Beim Rotmarkierten könnte man noch zusätzlich sparen:
Erstelle nur die vCards neu, von denen sich Teile geändert haben. Theoretisch kannst du dann soweit sparen, dass du sagen kannst "Warum soll ich nach 24h das Zip-Archiv neu herstellen, wenn sich keine einzige vCard seitdem verändert hat?".
 
theHacker schrieb:
filemtime() meinte ich. Mensch, wenn man einmal ned im Manual nachguckt :doh:

Beim Rotmarkierten könnte man noch zusätzlich sparen:
Erstelle nur die vCards neu, von denen sich Teile geändert haben. Theoretisch kannst du dann soweit sparen, dass du sagen kannst "Warum soll ich nach 24h das Zip-Archiv neu herstellen, wenn sich keine einzige vCard seitdem verändert hat?".
Zum Vergrößern anklicken....

Jo... da ist was dran!
Ich erstelle also die vcards (um zu sehen, ob sich da was von den alten unterscheidet) und entscheide dann (nach einer Abfrage ob jede einzelne sich von ihrem Vorgängermodell unterscheidet oder nicht) ob ich n neues achiv erstelle oder nicht. Belastet das den Server weniger? Wenn ich die vcards ohnehin erstellen muss... sollte ich statt der ganzen Abfragen dann nicht einfach n neues archiv erstellen?
Oder hab ich da was übersehen?
 
Kampfwurst schrieb:
Belastet das den Server weniger? Wenn ich die vcards ohnehin erstellen muss...
Zum Vergrößern anklicken....
Du musst sie ja nicht immer erstellen. Addressdaten ändern sich nicht 2x täglich.

Wenn dir die DB bei 79 von 80 Datensätzen sagt, es wurde nichts geändert, dann musst du nur ein einziges vCard-File neu erstellen. All diese Entscheidungen gehen mit der DB; der isses wurscht, wenn du vorher mal freundlich eine Abfrage zusätzlich verschwendest "Welche Datensätze wurden in den letzten 24h geändert?". Also keine Serverbelastung.

Sagt die DB "keine", so musst du nicht mal ein neues Zip-Archiv anlegen. Sonst holst du dir nur die geänderten Datensätze, updatest nur diese paar vCards und zippst alles nochmal.
 
Ohh. Ahh, jetzt wirds interessant :)

Kann ich die (mysql) db fragen, ob bestimmte Datensätze in den vergangenen 24 Stunden geändert wurde?
Wie? Oder müsste ich dann ne extra Timestamp-spalte hinzufügen, die bei ner Änderung aktualisiert wird?
 
Kampfwurst schrieb:
Oder müsste ich dann ne extra Timestamp-spalte hinzufügen, die bei ner Änderung aktualisiert wird?
Zum Vergrößern anklicken....
Genau; wie bereits in #2 (letzter Satz) erklärt.

Ich tippe mal stark drauf, dass du dann maximal einmal in der Woche überhaupt das Zip-Archiv anlegen musst. Wie gesagt: Adressdaten ändern sich normal nie ;)
 
Wie wäre es, einfach die VCard zu aktualisieren, wenn ein Benutzer etwas an seinem Profil ändert? Dann braucht man auch nicht das Änderungsdatum zu speichern... ;)
 
Hab ich auch schon drüber nachgedacht. Ist allerdings fehleranfällig, wenn ich mal per pma was änder.... zumal ich dann recht viel im vorhandenen script umbauen müsste, wodurch ich da auch noch einiges zerschießen könnte :D

Da bin ich dann etwas faul & feige und nehm etwas mehr Rechenleistung/Ausführungszeit in Kauf.
 
MrToiz schrieb:
Wie wäre es, einfach die VCard zu aktualisieren, wenn ein Benutzer etwas an seinem Profil ändert? Dann braucht man auch nicht das Änderungsdatum zu speichern... ;)
Zum Vergrößern anklicken....
Dann musste aber mit filemtime() ran und das gesamte Verzeichnis einlesen, um eine Änderung zu detektieren. Der Weg der "Gib mir alle, wo sich was geändert"-Anfrage an die DB gefällt mir besser.
 
theHacker schrieb:
Dann musste aber mit filemtime() ran und das gesamte Verzeichnis einlesen, um eine Änderung zu detektieren. Der Weg der "Gib mir alle, wo sich was geändert"-Anfrage an die DB gefällt mir besser.
Zum Vergrößern anklicken....

Naja, das ließe sich umgehen indem man in einer evtl. schon vorhandenen Config-Tabelle in der DB ein "Letzte VCard-Änderung"-Feld anlegt oder eine Indexdatei nutzt, die bei jeder Änderung getouch()t wird, somit bräuchte man nur noch eine Änderungszeit auslesen.
 
MrToiz schrieb:
Wie wäre es, einfach die VCard zu aktualisieren, wenn ein Benutzer etwas an seinem Profil ändert? Dann braucht man auch nicht das Änderungsdatum zu speichern... ;)
Zum Vergrößern anklicken....

finde ich auch die eleganteste Methode, egal ob du dann einiges am code ändern müsstest und nicht mehr mit pmy rumfummeln kannst :p
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben