[php] mail() gaat te langzaam; andere oplossing?

[BKJ]

Ik ben een site aan het ontwikkelen waarbij je bv een mailtje krijgt als je je hebt aangemeld of wanneer je je password kwijt bent.

Nu moeten bezoekers wachten totdat mail() zijn plicht gedaan. Dit geeft een lag van een aantal seconden (2 a 3). Het ligt prolly aan de sendmail instellingen maar kan ik niet dat gewoon dumpen in een queue of een background procesje starten?

Nadeel van een queue is dat bv een crontab die de queue leeg haalt maar max 1 keer per minuut draait. Ik heb liever dat ie direct een mail verzend.

Ik zat te denken aan bv een extern een php script te runnen met & vanuit het basisscript. Kan dit?

Iemand ervaring hiermee?

[--MeAngry--]

Iets van lag houd je altijd wel, maar aan je mail() commando kun je weinig doen, je moet de instellingen van je SMTP-deamon eens nakijken. Daarnaast vind ik 2 a 3 seconden geen noemenswaardig probleem voor het verzenden van een simpele activatiemail...

[Speedener]

Kan je niet zorgen dat er in een iframe een script wordt uitgevoerd die de mail verstuurd.

[BKJ]

Speedener schreef op 04 oktober 2004 @ 13:40:
Kan je niet zorgen dat er in een iframe een script wordt uitgevoerd die de mail verstuurd.

Snel wegklikken is dan wel funest.... Controleerbaarheid is lastig....

[Verwijderd]

verbinding maken met SMTP

[4VAlien]

Mocht je shell commando's kunnen doen dan zou je het natuurlijk naar de achtergrond kunnen gooien dmv een shell script/commando, maar 2-3 seconden, als je eerst ff meedeelt dat er een mail gestuurd wordt en dat flusht, dan weten de mensen waar ze op wachten.

[BKJ]

4VAlien schreef op 04 oktober 2004 @ 13:52:
Mocht je shell commando's kunnen doen dan zou je het natuurlijk naar de achtergrond kunnen gooien dmv een shell script/commando, maar 2-3 seconden, als je eerst ff meedeelt dat er een mail gestuurd wordt en dat flusht, dan weten de mensen waar ze op wachten.

Ik ga ervan uit dat er niet alleen maar tweakers op de site komen maar ook mensen zoals mijn of jullie ouders.... Als het sneller kan is het alleen maar beter...

[Verwijderd]

hitchhacker schreef op 04 oktober 2004 @ 13:37:
Het ligt prolly aan de sendmail instellingen maar kan ik niet dat gewoon dumpen in een queue of een background procesje starten?

Nadeel van een queue is dat bv een crontab die de queue leeg haalt maar max 1 keer per minuut draait. Ik heb liever dat ie direct een mail verzend.

Die ene minuut is imo verwaarloosbaar. Als er een mailserver tussen zit die mail scant op virussen en daar staat een queue, is je minuut winst ook verdwenen. Ik zou of gebruik maken een queue en dmv cron de mail versturen, of een directe verbinding maken naar een smtp server en dmv smtp commands de mail sturen.

[BKJ]

Verwijderd schreef op 04 oktober 2004 @ 13:56:
[...]


Die ene minuut is imo verwaarloosbaar. Als er een mailserver tussen zit die mail scant op virussen en daar staat een queue, is je minuut winst ook verdwenen. Ik zou of gebruik maken een queue en dmv cron de mail versturen, of een directe verbinding maken naar een smtp server en dmv smtp commands de mail sturen.

Ik heb even geprobeerd om via een socket de SMTP server direct aan te spreken maar de lag blijft helaas.

Even dan een andere vraag: hoe roep ik een php script aan in de shell met parameters? Ik heb niks kunnen vinden op php.net.

[ Voor 11% gewijzigd door BKJ op 04-10-2004 14:06 ]

[4VAlien]

http://nl3.php.net/shell_exec

[BKJ]

Ik meld toch nog ff de oplossing die ik nu heb gebruikt.

Ik heb een deamon gebouwd in PHP die om de x seconden een database checkt. Daarin staat het onderwerp, de tekst en waar die naar toe moet. Er is een kolom met status die, als hij nog niet verzonden is, op 0 staat.

