Mail nach XXX Sekunden verschicken

[godlike]

Jo, wie mach ich das am dümmsten. Hab in einer DB einen Timestamp (Unixtime). Nun soll der User nach X Sekunden eine Mail bekommen. z.B. nach 24 Stunden, nach einem Monat und nach einem Jahr. Hätte nun den Timestamp + die zusätzlichen Sekunden addiert und z.B. jede Stunde einen Cronjob laufen lassen der schaut auf welchen Timestamp in der DB das passt -> Sendmail.

Ist das ums Eck gedacht oder ne passable Lösung?

 

[KingJamez]

Genauso würde ich es auch lösen.
Ein Cronjob der ein Script anfeuert, das Script prüft, je nach aktuellem Timestamp, wer gerade berechtigt ist eine Mail zu bekommen, Senden der Mail.

 

[godlike]

Ok super, dann bastel ich mal was

 

[godlike]

Ok, wie sich herauskristallisiert hat ist das Ganze doch nicht so simpel. Es sollte nämlich, wenn möglich, auf die Sekunde genau eine Rückantwort gesendet werden. Sprich nach z.B. 6185 Sekunden, und die nächste dann nach z.B. 11233 Sekunden (Quasi nach oben offen). Alles basierend auf der Anmeldezeit des Users. Nun, um so genau zu sein müsste ich den Cronjob ja sekündlich ausführen - was ich ja quasi stecken kann oder? Immerhin könnte ich per SQL dann einen normalen SELECT machen und bräuchte kein BETWEEN 'X' AND 'Y'.

Geht das so überhaupt mit PHP oder sollte ich da gleich umsteigen (auf was auch immer)?

 

[drfuture]

Dann ist Mail evtl. so oder so nicht das Richtige.
Das ist für "Echtzeit" Kommunikation nicht konzipiert und spätestens seit es Spam gibt auch nicht mehr so gebrauchen.
Div. Mechanismen verlangsamen die Zustellung je nach Inhalt ja erstmal für x.

An sich ist 1x die Sekunde ein sql-Query und ein sendmail() Befehl kein so großes Thema... bei 10.000x die Sekunde würde ich mir evtl. sorgen machen.

 

[godlike]

Was wäre eine alternative Benachrichtigungsmethode? Da komm ich dann ja schon vom Thema Webserver weg oder? Da es am Ende wohl eh meistens an Handys geht. SMS? Oke, das mit der Mail hab ich mit den Momentanen Infos bzw. Zeiten auch verworfen.

 

[alter_Bekannter]

SMS wäre in der Tat ein Möglichkeit, in Bulk sind die recht günstig.

Worum gehts denn?

 

[godlike]

Genaueres kann ich dazu leider nicht sagen. Ein Dienst, evtl auch als App, bei dem es notwendig ist nach X Sekunden den registrierten Benutzer zu kontaktieren. Angebot für eine App usw. ist aber eh in Arbeit. Das mit den Benachrichtigungen wird da auch ein Thema sein. Dachte das man zumindest das mit den Benachrichtigungen zentral mit einer DB und Mails lösen könnte denn dann braucht man nicht zwingend eine Handynummer. Aber Ok, ich warte jetzt mal ab was so im Angebot steht.

Was heißt denn günstig? Was kosten z.B. 250.000 SMS?

 

[alter_Bekannter]

Wenns ne App ist dann kannste dir den Umweg doch sparen und die Benutzer intern kontaktieren.

Das einzige was dann halt noch immer nicht geht ist so richtig echtzeitaustausch, aber da du von Nutzern sprichst solls wohl an Menschen gehen. In dem Fall wäre das ja kein Problem.

 

[godlike]

Die App wäre quasi nur das Frontend. Ein wichtiger Part ist da noch ein Server der die ganzen Datensätze ja speichern soll. Gerade wenn man mal unabhängig eine Nachricht raus schicken möchte. Sprich die App müsste sowieso mit einem Server kommunizieren können. Ist aber wie gesagt Teil des Angebotes das in Arbeit ist.

Wenns ne App ist dann kannste dir den Umweg doch sparen und die Benutzer intern kontaktieren.

Wie meinst du das? Das es schon in der App vorgegeben ist schicke Nachricht "Hoi du Sepp" nach 7328 Sekunden? Naja, das kann sich erstens ändern und zweitens sollte man die Nachrichten schon zentral ändern / beeinflussen können. Das geht jetzt aber auch zu arg ins Detail. Wichtig war mit das mit dem Versenden mit PHP, Mail und ner DB. Das fällt jetzt ja wohl weg...

 

[alter_Bekannter]

Klar müsste die mit dem Server kommunizieren, aber da verstehe ich jetzt das Problem nicht.

