Massutskick med e-postmotor

Hejsan alla.

Jag håller på att optimera ett ASP-skript för att skicka ut e-postmeddelanden till en massa registrerade användare. Jag har en del frågor som jag har svårt att bilda mig en uppfattning om:

1. Eftersom det är ett skript och inte en DLL, hur många poster är det rimligt att klara av?

1a) Hur beror det på e-postservern och servermiljön i övrigt?
1b) Är belastningskurvan proportionerlig eller exponentiellt avtagande? Alltså om det tar 1 minut att skicka 1 000 meddelande - tar det 2 minuter att skicka 2000?
1c) Ponera att detta driftas på ett webbhotell - Är det rimligt att förvarna dem innan större utskick eller skall det anses ingå i ens rättigheter att nyttja tjänsten webbhotell (med tillhörande SMTP)?

2. Hur vet jag när jag uppnått optimum? Vad är rimligt att kräva av en sådan applikation? Finns det benchmarktider på t.ex. 10 000 mail? (Case-studier hos Dimac säger 15 000 mail på 15 minuter. Spontant tycker jag det låter långsamt.)

3. Gällande Dimacs w3 JMail, vad är det som skiljer tekniken att lopa genom eget recordset och skicka ett och ett eller att skicka recordsettet som in enparameter till MailMerge-funktionen och låta komponenten loopa istället? Hur kan det ena gå långsammare än det andra?

Den som har svar på detta, helt eller i delar, skall ha stort tack!

1b) Jag vet inte men det verkar otroligt att 2.000 mail skulle ta längre tid att skicka än 1.000 mail. Alltså, det borde ta dubbelt så lång tid.
1c) Webbhotell med e-postmöjlighet har nog en åsikt om detta. Förmodligen är det bättre att konsultera dom än att vända sig till forumet. Jag tror inte dom märker om du drar iväg ett gäng e-postmeddelanden. Du är ju trotts allt kund! Men som sagt, allt går att missbruka!

2. Jag tycker 15.000 medelanden på 15 minuter låter långsamt men det kanske tar lång tid att skicka e-post?

***
Ja, det är rätt mycket spekulationer i mitt inlägg, ha det i åtanke!

Jag har varit i kontakt med Dimac. De ger riktmärket 3000 mail per minut på en dedikerad P3 500 MHz med en komponent som kommunicerade med JMail.

Det ligger lite långt ifrån min fråga som gäller enbart skript och dessutom med en SMTP som kvoterar anatalet mail som respektive användarsession får skicka i stöten.

En rackarns massa okända variabler som kräver kvalificerade gissningar... bring 'em on.

r: stavfel

Det JMail gör är att den skickar alla mailen som finns i recordsetet till själva mailkön.

När du skickar ett mail så "pratar" komponenten och mailservern med varandra. Just detta kan ta olika lång tid pga en massa olika orsaker.

Jag gjorde ett test på en av våra servrar (PII 450 MHz) och den skickade ca 2 mail i sekunden med en komponent och skript där man själv loopar igenom alla mailen och skickar dem ett och ett.

Det med begränsningen av hur många mail man får skicka per session går ju att komma runt genom att skicka max antal mail i stöten och sedan köra Session.Abandon och redirecta tillbaka till samma sida men starta mail skicket där man slutade (som vanlig paging)

Fast, att skicka 10 000 mail på detta sätt e inte att rekomendera då det slöar ned servern rejält. Kolla istället om ditt webbhotell istället kan konfigurera en e-postlista åt dig (de flesta större mail-servers har den funktionaliteten)

cya,
PatrikB

Den kommande lösningen kommer företrädesvis att skicka HTML-mail (vilket kommer att ta längre tid än plain text antar jag). Vidare kommer recordsetet att skickas som inparameter och inte loopas utanför komponenten.

Slutligen får vi nog acceptera att vår session kvoteras jämte andra användare hos vår IPSs SMTP-server. Det vore inte schysst annars.

Tjänsten skall kopplas till kontaktregister och därför kommer e-postlistan att ständigt ändras.

Så, det jag undrar över är, benchmarktider för HTML-mail som skickas från samma session, med skript, med förutsättningar givna på ett webbhotell (dvs. ej dedikerad), medelst JMail-komponent som tar ett recordset snarare än skickar ett och ett med mailmerge-funktionen. (Smalspårig fråga? Javisst! :))

Kvalificerade gissningar i frågan är också intessanta givetvis.