viele EMails senden (gelöst) (Allgemeines zu Perl)

[thread]17472[/thread]

viele EMails senden [gelöst]

Tags: perl5 email Ähnliche Threads

Leser: 26

Articles: hide open all | hide show old branches

+16 replies
Gustl

2012-06-11 08:46

User since
2011-01-27
443 Artikel
BenutzerIn

Hallo,

nach erstellen eines zb. Beitrags auf einer meiner Webseiten, soll an vielen angemeldeten Users eine Email bezüglich des neuen Beitrags geschickt werden.

Da ich dies nun nicht unmittelbar nach Erstellung des Beitrags machen möchte, da sonst der Benutzer ja warten muss bis alle EMails geschickt wurden, wollte ich mal wissen wie ihr dies macht!?

Cronjob ist eine Möglichkeit.
Was ich mir noch gedacht habe, das ich einfach, nach der Erstellung des Beitrags, mit einem img-Tag ein Perl-Skript lade. Das wird doch dann auch im Hintergrund auf dem Server ausgeführt oder?

Gruß Gustl
- +5 replies
- GwenDragon
  
  2012-06-11 08:53
  
  User since
  2005-01-17
  14866 Artikel
  Admin1
  
  Wieso warten?
  Möglichkeiten:
  Zum Senden des Mails nutze fork, damit nicht durch sendmail & Co. blockiert wird
  und/oder
  Vor dem Senden schreibe die erstellten Mails als Textdateien in ein Verzeichnis sozusagen als Warteschlange, zyklisch per Cronjob werden die dort gespeicherten Mails abgesandt.
  Oder missverstehe ich ich dein Problem mit dem Mailversand?
  Last edited: 2012-06-11 08:54:47 +0200 (CEST)
  die Drachin Gwen
  
  Meine Perl-Artikel · perldev – verschiedene Perl-Versionen unter Windows starten
  - +4 replies
  - Gustl
    
    2012-06-11 09:51
    
    User since
    2011-01-27
    443 Artikel
    BenutzerIn
    
    Ja, genau das ist mein Problem, bei vielen Mails hat der User eben eine lange Wartezeit.
    
    Die Idee mit den Textdateien ist nicht schlecht, aber da ich dafür keinen CronJob benutzen möchte, versuche ich das mit fork, wait.
    Daran habe ich gar nicht gedacht.
    
    Danke dir.
    
    Gruß Gustl
    - +3 replies
    - Gast linuxer_offline
      
      2012-06-11 10:12
      
      Hi, wie lange dauert denn der Mail versand so?
      Webserver können eine Begrenzung haben haben, wie lange ein (CGI-) Kindprozess laufen darf.
      
      U.U. wird dadurch auch der Prozess zum Mailversand abgebrochen.
      
      (Ich gehe einfach mal davon aus, dass es hier um CGI-Skripte geht.)
      Last edited: 2012-06-11 10:20:37 +0200 (CEST)
      - +2 replies
      - Gustl
        
        2012-06-11 12:53
        
        User since
        2011-01-27
        443 Artikel
        BenutzerIn
        
        Hi, wenn ich im cgi-skript so 50emails versende, läd der browser dann schon 2 oder 3sec. Was sich noch in Grenzen hält, aber falls es eben noch mehr werden, dann dauert es ja immer länger. Dem will ich vorbeugen.
        
        Die EMails sind nur reine Text-Emails ohne Anhänge.
        Ich würde dann mit fork je email einen kindprozess starten. Dann sollte die Begrenzung vom Webserver nicht ansprechen.
        
        Muss ich aber erst noch alles testen, habe mit perl fork noch nicht verwendet.
        
        Gruß Gustl
        
        Gast Muffi
        
        2012-06-11 13:48
        
        mit fork pro Mail würd ich aber mal gucken, dass du nicht in eine Prozessobergrenze bzw. Speichergrenze läufst, bzw. ob du überhaupt forken darfst.
        Last edited: 2012-06-11 13:49:58 +0200 (CEST)
