Nieuwsbrievensysteem opzetten op meerdere servers

[juggle]

Beste Tweakers,

Ik zit wat te tubben over de juiste opstelling om voor verschillende klanten van ons nieuwsbrieven te gaan versturen. Allereerst, voordat ik het probleem uitleg, zal ik een situatie schets geven:

Op moment van schrijven heb ik 2 servers in gebruik die ondergebracht zijn bij onze hostingprovider:

1. Een dedicated mail server (VPS)
2. Een server waar de applicatie draait om nieuwsbrieven te versturen

De nieuwsbrieven applicatie (geschreven in PHP) maakt op moment van verzending een mysql verbinding met de VPS en pompt de bulk mail daar in een queue. Vervolgens draait op de VPS een Cronjob die er om de minuut een 100tal mailtjes uitgooit. Op zich werkt dit verder prima. De klant hoeft niet te wachten totdat de mailtjes zijn verzonden en de mail server wordt niet overbelast.

Nu mijn probleem:

Hypothetisch is het mogelijk dat 10 klanten 10.000 mailtjes versturen op exact hetzelfde moment. Het probleem is dat daardoor de queue aardig vol zit en diegene die het laaste op verzenden heeft gedrukt lang moet wachten voordat de mailing verstuurd is. Iemand met bijvoorbeeld "maar" 100 adressen zal lang moeten wachten als er eerst nog 90.000 andere mailtjes moeten worden verstuurd.

Mijn oplossingen:

1. Ik maak 2 queues of meer aan voor verschillende mailingen. Ik verdeel dus de mails over de verschillende queues
2. ik laat de cronjob zowel van bovenaf als onderaf records ophalen om te verzenden.

Toch voelt dit als "gekunstel" en heb ik niet het gevoel hier heel handig mee om te springen. Mijn vraag is dus:

Zijn er Tweakers die hier ervaringen mee hebben en mij misschien andere methoden kunnen aanbevelen of misschien zelfs een van de bovengenoemde oplossingen gebruiken?

[Deviruchi]

juggle schreef op vrijdag 10 oktober 2008 @ 17:18:
Beste Tweakers,

Ik zit wat te tubben over de juiste opstelling om voor verschillende klanten van ons nieuwsbrieven te gaan versturen. Allereerst, voordat ik het probleem uitleg, zal ik een situatie schets geven:

Op moment van schrijven heb ik 2 servers in gebruik die ondergebracht zijn bij onze hostingprovider:

1. Een dedicated mail server (VPS)
2. Een server waar de applicatie draait om nieuwsbrieven te versturen

De nieuwsbrieven applicatie (geschreven in PHP) maakt op moment van verzending een mysql verbinding met de VPS en pompt de bulk mail daar in een queue. Vervolgens draait op de VPS een Cronjob die er om de minuut een 100tal mailtjes uitgooit. Op zich werkt dit verder prima. De klant hoeft niet te wachten totdat de mailtjes zijn verzonden en de mail server wordt niet overbelast.

Nu mijn probleem:

Hypothetisch is het mogelijk dat 10 klanten 10.000 mailtjes versturen op exact hetzelfde moment. Het probleem is dat daardoor de queue aardig vol zit en diegene die het laaste op verzenden heeft gedrukt lang moet wachten voordat de mailing verstuurd is. Iemand met bijvoorbeeld "maar" 100 adressen zal lang moeten wachten als er eerst nog 90.000 andere mailtjes moeten worden verstuurd.

Mijn oplossingen:

1. Ik maak 2 queues of meer aan voor verschillende mailingen. Ik verdeel dus de mails over de verschillende queues
2. ik laat de cronjob zowel van bovenaf als onderaf records ophalen om te verzenden.

Toch voelt dit als "gekunstel" en heb ik niet het gevoel hier heel handig mee om te springen. Mijn vraag is dus:

Zijn er Tweakers die hier ervaringen mee hebben en mij misschien andere methoden kunnen aanbevelen of misschien zelfs een van de bovengenoemde oplossingen gebruiken?

Je zult voor jezelf goed na moeten gaan wat je precies wilt. Omdat het optimaliseren van dit systeem enorm veel tijd in beslag gaat nemen. Hoe groot is de kans dat dit gebeurt? Vind de klant het ook erg om te wachten als de prijzen minder hoog zijn? Je kunt bijvoorbeeld ook aangeven dat de kans bestaat dat het soms langer duurt.

Afijn, dat zijn een aantal excuses om het niet te doen; als programmeur wil je natuurlijk altijd je software verbeteren.
Je geeft zelf aan dat je records van de boven- en onderkant wil pakken. Stel je eens voor dat er 2 mailing van 90.000 mails zijn. Jij zit hier met je 200 mails tussen in. Niet bepaald eerlijk lijkt me.

