Cronjob oder PHP gesteuert?

[mgutt]

Hallo,

ich habe eine Community, wo Mitglieder kurz vor Ablauf eines Datums (ist bei jedem Mitglied anders) eine Nachricht per Email erhalten sollen.

Nun fallen mir natürlich tausend Sachen ein, wie ich die Prüfung auf das Datum lösen könnte.

Ich würde das gerne so haben, dass die Email 3 Tage vor Ablauf raus gehen soll.

Die Prüfungsroutine beim Login des Users zu machen fällt raus, da ich nicht sicher sein kann, ob er sich auch in den 3 Tagen vor Ablauf noch einloggen wird.

Daher kommt ein externes Script in Frage, dass ich bei Cronjob einmal in der Nacht aufrufe oder ich mache es so, dass ich unabhängig von Cronjobs bin.

Eine Idee war, dass ich eine Cachedatei schreibe die als php-Datei includet werden kann mit einem Zeitstempel und wenn der Zeitstempel älter als 24 Stunden ist, dann durchlaufe ich z.B. 10 User (damits schön schnell bleibt) pro Aufruf der Loginseite. Demnach würde jeder Login jedes Users die Schleife auslösen, bis alle Emails versendet wurden und der Zeitstempel aktualisiert wurde.

Ist das die schnellste Variante oder würdet ihr es noch anders machen?

Gruß
Marc

[penizillin]

verschwenderisch... was spricht gegen einen cronjob, der um 00:01 ein skript ausführt, welches abfragt (sql?), welche benutzer benachrichtigt werden sollen. oder müssen die 72 stunden auf die sekunde eingehalten werden?

[TobiaZ]

Cronjob.

Das generieren deiner Mails gehört absolut nicht zur "Aufgabe" deiner Besucher...

*move* nach OT oder so. Ist ja kein PHP-Problem.

[mgutt]

Das Problem ist aber, dass ich mit einer Scriptabfrage nicht alle Mails raus bekomme (können durchaus mehr als 1000 auf einen Schlag sein). Daher würde mir ein Cronjob-Start nicht ausreichen.

Wenn mir jetzt jemand einen Cronjob nennt der nen Meta-Refresh versteht, dann bin ich dabei :P

[sysop123]

