Hallo,

ich überlege, ein Newsletter-Modul für mein CMS zu erstellen und möchte
gerne hier die technische Grundidee checken lassen:

Beim Versand existieren wohl, nach Google-Recherche, die beiden
Problematiken, dass bei z.B. bei 500 oder auch 12.000 Emails, die
Scriptdauer überschritten wird und auch der Mailserver des Providers
(einfaches Webpaket) eine solche Zahl nicht direkt abarbeiten kann.
Die Lösung ist ein "häppchenweises" abarbeiten, z.B. immer 20 Stück.
Wie dies realisiert wird, da gibt es verschieden Idee-Vorschlage von
Usern.

Was ich noch nicht gelesen habe, war ein Lösungsansatz mit der
Meta-Angabe refresh.

Meine Idee ist nun folgende:
Mit einem Klick auf "Start" wird eine PHP-Seite geöffnet (_blank), in
der eine Meta-Angabe für einen refresh alle 10 sec sorgt.
Das PHP-Script nimmt sich 20 Adressen, in denen Flag=0 ist, baut und
verschickt die Newsletter und setzt in den jeweiligen Adressen in der
MySQL-Tabelle den Flag=1.
Nach dem refresh kommen die nächsten dran, bis alle versendet wurden.
Ein CSS-Balken könnte sogar den Fortschritt anzeigen.

Die obigen Zeiten müssten sicher evaluiert werden.

Frage: ist die refresh-Sache praktikabel? Wo ist der Haken?
Gibt es das schon so oder ist das neu?

Vielen Dank für Eure Meinung,

Uli

Uli Albrecht wrote:

> ich überlege, ein Newsletter-Modul für mein CMS zu erstellen und mö=
chte
> gerne hier die technische Grundidee checken lassen:

> Beim Versand existieren wohl, nach Google-Recherche, die beiden
> Problematiken, dass bei z.B. bei 500 oder auch 12.000 Emails, die
> Scriptdauer überschritten wird und auch der Mailserver des Providers =

> (einfaches Webpaket) eine solche Zahl nicht direkt abarbeiten kann.

Ist dem so? Direkt beim Provider nachgefragt?

> Die Lösung ist ein "häppchenweises" abarbeiten, z.B. immer 20 Stü=
ck. Wie
> dies realisiert wird, da gibt es verschieden Idee-Vorschlage von Usern.=


Was hälst du von Cronjobs? Ermöglicht zudem auch zeitversetzten Versa=
nd...

> Meine Idee ist nun folgende:
> Mit einem Klick auf "Start" wird eine PHP-Seite geöffnet (_blank), in=

> der eine Meta-Angabe für einen refresh alle 10 sec sorgt.
> Das PHP-Script nimmt sich 20 Adressen, in denen Flag=3D0 ist, baut und =

> verschickt die Newsletter und setzt in den jeweiligen Adressen in der
> MySQL-Tabelle den Flag=3D1.
> Nach dem refresh kommen die nächsten dran, bis alle versendet wurden.=

> Ein CSS-Balken könnte sogar den Fortschritt anzeigen.

Was immer ein CSS Balken ist, einfache Punkte reichen auch.

> Die obigen Zeiten müssten sicher evaluiert werden.
>
> Frage: ist die refresh-Sache praktikabel? Wo ist der Haken?
> Gibt es das schon so oder ist das neu?

Es dauert in der Regel ewig. Wenn du noch personalisierte News
verschicken willst, kannst du auch das BCC Feld vergessen.

Dann noch Pause nach 20 Mails?

Frage mal lieber deinen Provider, ob es nun wirklich Beschränkungen
dieser Art gibt, ist nicht unbedingt immer so.

Gruß
Frank B.


--
"Unterwerfung ist die einzige bequeme Antwort auf Autorität"

Uli Albrecht schrieb:
> Hallo,
>
> ich überlege, ein Newsletter-Modul für mein CMS zu erstellen und möchte
> gerne hier die technische Grundidee checken lassen:
>
> Beim Versand existieren wohl, nach Google-Recherche, die beiden
> Problematiken, dass bei z.B. bei 500 oder auch 12.000 Emails, die
> Scriptdauer überschritten wird und auch der Mailserver des Providers
> (einfaches Webpaket) eine solche Zahl nicht direkt abarbeiten kann.

