Bekijk Volledige Versie : Wat voor hardware voor deze aantallen
Beste,
Zoals wellicht enkele andere bedrijven hier hebben wij een aanvraag gekregen voor een mailserver voor het enkel intern versturen van mail.
Enkel kunnen wij in tegenstelling tot het aantal webrequests moeilijk inschatten wat voor hardware je hiervoor nodig hebt.
- 240 000 mails per dag (enkel intern en max 5k per bericht).
- 1.500 000 pop3 checks per dag (1000 accounts * 1 request per minuut).
- Alle berichten worden direct bij ophalen dus ook weer verwijderd.
Nu zijn 1.5m normale http requests per dag niet zo bijzonder. Enkel heb je het hier over authenticatie en het daadwerkelijk uitdelen van niet statische data.
Ook is 1.5M requests per dag gemiddeld 17 per seconde (ongeveer). Nu zie ik echter het risico omdat ze 1 keer per minuut checken dat je dus in 50 seconde per minuut weinig gebeurd en opeens in de overige 10 seconden opeens ~1000 requests binnenkomen.
Dus al met al wat zal qua hardware voldoende moeten zijn.
Ramon Fincken
29/03/13, 11:43
Backups? Hotspare ? Failover? bSMTP?
Backups? Hotspare ? Failover? bSMTP?
Backup en alles ben ik op dit moment niet geinteresseert in. Gaat me fysiek enkel om het idee van mail.
- Mailserver met pop3 & smtp.
- SMTP wordt enkel gebruikt voor sturen mail naar adressen op dezelfde fysieke server
Bovenstaand is allemaal niet zo heel bijzonder. Enkel vraag ik me af of een fysieke server met 1.5M pop3 connecties per dag heel blij wordt en of je dus aan 1 fysieke server wel voldoende hebt, zeker het feit dat het waarschijnlijk allemaal op hele minuut gebeurt.
Ramon Fincken
29/03/13, 12:03
Ok, al zou ik wel proberen het in je offerte op te nemen, want dit is wel een behoorlijk SPOF, en bij deze aantallen lijkt me dat niet leuk mocht hij ineens onbereikbaar zijn/platgaan etc..
Ok, al zou ik wel proberen het in je offerte op te nemen, want dit is wel een behoorlijk SPOF, en bij deze aantallen lijkt me dat niet leuk mocht hij ineens onbereikbaar zijn/platgaan etc..
Dat zeker. Al weet ik niet of wij een offerte gaan uitbrengen. We hebben wel ervaring met enorm druk bezochte websites maar niet met zulke aantallen emails per dag. Wat volgens mij toch weer een "vak appart" is.
Maar neemt natuurlijk niet weg dat ik nieuwsgierig ben :).
bedankt voor je reactie iig!
offtopic, maar zijn deze klanten niet eigenlijk gewoon op zoek naar een degelijk queue systeem? en 'misbruiken' ze daar nu email voor?
Beste,
Zoals wellicht enkele andere bedrijven hier hebben wij een aanvraag gekregen voor een mailserver voor het enkel intern versturen van mail.
Enkel kunnen wij in tegenstelling tot het aantal webrequests moeilijk inschatten wat voor hardware je hiervoor nodig hebt.
- 240 000 mails per dag (enkel intern en max 5k per bericht).
- 1.500 000 pop3 checks per dag (1000 accounts * 1 request per minuut).
- Alle berichten worden direct bij ophalen dus ook weer verwijderd.
Nu zijn 1.5m normale http requests per dag niet zo bijzonder. Enkel heb je het hier over authenticatie en het daadwerkelijk uitdelen van niet statische data.
Ook is 1.5M requests per dag gemiddeld 17 per seconde (ongeveer). Nu zie ik echter het risico omdat ze 1 keer per minuut checken dat je dus in 50 seconde per minuut weinig gebeurd en opeens in de overige 10 seconden opeens ~1000 requests binnenkomen.
Dus al met al wat zal qua hardware voldoende moeten zijn.
Dat hangt m.i. veel meer af van de geplande software , dan van de hardware.
Ik heb zo m'n twijfels hoe goed die requirements zijn. Het gaat blijkbaar om ca 1000 clients , die dan allemaal 240 mails per dag binnenkrijgen van elkaar.
Als gemiddelde over *iedereen* is dat echt wel hoog.
En daarnaast dan POP, dat is wel weer behoorlijk beperkt in een toch vrij grote organisatie. Dan verwacht je toch eerder IMAP of "Exchange" .
En de aanname (cq 'belofte') dat er geen 'leave mail on server' gebruikt wordt lijkt me ook iets wat best snel de deur uit zou kunnen gaan.
Als die polling dan telkens met een SSL (POP3S) sessie setup zou gaan wordt die sessie setup wel een zwaar deel.
Bij elkaar in elk geval een risico van "veranderende requirements gedurende het project".
Technisch moet je het gezochte resultaat (snelle notificatie van nieuwe mail , dat zal de 1 minuut poll zijn) beter en lichter kunnen bereiken met lang openstaande imap(s) sessies.
Voor server specs zou ik vooral zoeken naar schaling/specs van de geplande software.
Een naieve implementatie die een mailbox scanned om te kijken of er wat nieuws bijgekomen is, is amper tegenop te schalen met hardware.
Maar een slimmere setup die de toestand van de mailboxen snel kan opleveren moet m.i. met vrij beperkte hardware specs toe kunnen.
Ik heb een beetje gegoogled , maar zie niet meteen een combinatie hw specs/software/ #mail boxen*polling .
Wel her en der dingetjes die suggereren 'moet zeker kunnen' ; (iets op een cyrus imap mailing list uit 2002 over 50K mailboxen op blijkbaar een enkele server. Dan moet 1K op een mid range machine (8..16G, 4 core) in 2013 toch wel kunnen).
sample :
http://readlist.com/lists/lists.sourceforge.net/courier-imap/0/1207.html
(100..150K accounts op een enkele imap machine, 2007. geen cijfers over #concurrent active, maar 1% zal toch wel ? )
Dat hangt m.i. veel meer af van de geplande software , dan van de hardware.
Ik heb zo m'n twijfels hoe goed die requirements zijn. Het gaat blijkbaar om ca 1000 clients , die dan allemaal 240 mails per dag binnenkrijgen van elkaar.
Als gemiddelde over *iedereen* is dat echt wel hoog.
En daarnaast dan POP, dat is wel weer behoorlijk beperkt in een toch vrij grote organisatie. Dan verwacht je toch eerder IMAP of "Exchange" .
En de aanname (cq 'belofte') dat er geen 'leave mail on server' gebruikt wordt lijkt me ook iets wat best snel de deur uit zou kunnen gaan.
Als die polling dan telkens met een SSL (POP3S) sessie setup zou gaan wordt die sessie setup wel een zwaar deel.
Bij elkaar in elk geval een risico van "veranderende requirements gedurende het project".
Technisch moet je het gezochte resultaat (snelle notificatie van nieuwe mail , dat zal de 1 minuut poll zijn) beter en lichter kunnen bereiken met lang openstaande imap(s) sessies.
Voor server specs zou ik vooral zoeken naar schaling/specs van de geplande software.
Een naieve implementatie die een mailbox scanned om te kijken of er wat nieuws bijgekomen is, is amper tegenop te schalen met hardware.
Maar een slimmere setup die de toestand van de mailboxen snel kan opleveren moet m.i. met vrij beperkte hardware specs toe kunnen.
Ik heb een beetje gegoogled , maar zie niet meteen een combinatie hw specs/software/ #mail boxen*polling .
Wel her en der dingetjes die suggereren 'moet zeker kunnen' ; (iets op een cyrus imap mailing list uit 2002 over 50K mailboxen op blijkbaar een enkele server. Dan moet 1K op een mid range machine (8..16G, 4 core) in 2013 toch wel kunnen).
sample :
http://readlist.com/lists/lists.sourceforge.net/courier-imap/0/1207.html
(100..150K accounts op een enkele imap machine, 2007. geen cijfers over #concurrent active, maar 1% zal toch wel ? )
Het gaat hier om het uitwisselen van data van weerstations. Dus dat het enkel voor intern is is wel reëel. De duizend accounts zijn dus ook 1000 weerstations.
Vandaar is de hoeveelheid connecties met zekerheid te zeggen.
Het gaat hier om het uitwisselen van data van weerstations. Dus dat het enkel voor intern is is wel reëel. De duizend accounts zijn dus ook 1000 weerstations.
Vandaar is de hoeveelheid connecties met zekerheid te zeggen.
Noem anders een prijs waarvan je zegt voor deze prijs zorgen wij voor een oplossing (met het risico dat meer hardware nodig is). Je bent niet de enige met die aanvraag ;)
systemdeveloper
30/03/13, 00:36
Met 1 machine moet je dat met gemak aankunnen als je een lekker snelle raid array hebt.
Vraag is alleen wie de lul is als de boel kapot gaat of er onderhoud nodig is. Ben jij dat, dan ontkom je eigenlijk niet aan een replicerende oplossing.
Exchange, open-exchange e.d. lijkt me overkill aangezien er (?) geen sprake is van samenwerkings mogelijkheden. Als het semi geautomatiseerde processen zijn dan is imap ook overbodig.
Waar je wellicht wel aan kunt denken is virusscanning. Het is welliswaar een intern systeem maar je wilt niet dat er via 1 getrojanned systeem opeens 1000 mailboxen en clientsystemen besmet raken.
Dit kan je wel iets extra power kosten, maar met iets zoals een shared storage en 2 (of meer) mailservers kun je dat goed opvangen.
Het gaat hier om het uitwisselen van data van weerstations. Dus dat het enkel voor intern is is wel reëel. De duizend accounts zijn dus ook 1000 weerstations.
Vandaar is de hoeveelheid connecties met zekerheid te zeggen.
Ah, dan zijn specs inderdaad beter voorspelbaar, en kun je ook meer vertrouwen hebben dat de requirements stabiel blijven dan wanneer het KA gebruik betreft terwijl (voor KA) ongebruikelijke specs/gedrag gegegeven worden.