Versand eines individuallisierten Newsletters via Cron-Job

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Versand eines individuallisierten Newsletters via Cron-Job

    Hallo,

    ich sitze vor einem Problem und weiß nicht, wie rum ich es am besten lösen könnte. Oder ob ich ganz am gesuchten Baum vorbeigetrottet bin.

    Gewünschtes Vorhaben:

    - Ein Autohaus mit allen gängigen Marken will jeden Sonntag einen Newsletter an Abonnenten versenden.
    - Der Newsletter soll die Fahrzeuge beinhalten, die innerhalb der letzten Woche hinzugekommen sind.
    - Es gibt zwei Arten von Abonnenten: Kategorie 1 bekommt alle neuen Fahrzeuge. Kategorie 2 bekommt nur neue Fahrzeuge der Marken, die abonniert wurden (es können n Marken gewählt werden).

    Mein eigentliches Problem besteht nun in der Dimension der ganzen Geschichte und in der Tatsache, dass das ganze über einen Cron-Job gelöst werden muss. Jede Woche kommen knapp über 100 neue Fahrzeuge hinzu. Die Anzahl der Abonnenten liegt bei mehreren Tausend.

    Ich habe mir überlegt, zuerst den Newsletter für die Abonnenten-Kategorie 1 zu versenden, da er für alle gleich ist und ich ihn somit als Blindkopie in einem Zug versenden könnte.

    Aber bei der Kategorie 2 ist das problematischer. Der Newsletter an sich muss ja für jeden Abonnenten neu erzeugt und versendet werden. Das würde bedeuten:

    1. Einen Abonnenten aus der Datenbank holen
    2. Fahrzeuge aus der Datenbank holen, die den Kriterien des Abonnenten entsprechen
    3. Newsletter generieren
    4. Newsletter versenden
    5. Betroffenen Abonnenten als erledigt markieren

    Bei 3.000 Abonnenten müsste sich das Skript also 3.000 Mal aufrufen. Ich bezweifle, dass der Server das freudig mitmacht. (Mir steht leider keine Möglichkeit zur Verfügung, das "kurz mal" zu testen.)

    Da ich noch nie sonderlich viel mit Cron-Jobs gemacht habe, stelle ich mir auch folgende Frage (alles PHP, "so nebenbei" erwähnt): Angenommen, der Cron-Job ruft jeden Sonntag um 02:00 Uhr das Newsletter-Bastel-Skript auf. Das Skript markiert nun alle Abonnenten als unerledigt, holt sich einen Abonnenten, bastelt den Newsletter, verschckt ihn, markiert den Abonnenten als erledigt und ruft sich nun selbst wieder auf (ohne anschließend wieder alle Abonnenten als unerledigt zu markieren). Wie realisiere ich denn den erneuten Aufruf? Die URL werde ich wohl nicht aufrufen können, also so, wie der Cron-Job das Skript aufruft? Z. B. dann mit exec() o. ä.?

    Möglichkeit zwei wäre, das Skript nur einmal laufen zu lassen, dann jedoch in einer Schleife. Nur frage ich mich, ob sowas wirklich "akzeptabel" ist. Dafür müsste ich den Skript-Timeout auf 30 Minuten oder noch höher stellen. Und das hat doch auch seine negativen Folgen, wenn sich ein anderes Skript "aufhängt" bzw. in einer Dauerschleife während anderer Entwicklungstests endet.

    Mir gefallen irgendwie beide Lösungen überhaupt nicht. Nur weiß ich leider nicht, wie man es anders - oder anders gesagt besser - lösen kann. Ich stehe hier absolut auf dem Schlauch. Hat jemand also irgendwelche Erfahrungen mit ähnlichen Fällen gesammelt oder sieht vielleicht sofort eine bessere Lösung?

    Meine bisherigen Massen-Newsletter-Lösungen sehen so aus, dass sich ein Skript in einem IFrame für jeden Abonnenten neu aufruft und dann die Individualisierung und den Versend vornimmt. So umgehe ich eine hohe Serverlast und das ganze kann Stunden dauern, ohne dass es den Skript-Timeout interessiert. Doch bei einem Cron-Job habe ich keinen Browser, in dem ich irgendwelche clientseitigen IFrames und JS-Reloads einbinden kann. Ich habe auch keine Möglichkeit, in den Ablauf einzugreifen oder ihn sonst wie zu beeinflussen, wenn er erstmal gestartet wurde.

    Vielen Dank,

    pb

    (Und nein, ich kann mich leider nicht kürzer fassen. Meine große Schwäche *G*.)

  • #2
    Praxiserprobter Ansatz:
    Der Cronjob startet alle 5 Minuten.
    Das PHP-Script holt die ersten x 'unerledigten' aus der DB,
    sendet denen ihre Mail und ist fertig.
    Sind keine 'unerledigten' mehr da, haben alle ihre Mail bekommen und man setzt sich irgendwo ein Flag (Timestamp), dass der Newsletter für diese Woche raus ist.

    Vorteil: Man bewirft den Mailserver nicht mit 3000 Mails auf einmal. Das packen die meisten zwar, aber nach meiner Erfahrung bekommst du dann bis ca. 1/3 Bounces. Die willst du (ggf. spätere Erweiterung deines Scripts) auch verarbeiten ... und ruckzuck packt es der Mailserver nicht mehr.

    Also wählt man - je nach Mailserver-Kapazität - zum Beispiel x = 100 und findet sich damit ab, dass das Script 30 mal laufen muß ... also der letzte NL nach 30*5min raus geht.

    Kommentar


    • #3
      Du siehst wirklich nur die Möglichkeiten einen oder alle zu versenden. Schade...

      Kommentar


      • #4
        Es bestünde natürlich noch die Möglichkeit, gar keinen zu versenden, TobiaZ ...

        Oder das paketweise Versenden, wie onemorenerds Vorschlag. Nur habe ich hier wieder ein kleines Problem (das ich mir vielleicht nur einbilde). Angenommen, es sind zur Zeit 3.000 Abonnenten und ich versende zyklisch 100 Stück, so richte ich für den Cron-Job 30 Aufrufe á alle 5 Minuten ein. Aber es kommen beständig neue Abonnenten hinzu, so dass ich, auch wenn ich einen Puffer für 1.000 Abonnenten einrichte, irgendwann erweitern, folglich regelmäßig die Abonnentenzahl überprüfen (lassen) muss. Hier fehlt somit die Flexibilität. Anders könnte ich natürlich das PHP-Skript für 5 Minuten pausieren und sich anschließend erneut aufrufen lassen, was auf mich wieder so einen sehr unschönen Eindruck macht.

        Kommentar


        • #5
          du sollst deinen cron IMMER alle 5 min laufen lassen. nicht nur am sonntag zwischen frühstück und mittag.

          davon abgesehen, habe ich sowas auch schon mal gemacht. hier habe ich den cron jeden minute laufen gelassen. das ist kein problem.

          nun brauchst nur noch einen cronjob, der am sonntag 1h die mailempfänger auf unerledigt setzt. fertig.
          INFO: Erst suchen, dann posten![color=red] | [/color]MANUAL(s): PHP | MySQL | HTML/JS/CSS[color=red] | [/color]NICE: GNOME Do | TESTS: Gästebuch[color=red] | [/color]IM: Jabber.org |


          Kommentar


          • #6
            wenn man bedenkt, wie viele seitenaufrufe der server aushalten muss, da wird ein minütlicher aufruf (der meist nichts tut) ohnehin nicht ins gewicht fallen.

            Kommentar


            • #7
              Gut, jetzt habe ich es erkannt und verstanden. Dann kann ich mich mal ans Basteln machen.

              Vielen Dank!

              Kommentar


              • #8
                Hallo vielleicht könnten wir eventuell uns gegenseitig helfen ich wiederum suche ein Script für den Autohandel mit Administration Oberfläche, mit einem Privatkunden und Geschäftskunden bereich natürlich Passwort gestützt…

                Grus Thomas

                Kommentar

                Lädt...
                X