Hallå!

Vi har nyligen byggt om vår nyhetsbrev-funktion för att kunna inkludera namn och liknande uppgifter i utskicket. Detta har medfört att vi måste skicka ett mail per mottagare, och inte som tidigare lägga till alla i BCC. Detta pressar naturligtvis servern mycket mer, faktiskt alldeles för mycket.

Jag har genom lite tester kommit fram till att det är själva skicka-förfarandet som belastar servern, och tar lång tid. Jag är nu ute efter en lösning som dels minskar belastningen på servern (har en idé om att flytta bearbetningen till en annan server) och dels minskar tiden som webbläsaren blir upplåst. Det senare löser sig ju inte bara för att vi belastar en annan server istället för webbservern.

Teknik som används idag är ASP på Windows 2000 Server, och mailen skickas med CDONTS.

Vilken server är det som det belastar för mycket? Webbservern? Måste klienten vänta medan alla mail skapas och skickas?

Vi löser samma problematik med en demon (service) som skapar mailen och lägger dessa i ut-kön på smtp servern direkt. Demonen uppdaterar statistik som klienten ser.

Det enda klienten måste vänta på är att urvalet skapas och ett jobb initieras.

EDIT:
Tillägg

Arbetet är naturligtvis lika hårt för maskinen som skapar mailen... Men det kan vara en helt annan maskin.

Det är ju precis detta jag är ute efter. Det är webbservern som belastas, och klienten måste vänta medan alla mail skickas. Själva skapandet, och urvalet tar ca 10 sekunder, och presenteras i ett formulär, men skickandet tar betydligt längre.

Hur är detta löst, vad ska jag göra för att hantera detta?
SMTP-servern är och IIS ligger på samma maskin.

Att göra ett urval för ett utskick på 10s låter mycket. hur många poster handlar det om egentligen?
Och eftersom det känns som om urvalet tar lång tid misstänker jag att index inte används korrekt i databasen och om mailen skall "fixas till" för resp mottagare innebär det ju en del DB access även när breven skall skickas och om index även härt används fel så...

Så det kan ju vara värt att kika på exakt vad det är som tar tid.

Givet att det verkligen är skickandet som tar tid (pga att det är väldigt många mail som skall skickas), så föreslår jag att du "köar" utskicken och låter en demon/service beta av kön på låg prioritet så att du får iväg mailen under en längre period, men utan att sänka servern.

Men som sagt, jag är lite skeptisk till att DBn verkligen är optimerad i den omfattning som behövs.

Det rör sig om ca 60000 kunder som ska utvärderas utifrån ett urval av antal ordrar under en viss tidsperiod, total ordersumma under en viss period, registrerad inom en viss period, leveransadress inom en viss zon mm. Alltså ett ganska komplext urval.

Det är alltså detta jag vill förbättra prestandan på. Att skapa mailet och att göra urvalet tar några sekunder, beroende på vilket urval man har valt. Att skicka mailet tar en evighet.

Två förslag säger här att man kan "köa" utskicken, och det låter som en jättebra idé, men hur gör jag det?

Att skicka förfrågan till en annan dator skulle ju minska belastningen på webbservern, vilket skulle vara väldigt positivt, men jag vill fortfarande slippa ha klienten upplåst tills alla mail är skickade.

Antar att du redan (om möjligt) kör utskicken den tid på dygnet då belastningen på din webbserver är som minst, tex kl 04 på natten?

Nej det gör jag inte.. Eller "om möjligt" kanske. Det är inte riktigt möjligt. Dessutom har vi ganska bra belastning på servern dygnet runt. Klockan fyra börjar vi sammanställa dagens ordrar för att planera budbilarnas rutter, beställa hem färskvaror, och plocka ihop beställningar.

Ett urval på 60000 poster är inte speciellt stort egentligen. Jag låter kanske som en trasig skiva, men 10s låter fortfarande som alldeles för länge. Jag tror fortfarande att något går att göra åt den delen. Dock är ju detta inte det största problemet om jag förstår dig rätt att du inte behöver DB access för att skicka mailen.
Lägg in den info som krävs för att skapa ett mail (dvs innehåll/mall, mottagare, ev. parametrar för DB access för att customisera mailet) i en tabell i din databas.
Skriv ett nytt program som:
1) Sätter sin egen process prioritet till låg.
2) Hämtar rad för rad i "kötabellen" i databasen och skickar mailet.
Detta program kan antingen gå som en service/demon (dvs hela tiden i bakgrunden) eller så låter du ditt skicka script starta programmet när någon gör ett utskick. Alt. använder du windows scheduleraren (för du kör väl på windows om jag förstått rätt) som startar programmet var 5:e minut för att kolla kön. I de två senare fallen är det väl bra att programmet kollar så det inte redan körs när det startas också.

Enkelt uttryckt:
Vi kör en process som tar urvalet (namn, epost, kategorier, whatever you have) och tar en kompilerad mall av mailet, och mergar dessa data och lägger det i en utkö som "färdigt mail". Denna utkö är i vårt fall en katalog som vår smtpserver tar ifrån och skickar iväg.

Så själva köandet av mailen är bara ett skrivande av en fil.

Vi använder en javaapplikation för detta.

Men du kan lika gärna som någon tidigare föreslog, skriva ett php-skript som körs varje minut, och betar av en bit av urvalet.

Om du inte har möjlighet att som vi skriva direkt till utkön på smtp-servern, så kan du skicka mailen som du gör nu.

Hmm, jag funderar lite..
Eftersom mailen redan är klara här, ska det verkligen vara så mycket effektivare att lägga det i en kö, än att skicka ett mail?
Jag tycker det verkar konstigt.