De deamon checkt welke er nog op 0 staan (LIMIT 1). Verzend de mail en zet de status op 1.

Zo heb je als bezoeker geen lag en komt de mail toch snel aan.

[wasco]

die deamon, kan je ons daar meer informatie over geven. Hoe is hij gebouwd? Hoe zit het technisch in elkaar. Misschien wat source?

[BKJ]

wasco schreef op 12 oktober 2004 @ 10:57:
die deamon, kan je ons daar meer informatie over geven. Hoe is hij gebouwd? Hoe zit het technisch in elkaar. Misschien wat source?

PHP:

<?
require("functions.inc.php");


#maildeamon

$i = 0;
$verzonden = 0;

while ($i == 0)

{
    $query = "SELECT * FROM mails WHERE verzonden = '0' ORDER BY timestamp ASC LIMIT 1";
    $resultaat = mysql_query($query);

    while($obj =  mysql_fetch_object($resultaat)){
        $email = $obj->email;
        $voornaam = $obj->voornaam;
        $message = $obj->tekst;
        $subject = $obj->subject;
        $id = $obj->id;
        $myname = "Tweakers.net";
        $myemail = "[e-mail]";
        $headers .= "MIME-Version: 1.0\n";
        $headers .= "Content-type: text/html; charset=iso-8859-1\n";
        $headers .= "From: \"".$myname."\" <".$myemail.">\n";
        $output = $message;                
        $output = wordwrap($output, 72);
        mail("\"".$voornaam."\" <".$email.">", $subject, $output, $headers);
        unset($email, $voornaam, $message, $subject, $myname, $myemail, $headers, $output);
        $headers = "";
        $verzonden = 1;
    }

    if ($verzonden == 1) {
        $query = "UPDATE mails SET verzonden = '1' WHERE id='$id'";
        $resultaat = mysql_query($query); 
        $verzonden = 0;
        echo "Mail verzonden\n";
        }

    sleep(5);

}

?>

Deze run je gewoon als background proces en voila..klaar... nog opmerkingen?

[Verwijderd]

Die lag komt waarschijnlijk door je rfc1413 instellingen in sendmail.

Ikzelf gebruik exim en deze kent de opties:

rfc1413_hosts = [hosts] bv. aangegeven als *
rfc1413_query_timeout = [aantal seconden] bv. aangeven als 2s

wordt dan dus:

rfc1413_hosts = *
rfc1413_query_timeout = 2s


Sendmail zal deze opties ook wel kennen misschien is de syntax anders, maar een rfc is tenslotte een rfc.
Dus ff googlen en misschien dat dit je lag op lost.

[Grijze Vos]

Als een directe communicatie met de SMTP server zo traag gaat, zou ik eens kijken voor een andere SMTP server.

(kheb zelf net een communicatie-scriptje gebouwd voor SMTP, en dat doet het binnen 1/10e seconde hoor.)

[BKJ]

Grijze Vos schreef op 12 oktober 2004 @ 11:33:
Als een directe communicatie met de SMTP server zo traag gaat, zou ik eens kijken voor een andere SMTP server.

(kheb zelf net een communicatie-scriptje gebouwd voor SMTP, en dat doet het binnen 1/10e seconde hoor.)

Ik heb gewoon standaard sendmail....dat moet toch prima werken?

[Verwijderd]

hitchhacker schreef op 12 oktober 2004 @ 11:35:
[...]


Ik heb gewoon standaard sendmail....dat moet toch prima werken?

Dat moet ook prima werken. Is ook een oplossing van "Misschien moet je windows opnieuw installeren". Waarschijnlijk heeft Grijze Vos een smtp server geinstalleerd waarin rfc1413 standaard gedisabled is.

Kijk nou maar ff naar dat rfc1413 verhaal, ik denk dat daar je oplossing in te vinden is.
Lees dit maar eens:

http://groups.google.com/...lix.geog.mcgill.ca&rnum=7

[ Voor 11% gewijzigd door Verwijderd op 12-10-2004 11:42 ]

[HunterPro]

Verwijderd schreef op 12 oktober 2004 @ 11:30:
Die lag komt waarschijnlijk door je rfc1413 instellingen in sendmail.

Ikzelf gebruik exim en deze kent de opties:

rfc1413_hosts = [hosts] bv. aangegeven als *
rfc1413_query_timeout = [aantal seconden] bv. aangeven als 2s