Da gibts ne ganze Menge zu sagen:

a) bei so einer hohen Zahl an Mails muss man aufpassen, dass man nicht
als Massmailer abgestempelt wird und so leicht auf Blocklisten landet
b) scripte die so lange laufen müssen/können blo ckieren den Webserver
nicht umsonst gibts ja da Beschränkungen
c) das hängt zum großen Teil von der Mailserver Konfiguration ab, z.B.
ob er DNS lookups macht etc.

> Die Lösung ist ein "häppchenweises" abarbeiten, z.B. immer 20 Stück. Wie
> dies realisiert wird, da gibt es verschieden Idee-Vorschlage von Usern.
>
> Was ich noch nicht gelesen habe, war ein Lösungsansatz mit der
> Meta-Angabe refresh.

Das ist Käse, das funktioniert nur solange jemand seinen Browser nicht
schließt.

>
> Meine Idee ist nun folgende:
> Mit einem Klick auf "Start" wird eine PHP-Seite geöffnet (_blank), in
> der eine Meta-Angabe für einen refresh alle 10 sec sorgt.
> Das PHP-Script nimmt sich 20 Adressen, in denen Flag=0 ist, baut und
> verschickt die Newsletter und setzt in den jeweiligen Adressen in der
> MySQL-Tabelle den Flag=1.
> Nach dem refresh kommen die nächsten dran, bis alle versendet wurden.
> Ein CSS-Balken könnte sogar den Fortschritt anzeigen.
>
> Die obigen Zeiten müssten sicher evaluiert werden.
>
> Frage: ist die refresh-Sache praktikabel? Wo ist der Haken?
> Gibt es das schon so oder ist das neu?

Die einzige vernünftige Lösung für sowas ist ein cronjob, per script
kannst du dann ganz gemütlich den Versand erledigen ohne den Server zu
belasten.

>
> Vielen Dank für Eure Meinung,
>
> Uli

Danke Stefan und Frank,

eigentlich suche ich nach einer Lösung, die bei jedem Provider und auch
bei einfachen Webpaketen funktioniert, auch wenn beispielsweise
Cronjobs nicht im Paket enthalten sind.

>> Meta-Angabe refresh.
>
> Das ist Käse, das funktioniert nur solange jemand seinen Browser
> nicht
> schließt.

Nun, der Admin der Seite, der den Versand anstößt, sollte schon nicht
so blöd sein, das Programm im laufenden Betrieb zu schließen (gilt
übrigends für jede Art Software ;-).

> Die einzige vernünftige Lösung für sowas ist ein cronjob

Ja, dachte ich mir. ist jedoch ein mir unbekanntes Feld.
Darum wollte ich meine refresh-Idee mal von Euch durchleuchten lassen.

PS: Ein CSS-Balken ist Fortschrittsbalken, der per CSS definiert wird.
Kein echter Begriff, sondern nur eine Kurztitel von mir.

Uli

Uli Albrecht schrieb:
> eigentlich suche ich nach einer Lösung, die bei jedem Provider und auch
> bei einfachen Webpaketen funktioniert, auch wenn beispielsweise Cronjobs
> nicht im Paket enthalten sind.

Gibt genug Anbieter außerhalb von Webhostern, die Cronjobs anbieten:
http://cron-job.org/cgi-bin/cronweb

Also bist damit auf jeden Fall unabhängig von deinem Anbieter, musst bei
den kostenlosen Angeboten aber meist auf Pünktlichkeit verzichten.

> Nun, der Admin der Seite, der den Versand anstößt, sollte schon nicht so
> blöd sein, das Programm im laufenden Betrieb zu schließen (gilt
> übrigends für jede Art Software ;-).

Warum jedesmal einen Admin dranhängen der Dummy Arbeit macht, wenn das
ganze ein Cronjob erledigen kann ganz automatisch.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann schrieb:
> Uli Albrecht schrieb:
>> eigentlich suche ich nach einer Lösung, die bei jedem Provider und
>> auch bei einfachen Webpaketen funktioniert, auch wenn beispielsweise
>> Cronjobs nicht im Paket enthalten sind.
>
> Gibt genug Anbieter außerhalb von Webhostern, die Cronjobs anbieten:
> http://cron-job.org/cgi-bin/cronweb
>
> Also bist damit auf jeden Fall unabhängig von deinem Anbieter, musst bei
> den kostenlosen Angeboten aber meist auf Pünktlichkeit verzichten.