wenn du dir die mailfunktion ansiehst (mail(), kann man da problemlos ein array übergeben oder dein cron könnte 10 durchläufe a 100 mails machen.

den besucher zu strafen, indem du ihm den mailversand anhängst könnte vom besucher negativ aufgefasst werden.

[Quetschi]

Original geschrieben von mgutt
Wenn mir jetzt jemand einen Cronjob nennt der nen Meta-Refresh versteht, dann bin ich dabei :P

Werd das Gefühl nicht los, dass du da ein paar verschiedene Welten etwas durcheinanderbringst.

Du kannst die Abfragerei und Mailerei ruhig in PHP proggen, darin mit entsprechenden Schleifen deine 1000 oder Aber-Millionen Mails raushauen und das Script einfach mit nem Cronjob einmal täglich laufen lassen.

[RanzigeMilch]

er hat wahrscheinlich probs mit der laufzeit (kann eigentlich nur das sein was er meint)
aber selbst das kann man ja einstellen...

[TobiaZ]

Tja, gerade was den Massenmailversand angeht, so sollte man wenigstens ein bisschen wissen was man tut...

[mgutt]

Hi!

>>er hat wahrscheinlich probs mit der laufzeit
Natürlich meine ich die Laufzeit. Die Zeit ist nicht einstellbar. Ich rechne bei ca. 1.000 Emails mit einem Scriptabbruch. Die Menge kann aber durchaus 10.000 - 100.000 betragen je nachdem wie erfolgreich die letzte Kampagne war. Ist ein chinesisches Projekt, daher sind die Userzahlen etwas größer.

>>den besucher zu strafen, indem du ihm den mailversand anhängst könnte vom besucher negativ aufgefasst werden

Wie soll ich das verstehen? Der Besucher bekommt davon doch gar nichts mit. Wenn man beim Login 10 Mails raushaut, dann dürfte das zeitlich gegen Null tendieren und daher wird er auch kaum eine Verzögerung bemerken. Ich glaube daher, dass Du da was falsch verstanden hast.

Und die Ratio 1:10 (also ein Besucher "arbeitet" für 10 Besucher) ist denke ich zuverlässig UND schnell.

Wie man sieht mag ich Cronjobs nicht sonderlich, da sie nur Mehrarbeit in meinen Augen verursachen (Script + Cronjob > nur Script). Weiterhin mag ich es unabhängig von externen Diensten zu sein. So kann man jederzeit den Server wechseln. Aber ich habe Euch ja um Eure Meinung gebeten

Daher möchte ich noch mal die wichtigsten Punkte aufgreifen:

>>verschwenderisch...
Warum?

>>oder Aber-Millionen Mails
zeig mir ein Script, dass das kann. Und zwar ohne bcc und ohne dabei den Server lahm zu legen. Denn so viele Mails im Postausgang zu haben dürfte ziemliche Probleme mit sich bringen. Weiterhin bin ich davon überzeugt, dass bestimmte Provider eine gewisse Anzahl von Emails noch durchlassen, andere blocken sie aber erstmal ab. Ich kenne das z.B. von AOL, wo gerne mal 6-12 Stunden Verzögerung ein Thema sind.

>>sollte man ... wissen was man tut
Bereichere mich mit Deinem Wissen

Gruß
Marc

[wahsaga]

Original geschrieben von mgutt
Wie man sieht mag ich Cronjobs nicht sonderlich, da sie nur Mehrarbeit in meinen Augen verursachen (Script + Cronjob > nur Script).

Und das durch-jeden-Besucher-zehn-Mails-verschicken-lassen implementiert sich im Gegensatz zum Cronjob natürlich von alleine.

Weiterhin mag ich es unabhängig von externen Diensten zu sein.

Was hat den Cronjob mit extern zu tun?

[onemorenerd]

Original geschrieben von mgutt
zeig mir ein Script, dass das kann. Und zwar ohne bcc und ohne dabei den Server lahm zu legen. Denn so viele Mails im Postausgang zu haben dürfte ziemliche Probleme mit sich bringen.

Der Trick ist, dem SMTP-Server immer nur ein paar Mails in die Queue zu legen und dann so lange zu pausieren, bis er diese verschickt hat.

Ansatz:
Cron: "1 0 * * * /usr/bin/php /path/to/mailcatapult.php"
mailcatapult.php:

<?php
set_time_limit(0);
$to = /* billions of mail addresses from DB */;
/* ... subject, body, etc. */
for ($i = 0; $i < count($to); $i++) {
    mail($to[$i], /* subject, body etc. */);
    if ($i % 100 == 0) sleep(60);
}
?>

Berücksichtige aber, dass bei Massenmailings viele Bounces anfallen, die der Mailserver auch noch verarbeiten muß.

Original geschrieben von mgutt
Weiterhin bin ich davon überzeugt, dass bestimmte Provider eine gewisse Anzahl von Emails noch durchlassen, andere blocken sie aber erstmal ab. Ich kenne das z.B. von AOL, wo gerne mal 6-12 Stunden Verzögerung ein Thema sind.

Wenn dem so wäre, würde ich es völlig ignorieren, denn es ist Betrug am Kunden - die Provider blockieren u.U. NonSpamMails, das darfst du nicht auch noch unterstützen!

[Quetschi]

Das mit den Aber-Millionen war na nicht ganz ernst gemeint

Wenn du nen eigenen Server hast, leg dir ne eigene *.ini an, die du für das CLI benutzt in der dann kein max_execution festgelegt ist - dann musst du keine Angst vor nem Script-Abbruch haben - aber aufpassen, dass du den Speicher nicht vollaufen lässt.

[sysop123]

oder mach eine durchlauf mit z.b. 100 mails und dann ein refreh auf dein script und setze dort wieder an, wo du aufgehört hast (also1 - 100, refresh, 101 - 200, refresh, 201 - 300 usw)

was mir an deiner lösung aber auch garnicht gefällt, ist die tatsache, das jemand klicken MUSS, damait die mails versendet werden. bei 100.000 mails und bei jedem klick 10 mails versenden... hmm was machst du, wenn es nur 7000 klicks an diesem tag gibt, bekommen die restlichen 30.000 empfänger einfach kein mail oder werden die dann auf die nächsten 100.000 mails aufgeschlagen (macht am tag 2 dann ja schon 130.000 mails u.s.w)

es ist deine lösung, wenn du also unseren vorschlag nicht magst, gut, dann mach wie du willst. deine persönliche abneigung gegen cronjobs hat nichts damit zu tun, das cron die einzige richtige entscheidung wäre.

deine lösung wäre mir zu unsicher und zu sehr zusammen gefrickelt.

[zerni]

könnte man nicht einen Teil über andere User machen und dann den Rest mit Cronjob um die Last auf einmal zu verringern??

[tontechniker]

Was spricht denn gegen den Cronjob?