wordt dan dus:

rfc1413_hosts = *
rfc1413_query_timeout = 2s


Sendmail zal deze opties ook wel kennen misschien is de syntax anders, maar een rfc is tenslotte een rfc.
Dus ff googlen en misschien dat dit je lag op lost.

Ik denk eerder nameserverinstellingen. Niet vlot genoeg kunnen resolven = timeout; mail() hoort normaal gesproken behoorlijk vlot er doorheen te rossen (at least met de 'direct mails' die ik de deur uit doe voor een klant duurt het echt geen 2 sec per request, ik doe eerder een kwart van de hele batch in 2 seconden )

[simon]

Ik zou je config van je sendmail wijzigen, en kijken naar een socket verbinding voor smtp, is sowieso sneller dan mail...

[Verwijderd]

HunterPro schreef op 12 oktober 2004 @ 11:44:
[...]

Ik denk eerder nameserverinstellingen. Niet vlot genoeg kunnen resolven = timeout; mail() hoort normaal gesproken behoorlijk vlot er doorheen te rossen (at least met de 'direct mails' die ik de deur uit doe voor een klant duurt het echt geen 2 sec per request, ik doe eerder een kwart van de hele batch in 2 seconden )

Kan dus nog steeds een rfc1413 instelling zijn omdat deze instelling controleerd of het domein waarnaar je probeerd te versturen een valid domain is. Dus gaat er inderdaad een dns lookup plaats vinden.

[LuCarD]

hitchhacker schreef op 12 oktober 2004 @ 11:15:
[...]


<SNIP>

Deze run je gewoon als background proces en voila..klaar... nog opmerkingen?

Paar kleine:
• Ik zou mysql_free_result() gebruiken, aangezien mysql_query elke keer een nwe result identifier terug geeft. Dit zou mogelijk een memoryleak veroorzaken. Normaal heb je hier geen last van aangezien aan het eind van een normaal script ( pagina ) het door php wordt gedaan. Maar jouw script blijft altijd door draaien.
• Alle tijdelijke variablen zijn eigenlijk niet nodig
• Kijk eens naar sprintf
• Waar gaat die echo heen? regel 39. Zou je die niet in een log file willen zetten

[ Voor 49% gewijzigd door LuCarD op 12-10-2004 11:51 . Reden: code uit de quote gezet, niet nodig voor reply ]

[BKJ]

LuCarD schreef op 12 oktober 2004 @ 11:51:
[...]


Paar kleine:
• Ik zou mysql_free_result() gebruiken, aangezien mysql_query elke keer een nwe result identifier terug geeft. Dit zou mogelijk een memoryleak veroorzaken. Normaal heb je hier geen last van aangezien aan het eind van een normaal script ( pagina ) het door php wordt gedaan. Maar jouw script blijft altijd door draaien.
• Alle tijdelijke variablen zijn eigenlijk niet nodig
• Kijk eens naar sprintf
• Waar gaat die echo heen? regel 39. Zou je die niet in een log file willen zetten

• OK..free_result lijkt me idd beter.
• Wat bedoel je met tijdelijke variabelen?
• Je bedoelt voor de formattering van de headers?
• Echo was als test. Tehcnisch moet een deamon eigenlijk geen raw output geven en zou een logfile idd beter zijn.

[LuCarD]

hitchhacker schreef op 12 oktober 2004 @ 11:57:
[...]


• OK..free_result lijkt me idd beter.
• Wat bedoel je met tijdelijke variabelen?

$email, $voornaam, $message, $subject, $myname, $myemail,

• Je bedoelt voor de formattering van de headers?

Niet alleen de headers.
bv

PHP:

 $query = sprintf("UPDATE mails SET verzonden = '1' WHERE id=%d",$id);

• Echo was als test. Tehcnisch moet een deamon eigenlijk geen raw output geven en zou een logfile idd beter zijn.

[simon]

LuCarD schreef op 12 oktober 2004 @ 13:36:
[...]

$email, $voornaam, $message, $subject, $myname, $myemail,

[...]

Niet alleen de headers.
bv

PHP:

 $query = sprintf("UPDATE mails SET verzonden = '1' WHERE id=%d",$id);

[...]