Wenn es dir nicht um pünktlichkeit geht, du jedoch eine regelmäßig
frequentierte Webseite hast, ist natürlich eine weitere Lösung einen
cronjob zu simulieren:
Bei jedem Seitenaufruf der Hauptseite wird überprüft wie lange die
letzte Ausführung her ist, wenn mehr als X, führe das Script noch einmal
aus und setze die letzte Ausführung auf jetzt.

Denke aber daran dadurch keine allzu großen Verzögerungen der Hauptseite
einzubauen und dass jede andere genannte Lösung bis auf das Meta-Refresh
wahrscheinlich besser ist.

regards,
Jens

Jens Himmelrath schrieb:
> Wenn es dir nicht um pünktlichkeit geht, du jedoch eine regelmäßig
> frequentierte Webseite hast, ist natürlich eine weitere Lösung einen
> cronjob zu simulieren:
> Bei jedem Seitenaufruf der Hauptseite wird überprüft wie lange die
> letzte Ausführung her ist, wenn mehr als X, führe das Script noch einmal
> aus und setze die letzte Ausführung auf jetzt.
>
> Denke aber daran dadurch keine allzu großen Verzögerungen der Hauptseite
> einzubauen und dass jede andere genannte Lösung bis auf das Meta-Refresh
> wahrscheinlich besser ist.

Da verzögerst ja jeden Seitenaufruf weil die Mails häppchenweise
abgearbeitet werden. Bei großen Mengen bestimmt über Stunden je nachdem
wie gut die Seite besucht wird... :)

Da ist die Sache über Cronjob doch geschickter würde ich sagen. Einfach
alle 5 Minuten laufen lassen und erst schauen, ob mails verschickt
werden müssen, wenn ja die nächsten 100 oder so holen (oder alle, wenn
ConJob nicht nach ner Zeit gekillt wird).

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann schrieb:
> Jens Himmelrath schrieb:
>> Wenn es dir nicht um pünktlichkeit geht, du jedoch eine regelmäßig
>> frequentierte Webseite hast, ist natürlich eine weitere Lösung einen
>> cronjob zu simulieren:
>> Bei jedem Seitenaufruf der Hauptseite wird überprüft wie lange die
>> letzte Ausführung her ist, wenn mehr als X, führe das Script noch einmal
>> aus und setze die letzte Ausführung auf jetzt.
>>
>> Denke aber daran dadurch keine allzu großen Verzögerungen der Hauptseite
>> einzubauen und dass jede andere genannte Lösung bis auf das Meta-Refresh
>> wahrscheinlich besser ist.
>
> Da verzögerst ja jeden Seitenaufruf weil die Mails häppchenweise
> abgearbeitet werden. Bei großen Mengen bestimmt über Stunden je nachdem
> wie gut die Seite besucht wird... :)

Naja, je nach Besucherstrom, kann man pro Besucher 10-20 Mails
verschicken und alles läuft flüssig und ausreichend schnell.
Man kann auch einfach pro Besuch 1-2 Sekunden lang mails verschicken und
dann irgendwo vermerken wie weit man ist.

> Da ist die Sache über Cronjob doch geschickter würde ich sagen. Einfach
> alle 5 Minuten laufen lassen und erst schauen, ob mails verschickt
> werden müssen, wenn ja die nächsten 100 oder so holen (oder alle, wenn
> ConJob nicht nach ner Zeit gekillt wird).

Wie ich schrieb: Fast alles andere ist besser. Ich ging jedoch von einer
Situation ohne Cronjob aus und da halte ich das für eine mögliche
Alternative.

regards,
Jens

Jens Himmelrath schrieb:
> Wie ich schrieb: Fast alles andere ist besser. Ich ging jedoch von einer
> Situation ohne Cronjob aus und da halte ich das für eine mögliche
> Alternative.