Je kunt ervoor kiezen om te gaan sorteren op hoeveelheden. Een mailing van 100 krijgt voorrang op een mailing van 100.000. Simpelweg omdat de langere mailing toch al veel tijd in beslag neemt zal het niet uitmaken om even te wachten op die 100 mails. Je moet hierbij wel de tijd in de gaten houden wanneer de mailing van die 100.000 had moeten beginnen.

Het lijkt me dus het handigste hier 2 queues voor te maken, 1 voor grote mailings en 1 voor kleinere. In plaats van dat je er nu 100 verstuurd voor 1 queue verstuur je er dan 50 per queue. Als er dan 1 leeg is stap je bij de andere over op 100 mails.

Dit is echter vast niet het enige wat je wil optimaliseren. Wat nou als een klant 1.000.000 mails wil versturen. Dan moet hij echt heel lang wachten. Dan kun je misschien beter je mail server iets zwaarder belasten gedurende korte tijd.

Ik zou er zelf voor kiezen om bij de realiteit te blijven, en dit probleem op te pakken wanneer het zich voor gaat doen. Het lijkt me de investering op de korte termijn gewoon niet waard.

[juggle]

@Deviruchi
Bedankt voor je uitgebreide antwoord. Op zich heb je wel gelijk. De situatie doet zich inderdaad nog niet voor. Het gaat er mij meer om dat je vanaf het begin eigenlijk een solide basis wilt hebben. Achteraf uitbreiden op een systeem wat vanaf de basis goed in elkaar zit is veel gemakkelijk dan een systeem waarop je qua architectuur vanaf het begin al fout zit. 1.000.000 mails zou mooi zijn maar dan stap ik over op een echte dedicated server.

Ontopic:

Ik denk dat ik de aanpak van verschillende queues ga implementeren. Zeker op langere termijn is het dan mogelijk bij veel regelmatig mailverkeer er extra queues bij te plaatsen. Schaalbaar en beheersbaar.

Toch blijf ik wel heel erg nieuwsgierig naar mensen die soortgelijke situaties mee hebben gemaakt en voor verschillende klanten grote mailingen versturen. Ik weet dat er hier een aantal topics over zijn geweest maar daarin ging het meer over het eenmalig verzenden van een grote mailing.

Dus replies zijn nog van harte welkom.

[Soultaker]

Vrijwel alle zinnige mailservers (daarmee bedoel ik dus de software, niet de server zelf) kunnen een grote hoeveelheid mail in de queue hebben staan. Het in de queue plaatsen kost vrijwel geen tijd. Vervolgens probeert de mailserver op de achtergrond alle berichten zo snel mogelijk de deur uit te krijgen. De snelheid waarmee dit gebeurt is vooral afhankelijk van de snelheid van het netwerk, maar ook van de belasting van de server. Verder is er vrij weinig wat je kunt doen om het proces te versnellen.

Vandaar dat ik me afvraag, wat je precies wil bereiken met handmatige cron jobs en scheduling van e-mail. Dat maakt het alleen maar ingewikkelder, terwijl de efficientie waarschijn ook achteruit gaat door het heen en weer kopiëren van berichten en de handmatige beperking op het aantal mailtjes dat per minuut verstuurd kan worden. Is het niet een beter idee om ervoor te zorgen dat je voldoende capaciteit hebt om 10.000 mailtjes een beetje snel weg te werken, zodat je ook niet moeilijk hoeft te doen met prioriteren van individuele berichten op basis van de afzender.

Een andere optie waar je naar zou kunnen kijken, is het virtualiseren van de mailserver, zo dat elke gebruiker zijn eigen mailserver met bijbehorende queue krijgt, of misschien een paar vaste virtuele servers voor verschillende soorten gebruikers.

[RobIII]

^^ Met hem.

En als je dan toch meerdere mailings netjes 'tegelijk' wil afhandelen: Als er (in volgorde) 3 jobs geplanned worden (100.000, 200, 99.900) dan maak je gewoon 3 queues en ga je gewoon mail dequeuen op queue basis: 1, 2, 3, 1, 2, 3, 1, 2, 3, 1, 2, 3 etc. Dan hebben ze alle 3 evenveel prio. Heeft klant C een 'PRO' account (ik noem maar wat) dan kun je ook nog eens 1, 2, 3, 3, 3, 1, 2, 3, 3, 3, 1, 2, 3, 3, 3 doen bijvoorbeeld omdat deze klant meer betaalt. Etc. Supersimpel te bouwen en een eerlijk systeem. Dit werkt net zo goed voor 50 queues (= klanten/mailings) als voor 2 en blijft even 'eerlijk' bij 1 of bij 1miljoen mails.

[juggle]