Fast det är klart, när jag bara kommenterar bort raden objMail.send() på den sida som loopar igenom alla adresser och mail, och skickar dom, så går den också fort.

Jag ska göra lite tester..

Det komemr inte gå fortare att skicka, men din web-app kommer vara "klar" fortare. mailen skickas ju sedan efter hand (då helst med låg prio på processen som gör detta för att inte sänka servern i övrigt).
Så total tid att skicka mailen blir dn samma, men användaren slipper uppleva det.

Jag provade just att skriva textfiler, med information om vem som skulle ha mailet, och hur det skulle utformas. Detta tog lite över 2 minuter för 8000 mottagare...

Det är ju en klar förbättring, men fortfarande inte bra...

För oss handlar det om att göra "rätt saker på rätt ställe".

Urvalet görs i webbapplikationen.

Vår javaapp och template-motor skapar mailen bra och snabbt.

Vår smtp server levererar mailen.

Att allt skulle göras i webbapplikationen skulle, för oss, inte vara optimalt.

Lånar denna tråden lite, känns dumt att skapa en ny när rätt folk redan är samlade här.

När man skriver ett eget script till en e-postlista, är det bara att köra med en vanlig accesdatabas och sedan loopa ett vanligt mailscript? Det kan inte uppstå några problem då?

Det var den löjligaste ursäkt jag sett på länge. Skapa en egen tråd och jag hoppas en moderator raderar perejes och mitt inlägg (detta) som refererar till detta snarast.

Hallå igen... Nu har jag gjort så att jag skapar en XML-fil med nödvändig information om samtliga mottagare. Är det någon som har ett lämpligt förslag på hur jag går vidare? Ska jag göra ett program i visual basic, som ligger och kollar efter filer, eller ska jag göra en asp-sida som kollar efter filer?
Tänkte sen också att jag skulle generera eml-filer och lägga dom direkt i kön på smtp-servern, eller är det bättre att jag använder CDONTS för att skicka?

heyday har ju en point i att göra rätt sak på rätt ställe. Om nu urvalet är så tungt att göra skall detta kanske göras någon annan stans. dvs, du behöver kanske ett flöde typ:
- webapp skapar ett mailutskick med parametrar
- ett annat program kollar efter mailutskick och skapar en kö med mail
- ännu ett program skickar mail från kön.

Som den trasiga skiva jag är tycker jag fortfarande att det låter mycket med 2minutyer för att öppna och skriva lite text i några filer.
har du lokaliserat att det verkligen bara är filskrivningen som ger fördröjningen (tidigare inlägg indikerar detta) då t.ex. ASP har stora problem med sträng concat prestandamässigt så kan en sådan sak sänka ett script utan att varken DB eller något annat tar tid.

Ärligt talat så är det lite svårt att säga exakt vad som skall göras utan att se koden i alla delar. Antingen så får du hyra in någon extern som kollar det du gjort (är ju lätt att bli hemmablind) och då skall du ha någon som är van vid att optimera webapplikationer. I andra hand måste du noga mäta exakt vilka operationer som tar lång tid och vilka som inte gör det så vi vet att vi kan utesluta saker som DB, ASP string concat etc.

Hoppsan, du han visst in emellan...
jag tror det är bättre att använa en komponent istf att skapa egna eml filer. Då minskar risken för att du skapar ett mail med fel format av misstag.
Och ja, skapa ett VB program. Som jag skrev tidigare tror jag det är enklast att du startar programmet med jämna mellanrum (säg var 5:e minut) och att programmet då kollar efter en fil och sedan behandlar den om den finns och sedan dör.
När programmet hittar filen kan den ju läsa in det den behöver och sedan ta bort filen så om den inte är klar efter 5 minuter så spelar det ingen roll, nästa instans kommer inte hitta filen.
naivt, men enkelt. Skapar du flera utskick samtidigt kommer således flera VB-program kunna köras samtidigt (startade med 5 minuters intervall) för att ta hand om ett utskick vardera.

Får du prestanda problem får du ställa ner prioriteten på skicka-processerna när de startas också, men det behövs nog inte.

Inte några textfiler, 8000 textfiler. När jag istället skrev all info i samma textfil blev tidsåtgången istället ca 5 sekunder.

Det är därför jag nu har skapat en XML-fil av det hela. Första tanken var att göra eml-filer direkt, men eftersom detta tog lite tid, gör jag alltså En fil först. Utifrån denna täkner jag nu skicka mailet. Urvalet är nog bland det klumpigaste, men information ska hämtas om VAD kunderna har handlat, när, för hur mycket, hur ofta, och vart varorna levererats, och tiderna jag anger här är från tester på en separat testserver, som kör både webb och sql på samma. Dessutom är den rätt gammal.

SQL-uttrycket som tar så lång tid ser ut så här:

Coolt. Var inte helt säker på att det verkligen skulle ta så lånmg tid att öppna&stänga 8000 filer, men det är ju trots allt drygt 60st/s så ja så är det väl.

Ang. ditt SQL uttryck (som enl. tidigare inlägg) tar 10s att exekvera. Jag har svårt att motstå en utmaning...
Du har många subselects och en hel del OR. ja sånt kan ta lite tid... Dessutom en massa onödiga strängjämförelser (varför envisas webfolk med att ha saker som "ordertype" som strängar och inte integers...)

men, men... Roten till det onda ligger nog i filskrivandet för även mailkomponenten lär ju skriva mail till fil för att köa upp dem i servern så ett progranm som i bakgrunden skickar mailen efter hand är nog vägen att gå.