- +5 replies
- rosti
  
  2012-06-11 22:23
  
  User since
  2011-03-19
  3712 Artikel
  BenutzerIn
  
  hi,
  
  den Versand asynchron abkoppeln mit ajax, würde ich so machen. Das ist noch am besten unter Kontrolle zu kriegen. Ich würde den Input in eine Tabelle schieben (Queue). Per ajax wird dann ein Prozess ausgelöst, der eine begrenzte Anzahl aus dieser Queue abarbeitet und die Records entsprechend markiert. Der ajax-Request kann von jeder beliebigen Seite aus gesendet werden. Einmal von der Seite mit dem Formular selbst aber auch von jeder andereren Seite, die öfter mal aufgerufen wird.
  
  --Rosti
  http://rolfrost.de/wallpaper.html
  
  WallPaper -- jeden Monat neu. Mit nur 2 Klicks den Aktuellen Monat auf dem Desktop.
  - +4 replies
  - Gustl
    
    2012-08-01 18:23
    
    User since
    2011-01-27
    443 Artikel
    BenutzerIn
    
    Hallo rosti,
    
    Dein Vorschlag klingt ganz gut.
    
    Ich beschreibe jetzt mal wie ich mir das gedacht habe:
    In der Datenbank erstelle ich eine Tabelle emails, dort werden alle emails die abgeschickt werden sollen eingetragen. Nach einem Insert von ca. 200 Datensätze(emails) setze ich eine Variable im Frontend input-hidden feld auf 1, diese wird bei fertigladen der Seite per Javascript ausgelesen und, falls diese auch 1 ist, wird per Ajax ein Perl-Skript aufgerufen welche dann, sagen wir mal 100 Emails verschickt und diese dann anschließend in der DB markiert.
    
    Beim nächsten Besucher der meine Seite dann refresht, wird wird die tabelle emails dann geprüft ob noch welche zu verschicken sind. Wenn ja, wird der Wert von dem hiddenfeld wieder auf 1 gesetzt und mein perl-skript das per ajax aufgerufen wird sendet dann den Rest.
    
    So würde ich das jetzt realisieren. Wie denkst du /ihr darüber?
    
    Gruß Gustl
    - +3 replies
    - Raubtier
      
      2012-08-01 18:32
      
      User since
      2012-05-04
      1083 Artikel
      BenutzerIn
      
      Das hört sich aber ziemlich kompliziert an. Nur weil Ajax exisitert, muss man es nicht für alles nutzen! In dem Moment, wo du dein Hidden-Feld mit der 1 absendest, weißt du doch schon auf dem Server, dass du Mails versenden willst. Warum willst du das wieder vegessen und dann vom Script per Ajax erneut "herausfinden"?!
      - +2 replies
      - Gustl
        
        2012-08-01 19:04
        
        User since
        2011-01-27
        443 Artikel
        BenutzerIn
        
        Javascript soll ja nur email_send-skript im Hintergrund starten wenn emails zu senden sind. Deshalb die lösung mit den hidden. Oder geht das auch anders? Ich könnte natürlich auch direkt einen javascript in html ausgeben und dort dann die variable setzen. das stimmt. Aber eine andere Lösung fällt mir jetzt nicht ein.
        
        Besorgt bin ich dann "nur" bei dem insert von 200 Datensätzen, da dies ja auch "etwas" länger dauern und das geht dann auf die Wartezeit vom Benutzer.
        
        Mit fork habe ich es so probiert:
        
        Code (perl): (dl )
        
        1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39
        
        sub test(){ my @b; foreach(1..10){ $b[$_]->{send_to} = "gustl1und1\@online.de"; $b[$_]->{username} = "Gustl"; } send_emails(\@b); } sub send_emails{ my @mail = @{$_[0]}; my $type = $_[1]; my $mailprog = '/usr/lib/sendmail'; my $pid = undef; foreach(@mail){ if (defined($pid = fork)) { if ($pid) { #Eltern #print "Eltern: Kind $i ($pid) gestartet \n"; } else { #Kind my $mailfrom = $Glob::mailfrom_support; my $name = "TRAIN your programmer Support"; my $subject = "TRAIN your programmer - Test"; my $body = "TEXTE TEXT TEXT TEXT!"; open (MAIL, "|$mailprog $_->{send_to}") || die "Cant open $mailprog!\n"; print MAIL ("To: $_->{send_to}\n"); print MAIL ("From: $name <$mailfrom>;\n"); print MAIL ("Subject: $subject\n\n"); print MAIL ("$body"); close (MAIL); last; } } } }
        
        Dann rufe ich test() auf, aber dann sehe ich 10x mein content auf einer Seite. was ja klar ist, weil der Kindprozess alles vom ELternprozess übernimmt.
        Somit müsste ich ein eigenes Script schreiben welchem dann das gesamte email_array als parameter übergeben wird. Aber das geht ja nicht, da der GET ja eine Begrenzung hat, somit könnten emails verloren gehn.
        
        Deshalb favorisiere ich im Moment die AJAX-Lösung.
        
        Muffi
        
        2012-08-01 22:11
        
        User since
        2012-07-18
        1465 Artikel
        BenutzerIn
        
        200 inserts sollten in einem schwupp passieren. Ich glaub nicht, dass man da Wartezeit bemerkt.
        Schlimmstenfalls machs mit einem
        
        Code: (dl )
        
        INSERT INTO foo (a,b,c) VALUES (1,2,3), (4,5,6), (7,8,9), ...
        
        1 + 1 = 10
- +4 replies
- Linuxer
  
  2012-08-01 22:32
  
  User since
  2006-01-27
  3891 Artikel
  HausmeisterIn
  
  Warum muss der Benutzer warten, dass Du das Skript die Emails verschickst?
  
  Gedanken zu einem reinen simplen CGI Skript:
  
  - Benutzer ruft Seite mit Formular auf, trägt Daten ein und schickt diese ab
  
  - das aufgerufene CGI-Skript verarbeitet die Daten und trägt sie in die DB-Tabelle ein
  
  . dann gibt es eine entsprechende Ergebnisseite aus, damit der Benutzer weiß, dass seine Daten eingetragen wurden
  
  - das Skript schließt nun den Ausgabekanal, womit für den Browser die Verbindung beendet ist (und der Benutzer anschließend nicht weiter warten muss)
  
  - das Skript selber läuft aber noch weiter und verschickt die noch ausstehenden Mails
  
  - Je nachdem, wie lange das Skript zum Versenden braucht, muss man eventuell darauf achten, dass die Laufzeit nicht zu hoch wird, weil es ansonsten vom Webserver u.U. beendet wird.
  
  - Den Punkt "Ausgabekanal schließen und dann noch Emails versenden" könte man auch bei "normalen" Requests machen, sodass sich u.U. nicht zuviele Emails ansammeln...
  meine Beiträge: I.d.R. alle Angaben ohne Gewähr und auf Linux abgestimmt!
  Die Sprache heisst Perl, nicht PERL. - Bitte Crossposts als solche kenntlich machen!
  - +3 replies
  - Gustl
    
    2012-08-01 22:43
    
    User since
    2011-01-27
    443 Artikel
    BenutzerIn
    
    Hallo,
    
    wenn das so einfach wäre würde ich mich freuen.
    
    Wie schließe ich denn den Ausgabekanal im Script ab? Das läuft ja linear ab.
    
    Ich benutze CGI mit HTML::Template.
    Habe gerade probiert die Emails nach dem $template->output(); zu schicken, aber das dauert genauso lange.
    
    Gruß
    - +2 replies
    - Linuxer
      
      2012-08-01 22:53
      
      User since
      2006-01-27
      3891 Artikel
      HausmeisterIn
      
      Habe gerade keinen Server zur Hand, kann es also nicht testen.
      
      In der Regel gibt das Skript die Daten für den Browser via STDOUT aus.
      Das ist ein ganz normaler Handle, den man mit close auch schließen kann.
      
      Wenn man sich sicher ist, dass keine Daten mehr zum Browser geschickt werden müssen, kann man STDOUT eben schließen. Damit wird der Datenkanal zum Browser geschlossen.
      
      Schema-Beispiel:
      
      Code (perl): (dl )
      
      1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
      
      #! /usr/bin/perl use strict; use warnings; use CGI; my $cgi = CGI->new; print $cgi->header('text/plain'); print "Gestartet: " . localtime($^T) . "\n"; sleep int(rand(6)+1); print "Ausgabe Ende: " . localtime() . "\n"; # hiernach ist keine Ausgabe mehr an den Browser moeglich close STDOUT; # andere Jobs, die Zeit kosten sleep 5; # Kontrolle nach STDERR (ins Log, ...) warn "andere Jobs Ende: " . localtime() . "\n"; # Skript Ende exit 0; __END__
      
      meine Beiträge: I.d.R. alle Angaben ohne Gewähr und auf Linux abgestimmt!
      Die Sprache heisst Perl, nicht PERL. - Bitte Crossposts als solche kenntlich machen!
      - Gustl
        
        2012-08-01 23:37
        
        User since
        2011-01-27
        443 Artikel
        BenutzerIn
        
        Ja SUPER! :)
        
        Code: (dl )
        
        close STDOUT;
        
        funktioniert klasse.
        
        Hab es gerade mit 500 EMails probiert, ging alles gut.
        
        Wieder was gelernt, freut mich. :)
        
        Dankeschön.
        Gruß
        Last edited: 2012-08-01 23:43:54 +0200 (CEST)
- Froschpopo
  
  2012-08-01 22:39
  
  User since
  2003-08-15
  2653 Artikel
  BenutzerIn
  
  Hm, reicht denn der Postfix-Queue nicht aus? das ist doch schon eine Warteschlange und wie die abgearbeitet wird, kann man ja auch vorgeben.
  
  Ich mache es allerdings auch ähnlich. Ich speichere die Mails zunächst in einer Datenbank die ich dann regelmäßig per Cron abarbeite.
  Ich gehe sogar noch etwas weiter und schreibe in die Datenbank nur JSON, welches ich dann mittels JSON.pm und Text::Template in eine Template-Datei einsetze. Also sehr geringer Speicherbedarf.
  Last edited: 2012-08-01 22:42:34 +0200 (CEST)

View all threads created 2012-06-11 08:46.