@Soultaker
Op zich kan de server aardig wat hebben. Maar aangezien het om een VPS gaat begint deze toch wat te stijgeren als er via qmail 100.000 mails in een keer heen gepompt worden. Vooral de diskload die dit met zich meebrengt kan voor wat performance problemen zorgen. Daarnaast zorgen de queues ervoor dat mailingen gescheduled kunnen worden op gezette tijden. Op deze wijze kan ik dus mailings klaarzetten die op een veel later tijdstip worden verstuurd.

Misschien dat je de constructie wat vreemd vind maar het heeft er mee te maken dat de mailing applicatie zowel standalone als in een CMS oplossing van ons kan worden gebruikt. Door alle queues en verzend logica centraal op de VPS te zetten hoef ik mij dus nooit zorgen te maken of andere hosters wel ondersteuning bieden voor CronJobs en andere instellingen.

Het virtualiseren van de mailserver kan interessant zijn en sluit ook aan bij de eerder genoemde oplossing, hoe zie je een dergelijke constructie dan precies voor je?

[FragFrog]

Je zou ervoor kunnen kiezen elke 'batch' een gedeelte van elke que te doen; hierbij er vanuitgaand dat in je DB staat bij welke groep elk mailtje hoort. Eventueel kun je dat weer koppelen aan een percentage, ie, als er drie mailings zijn, een van 100.000 mailtjes en twee van 50.000 mailtjes kun je per batch 50 van de grootste groep doen en 25 van de kleintjes, zijn ze allemaal op hetzelfde moment klaar en beginnen ze toch allemaal zodra ze enqueed worden.

Andere optie is het aantal mailtjes per que gelijk te zetten, in dat geval zou bij bovenstaande voorbeeld 33 mailtjes van elke groep verstuurd worden. Op deze manier zijn kleinere mailings ook sneller klaar wat wellicht op je klanten natuurlijker overkomt.

Eventueel kun je dan zelfs ervoor kiezen om de hoeveelheid per batch aan te passen naar aanleiding van het totale aantal mailtjes in de que, zodat als het echt heel druk is hij er bijvoorbeeld 200 per tien minuten probeert uit te jassen - eventueel met een status opslaan in de DB zodat de volgende batch alleen start als de vorige klaar is. Schaalt prima zolang je hardware 't aankan, als je statusmeldingen in de DB zet kun je zelfs makkelijk meerdere mailservers eraan hangen (die elk alleen mailtjes gaan versturen die nog niet in een actieve batch zitten) zodat je in principe bijna oneindig veel kan versturen, en het bespaart je de overhead en moeite van aparte VPS'en opzetten voor elke klant.

All that being said, voor het laatste project waar er massief veel gemailed moest worden hebben mijn collega's simpelweg een externe partij benadert die erin gespecialiseerd is, graphicmail, die lachen om 10k mailtjes en als er iets stuque is verwijzen we de klant fijn naar hun door


_{//edit
Zucht, neem je ook eens tijd wat te tikken, zijn ze je weer te snel af}

[PeterEs]

Ik heb de zelfde situatie gehad. Mijn mailing betrof een 70-80 duizend adressen. Weet niet hoe groot de jouwe precies is?

In mijn geval betrof het maar 1 bedrijf, dus heb het ook gewoon bij een queue gelaten. Eerst worden alle adressen toegevoegd aan een table, daarna per X aantal adressen, geschijden door ; met body, subject etc. in een andere table geplaatst. Deze table word dan weer door een cronjob elke X aantal minuten aangeroepen en de mails verzonden.

Draait op een shared hosting account, uiteraard wel met eigen IP adres.

[juggle]

@RobIII
Kijk eens aan dat is lekkere info, ik zat zelf ook al aan zoiets te denken. Op deze wijze heb je inderdaad een super simpel systeem en hardstikke schaalbaar. Het ging mij er ook met name om dat ik bij dat ene mailtje (bij wijze van een demo account bijvoorbeeld) niet hoef te wachten todat die dikke mailing van 10.000 de deur uit is.

@FragFrog
Zoals ook al door Robll en Soultaker aangegeven kun je alle kanten op. Statussen worden op dit moment al toegekend en er zit een max op van het aantal pogingen dat wordt ondernomen om te verzenden. Kijk, ik wil ook helemaal niet een oplossing bouwen waarmee ik miljoenen e-mail kan versturen. Daarvoor zijn inderdaad veel betere partijen beschikbaar met veel meer capaciteit. Bij mij gaat het gemiddeld genomen om mailings tussen de 500 en 15.000 mailtjes. Wat ik belangrijk vind is dat ik een schaalbaar systeem heb waarmee ik in ieder geval ruimte heb om mijn klanten te kunnen bedienen. Met de in dit topic genoemde oplossingen kom ik daar al heel dicht bij in de buurt.

hehehe desalniettemin wordt je input zeker gewaardeerd door de TS

[ Voor 3% gewijzigd door juggle op 10-10-2008 22:12 ]