Da gebe ich dir vollkommen recht. Aber aus welchem praktischen Grund
sollte man für dieses Problem auf CronJobs verzichten.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann schrieb:
> Jens Himmelrath schrieb:
>> Wie ich schrieb: Fast alles andere ist besser. Ich ging jedoch von einer
>> Situation ohne Cronjob aus und da halte ich das für eine mögliche
>> Alternative.
>
> Da gebe ich dir vollkommen recht. Aber aus welchem praktischen Grund
> sollte man für dieses Problem auf CronJobs verzichten.

Ich hatte lange mehr kein shared-hosting-Paket, aber zumindest vor ein
paar Jahren waren cronjobs noch nicht selbstverständlich.

regards,
Jens

Jens Himmelrath schrieb:
> Christoph Herrmann schrieb:
>> Jens Himmelrath schrieb:
>>> Wie ich schrieb: Fast alles andere ist besser. Ich ging jedoch von einer
>>> Situation ohne Cronjob aus und da halte ich das für eine mögliche
>>> Alternative.
>> Da gebe ich dir vollkommen recht. Aber aus welchem praktischen Grund
>> sollte man für dieses Problem auf CronJobs verzichten.
>
> Ich hatte lange mehr kein shared-hosting-Paket, aber zumindest vor ein
> paar Jahren waren cronjobs noch nicht selbstverständlich.

Ich mach mal die Ingrid.

Sorry, du meinst die wohl kostenlosen Angebote.
Ich hab damals mal eins genutzt, ich sehe folgende Nachteile:
- So wirklich zuverlässig war das zumindest damals nicht.
- Man hat eine weitere Komponente im Spiel
- Je nach Besucherzahl ist der externe Cronjob langsamer
- Bei hoher Besucherzahl kann man in kleineren Happen schicken - was den
Server gleichmäßiger auslastet

regards,
Jens

Jens Himmelrath schrieb:
> Sorry, du meinst die wohl kostenlosen Angebote.
> Ich hab damals mal eins genutzt, ich sehe folgende Nachteile:
> - So wirklich zuverlässig war das zumindest damals nicht.

Hatte nie Probleme mit dem Anbieter des beigefügten Links in einem der
letzten Beiträge.

> - Man hat eine weitere Komponente im Spiel

Und? eine unabhängige Komponente, die ihre Arbeit verrichtet ohne
Probleme. Klar wenn man keine eigenen CronJobs hat im Angebot, muss man
externe nutzen.

> - Je nach Besucherzahl ist der externe Cronjob langsamer

Ist doch egal wie langsam der ist, solange er seine Arbeit in
angemessener Zeit erledigt.

> - Bei hoher Besucherzahl kann man in kleineren Happen schicken - was den
> Server gleichmäßiger auslastet

Und bei jedem Besucher die Ladezeit erhöht, was für mich nicht wirklich
eine Alternative darstellt.

Aber da kann man ewig diskutieren. Der OP hat genug Informationen um
sein Problem zu bearbeiten. :)

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Jens Himmelrath:

> Naja, je nach Besucherstrom, kann man pro Besucher 10-20 Mails
> verschicken und alles läuft flüssig und ausreichend schnell.
> Man kann auch einfach pro Besuch 1-2 Sekunden lang mails verschicken
> und dann irgendwo vermerken wie weit man ist.

Alternativ könnte auch bei jeder Seitenanfrage ein Skript als
HTTP-Subrequest gestartet werden, bspw. als Skript, welches ein
transparentes GIF zurückgibt - und als Payload ein paar E-Mails
verschickt.

Gruß
Christoph

--
Today is Prickle-Prickle, the 14th day of Chaos in the YOLD 3174

Christoph Jeschke schrieb:
> Jens Himmelrath:
>
>> Naja, je nach Besucherstrom, kann man pro Besucher 10-20 Mails
>> verschicken und alles läuft flüssig und ausreichend schnell.
>> Man kann auch einfach pro Besuch 1-2 Sekunden lang mails verschicken
>> und dann irgendwo vermerken wie weit man ist.
>
> Alternativ könnte auch bei jeder Seitenanfrage ein Skript als
> HTTP-Subrequest gestartet werden, bspw. als Skript, welches ein
> transparentes GIF zurückgibt - und als Payload ein paar E-Mails
> verschickt.

Oder zwischendurch regelmäßig einen Dummy-XMLHttpRequest absetzen...
aber dafür sind wir hier in der falschen Gruppe.

regards,
Jens