Opzet meerdere mailqueues nieuwsbriefsysteem

[juggle]

Beste tweakers,

2 jaar geleden heb ik een topic geopend die een soortgelijke vraag behandelde:
http://gathering.tweakers.net/forum/list_messages/1316824

2 jaar verder en inmiddels heeft het mailsysteem meer dan 1200 actieve gebruikers en verzendt het mailsysteem gem. 25.000 mails per dag.

De verzendaantallen zijn geen breinbrekers, maar ik wil graag de verzendlimiet omhoog hebben.

Op dit moment worden per minuut 400 mails verzonden. Dit is eigenlijk de maximale capaciteit die ik over een persistant smtp verbinding kan persen. De dedicated server die de mails afhandelt staat in feite dus te lummelen. 400 mails verwerken per minuut is geen belasting.

Nu wil ik meerdere queues gaan inzetten en daarover de mails verdelen. Dus zeg maar tabel:
mail_queue_1, mail_queue_2, mail_queue_3 etc.

Vervolgens net zoveel cronjobs aanmaken die alle queues leegtrekken. Op deze wijze kan ik dus 400 * het aantal mailqueues verzenden per minuut.

Echter wordt de database hierdoor wel extra belast, aangezien er meerdere queries worden verzonden per proces. Daarnaast is dit dezelfde server die ook de applicatie serveert.

Zij er andere oplossingen mogelijk, of dien ik de verzendmethoden te optimaliseren? Zijn er ervaringen op dit gebied?

[rhodium]

Dit lijkt mij toch niet echt moeilijk om iets zelf te bedenken.

Bijvoorbeeld: 400 mailadressen met behulp van xml wegschrijven in een bestandje op de server. Cronjobje die kijkt of mapje running leeg is en bestandje uit mapje queue haalt en in mapje running plaatst. En iets wat volgens het bestandje inlaad uit queue en verwerkt.

Daarbij zou je ook kunnen onderzoeken of de mailserver zelf hiervoor geen opties heeft. Lijkt mij bijna van wel.

[creator1988]

Als je een queue oplossing pakt als ActiveMQ of MSMQ kan je gewoon meerdere workerthreads de queue laten verwerken. Kan je opschalen tot je mailserver de beperkende factor wordt.

[FragFrog]

rhodium schreef op donderdag 07 april 2011 @ 12:17:
Bijvoorbeeld: 400 mailadressen met behulp van xml wegschrijven in een bestandje op de server. Cronjobje die kijkt of mapje running leeg is en bestandje uit mapje queue haalt en in mapje running plaatst. En iets wat volgens het bestandje inlaad uit queue en verwerkt.

In plaats van een database data wegschrijven naar een flatfile in een bloated formaat zal eerder het tegenovergestelde bereiken als je performance wilt vermoed ik.

Het klinkt alsof je de mail-queue ook goed op een andere machine zou kunnen verwerken, ik zou zeggen ga er eens mee testen en kijk of je tegen capaciteitsproblemen aanloopt. Zoja kun je altijd nog een extra machine erin zetten of bijvoorbeeld een direct-to-memory oplossing gebruiken voor je queue's zelf (iets als memcache bijvoorbeeld).

[Verwijderd]

Ik heb eenzelfde soort systeem ooit gebouwd waarbij er 1 hoofdserver is die de que bijhoudt en een lijst met servers die wel/niet actief is.

Op de hoofdserver draait een daemon die in Perl geschreven is die kijkt of er een batch is (x aantal nog niet verstuurde emails) en of er een server beschikbaar is om tegenaan te praten, indien dat het geval is wordt die batch job naar een server gepushed , via soap of json. De server gaat de batch versturen aan de hoofdserver of de batch gelukt is.

Dit is wel een redelijk 'bloated' oplossing maar wel heel schaalbaar , het bijhouden van meerdere queue's is niet nodig en alle data wordt toch centraal opgeslagen.