Wat is daarvan het voordeel boven $query = 'bla' . $variabele?

[LuCarD]

Simon schreef op 12 oktober 2004 @ 13:56:
[...]


Wat is daarvan het voordeel boven $query = 'bla' . $variabele?

1/ Je krijgt nu gegarandeerd een decimaal getal terug.
2/ Hij had inline variablen die zijn traag en onduidelijk, zo als jij het nu neer zet is natuurlijk ook goed

3/ Ik vindt het gewoon mooier Oog wil ook wat

[simon]

LuCarD schreef op 12 oktober 2004 @ 13:59:
[...]


1/ Je krijgt nu gegarandeerd een decimaal getal terug.
2/ Hij had inline variablen die zijn traag en onduidelijk, zo als jij het nu neer zet is natuurlijk ook goed

3/ Ik vindt het gewoon mooier Oog wil ook wat

Hmm, het lijkt mij technisch gezien 'trager', verder kun je via intval ook puur de integers waarden eruit halen...

[wasco]

misschien voor de volledigheid ook nog even zeggen hoe je dit als achtergrond process laat draaien? en ik heb nog een bijvraag maar ik weet niet of dit hier nu bij thuishoort, maar als je computer nu terug opstart, verliest hij dan dat process?

[4VAlien]

Waarom LIMIT 1 in die query? waarom niet alle uitstaande mails in een loop processen? Deze oplossing zal namelijkt nooit de laatste mails sturen als je meer dan 1 mail per 5 seconden aangeleverd krijgt. Misschien allemaal niet heel waarschijnlijk, maar toch netter om het gelijk op te lossen.


edit: waarom

PHP:

while ($i==0){}

en niet

PHP:

while(true){}

[ Voor 12% gewijzigd door 4VAlien op 12-10-2004 18:30 ]

[BKJ]

4VAlien schreef op 12 oktober 2004 @ 18:28:
Waarom LIMIT 1 in die query? waarom niet alle uitstaande mails in een loop processen? Deze oplossing zal namelijkt nooit de laatste mails sturen als je meer dan 1 mail per 5 seconden aangeleverd krijgt. Misschien allemaal niet heel waarschijnlijk, maar toch netter om het gelijk op te lossen.


edit: waarom

PHP:

while ($i==0){}

en niet

PHP:

while(true){}

Er zit een UNIX timestamp in die tabel. Volgens mij doe je dan altijd de mails op de juiste volgorde...of mis ik iets?

$i==0 was ff een snelle oplossing while(true) staat natuurlijk leuker.

[4VAlien]

je processed de mails wel in de goede volgorde, maar je doet maximaal 1 mail per 5 seconden ipv de hele queue.

[BKJ]

4VAlien schreef op 13 oktober 2004 @ 01:22:
je processed de mails wel in de goede volgorde, maar je doet maximaal 1 mail per 5 seconden ipv de hele queue.

Ik verwacht niet dat de site per 5 seconden een nieuwe member krijgt.

[E-Vix]

hitchhacker schreef op 13 oktober 2004 @ 09:16:
[...]


Ik verwacht niet dat de site per 5 seconden een nieuwe member krijgt.

Dan kan je die 2e while (regel 16) net zo goed vervangen door een if. Die while krijgt namelijk als hij al iets terug krijgt maximaal 1 waarde terug.

Persoonlijk zou ik toch de limit 1 uit je query verwijderen. Stel dat je in 5 seconden toch 2 inschrijvingen krijgt, dan verwerkt hij ze allebij direct na elkaar in plaats van 5 seconden te wachten.

[BKJ]

E-Vix schreef op 13 oktober 2004 @ 09:44:
[...]


Persoonlijk zou ik toch de limit 1 uit je query verwijderen. Stel dat je in 5 seconden toch 2 inschrijvingen krijgt, dan verwerkt hij ze allebij direct na elkaar in plaats van 5 seconden te wachten.

Dat is toch geen probleem? De lag is toch niet te merken door de bezoeker...

[djc]

Om even terug te gaan naar het originele probleem: volgens mij helpt het om sendmail te vervangen door exim. sendmail houdt op een of andere manier de functie veel langer vast, terwijl exim een buffer opbouwt waarna de PHP-functie snel klaar is (dat exim dan nog een tijdje bezig is merk je niet in je PHP script).