Wie viele Millionen Nutzer hast/erwartest du das es ein Problem gibt wenn jeder davon sagen wir alle 10 Sekunden nach neuen Nachrichten fragt die in einer SQL Datenbank liegen?

 

[theSplit]

Kann man den Spieß nicht umdrehen? - Das PHP einen CronJob scheduled für die Zeit X mit der Übergabe welche Nutzer dann angemailt werden müssen? Vielleicht könnten die Daten auch aus Dateien kommen die nach Ablauf des Jobs gelöscht werden?

Oder ist es effizienter alle 10 Sekunden X Kundeneinträge nach "könnte/müßte" angemailt werden zu durchforsten?

Kenne mich dafür zu wenig aus wie das Tasken mit CronJobs funktioniert und wie performant/schonend das im Gegensatz zum DB Query wäre.

 

[alter_Bekannter]

Wenn man keine riesige und komplexe Datenstruktur hat kann man idR keine so kleinen Maschinen mieten das es noch eine Rolle spielt.

knapp am Topic vorbei:

Spoiler

Der technische Fortschritt ist schon schrecklich, die meisten Computekomponenten langweilen sich dauernd.
Das alte Gulli Board lief afaik auf nur 3 relativ normalen Servern. Grob geschätzt vermutlich Xeon Quadcores mit 16 bis 128GB RAM. Das weiss ich allerdings nicht, ist das öffentlich?

 

[theSplit]

Beantwortet jetzt aber nur indirekt meine Frage über Sinn oder Unsinn des "Einwurfs"

 

[alter_Bekannter]

Die Antwort war so genau wie es anhand der vorliegenden Informationen geht. Für ansprechendere Halbwahrheiten wenden Sie sich bitte an die PR-Abteilung, ich bin ein Techniker.

 

[godlike]

Klar müsste die mit dem Server kommunizieren, aber da verstehe ich jetzt das Problem nicht.

Sprich die Timestamps sind in der App selber hinterlegt und die App schickt dann diese SMS/Nachricht/Whatever? Die Benachrichtigung könnte auch im Handy erfolgen - die Idee ist echt klasse Da könnte man dann echt Traffik und Stress sparen. Auf die Idee bin ich in der Tat noch nicht gekommen. Den Inhalt der Benachrichtigung kann man sich sicherlich auch von nem Server abholen falls man das dynamisch haben will.

Wie viele Millionen Nutzer hast/erwartest du das es ein Problem gibt wenn jeder davon sagen wir alle 10 Sekunden nach neuen Nachrichten fragt die in einer SQL Datenbank liegen?

Naja, ausgelegt sollte das Teil schon für 50 bis 100 Millionen Nutzer (weltweit) sein Darum auch die Bedenken. Und jeder User kann Quasi mehrere "Jobs/Anmeldungen" tätigen die dann wieder für sich ihre eigenen Rückmeldungen produzieren. Es potenziert sich hier also sogar noch.

Kann man den Spieß nicht umdrehen? - Das PHP einen CronJob scheduled für die Zeit X mit der Übergabe welche Nutzer dann angemailt werden müssen?

[...]

Oder ist es effizienter alle 10 Sekunden X Kundeneinträge nach "könnte/müßte" angemailt werden zu durchforsten?

Naja SQL ist ja schon übel schnell. Wenn ich dann aber wirklich mal 150 mio DB-Einträge hab. Kein Plan

 

[drfuture]

Nuja mit Handy-App ist das ganze halt dann wie ein Messager...
die App hällt eine socket-verbindung zum Server und kann per Event benachrichtigt werden...
Die Zeitsteuerung kann schon zentral erfolgen - ein Cron pro sekunde ist wie gesagt nicht so viel finde ich.
Dann kommen Einträge in die Messanger-Tabelle mit username usw. und der Client holt sich die Nachricht oder wird per ping informiert das es eine neue Nachricht gibt und list die dann aus.

 

[godlike]

Oke, das ist wie gesagt eh die Aufgabe vom App-Entwickler. Also die Kommunikation App <--> Server. Wollte ja nur mal die Server-Möglichkeiten ausloten aber da muss dann auch einfach ein Crack her. Mal just4fun und zum ausprobieren. Wie erstelle ich mir am dümmsten eine 4-Spaltige Tabelle mit 50 Millionen Einträgen?

 

[Jester]

You do not have permission to view link please Anmelden or Registrieren

Per Skript

 

[godlike]

Danke!

Ich probiers mal mit SQL...

Edit: So, hab mal 25.000.000 Datensätze angelegt. Mal sehen wie der Query so funzt.

Edit2: Zu früh gefreut. Kann auf ein mal nur eine Million Datensätze erstelle

Edit3: So, DB mit 3,5 Millionen Einträge, der Query braucht zwischen 0,009 und 0,03 Sekunden.