Всем привет.Сразу уточняю, что речь не идёт о спам-сервере.
Возникла задача отправки 5 миллионов в месяц, при этом на сервере будут крутиться:
1) mysql с базой контактов;
2) postfix;
3) dovecot или courier для приёма ответных писем;Никаких антивирусов и антиспамов, никаких сканеров.
Проблема в том, что я с такими объёмами никогда не сталкивался и сейчас мучаюсь вопросом выбора железяки под это дело.
Планируется 4х процессорный аппарат с 4 гигами памяти.
Я где-то нутром чую, что для отправки писем такое железо сгодится, но есть и иная проблема - приём ответных, в том числе и bounce-сообщений, то есть их будет много.Кто-нибудь сталкивался с такими задачами, как они решались. Целесообразно ли использование haproxy для smtp, чтоб распараллелить потоки отправки между несколькими серверами?
Заранее спасибо.
Хмм...
$ bc
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
scale=3
5000000/30/86400
1.929т.е. 2 письма в секунду...
да с этим что угодно справится (вплоть до pIII + 512Mb RAM)
>[оверквотинг удален]
>Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
>This is free software with ABSOLUTELY NO WARRANTY.
>For details type `warranty'.
>scale=3
>5000000/30/86400
>1.929
>
>т.е. 2 письма в секунду...
>да с этим что угодно справится (вплоть до pIII + 512Mb RAM)
>сферический конь.
Привет :)Я не совсем верно выразился, отправки будут не равномерными, скажем, сегодня надо отправить 700 тысяч писем. желательно за 2-4 часа. Скажем, примерно по 3000 в минуту.
Я сейчас попробовал через свой сервер прогнать такой поток, судя по статистике, 1400 в минуту прокачивает потом, судя по всему, очень просела принимающая сторона.
У меня просто нет опыта, примерные расчеты говорят, что железяки такой хватит, но хотелось бы узнать опыт других, может что-то ещё учесть надо.
>[оверквотинг удален]
>Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
>This is free software with ABSOLUTELY NO WARRANTY.
>For details type `warranty'.
>scale=3
>5000000/30/86400
>1.929
>
>т.е. 2 письма в секунду...
>да с этим что угодно справится (вплоть до pIII + 512Mb RAM)
>
желательно за 2-4 часакак это можно контролировать?
>[оверквотинг удален]
>>Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
>>This is free software with ABSOLUTELY NO WARRANTY.
>>For details type `warranty'.
>>scale=3
>>5000000/30/86400
>>1.929
>>
>>т.е. 2 письма в секунду...
>>да с этим что угодно справится (вплоть до pIII + 512Mb RAM)
>>Ну тогда другой разговор...4-х ядерник может и излишне, а может и нет...Но действительно
придется городить что-то типа HAProxy...
Я делал так...
один сервер рассылает через два других у меня есть железячный load balancer), а
прием организован вообще двумя другими.
>[оверквотинг удален]
>
>Планируется 4х процессорный аппарат с 4 гигами памяти.
>Я где-то нутром чую, что для отправки писем такое железо сгодится, но
>есть и иная проблема - приём ответных, в том числе и
>bounce-сообщений, то есть их будет много.
>
>Кто-нибудь сталкивался с такими задачами, как они решались. Целесообразно ли использование haproxy
>для smtp, чтоб распараллелить потоки отправки между несколькими серверами?
>
>Заранее спасибо.Даже интересно стало: а что это за задачи, требующие такого напряжённого почтового трафика? Академический интерес.
Контролировать можно.
Зачем это нужно. Компания занимается предоставлением площадок для проведения маркетинговых кампаний. Я тоже ехидно улыбался и думал, что спамеры, но нет.
На деле же используется такая штука http://www.interspire.com/emailmarketer/
По сути вебморда для планирования и реализации рассылок. Эта же система ведёт учет количества отправленных писем, осуществляет сбор ответов (в том числе и реджектов), помечает тех, кто отписался и так далее.Поэтому нужны временные рамки более менее чёткие.
Я только что закончил отправку 500 тысяч писем (по 10 кб) между двумя постфиксами в дефолтовой конфигурации (никакой оптимизации) на обычных рабочих станциях. Заняло это около трёх с половиной часов.
Учитывая, что там сам сервер мощнее, то за эту часть я всё меньше волнуюсь. Основная проблема скорее всего станет в сетевых задержках, таймаутах и нагрузке в виде приходящих отлупов.