Я не совсем в PHP теме, поэтому не знаю чего вдруг ваш sendmail грузит сервер. Но поскольку сталкивался с задачей - напишу свои 5 копеек, может что пригодится.
Вообще все вопросы связанные с нагрузкой нужно начинать решать от понимания того как все работает. Что происходит когда вы отсылаете письмо с CC (или BCC) со своей машины наружу? Вы формируете письмо в 1 экземпляре (1 body) с длинной предлинной строкой адреса, где у вас просто перечислены все адреса получателей. Затем Вы его передаете в механизм отсылки. Понятно, что чем меньше писем, тем меньше объем передаваемых данных, а следовательно немного экономичнее будет расход памяти и приложение будет работать побыстрее. То есть 10 писем по 5000 реципиентов теоретически лучше, чем 100 по 500.
Далее начинается самое интересное. Если ваш механизм отсылки отсылает почту НАПРЯМУЮ по 25 порту к получателю, то он:
- рубит длинную строку BCC на отдельные адреса
- вычленяет из каждого адреса получателя имя домена
- резолвит имя домена в IP адрес (? может и не делать этого)
- лезет в ДНС для получения MX записи - адреса почтовика, который отвечает за обработку почты на данном доменном имени
- открывает соединение по 25 порту к полученному IP сервера
- шлет данные
- закрывает соединение
- повторяет это все в цикле покуда BCC не кончится
Если с соединением некузяво, то еще при каждом соединении что-то происходит. В зависимости от настроек это может быть посылка системных сообщений, постановка сообщения в очередь или просто программный отлуп с возвратом кода ошибки.
Понятно, что в данном случае механизм, который отсылает почту (sendmail к примеру), берет ваш текст одного письма с 5000 BCC, разбирает его и ДУПЛИЦИРУЕТ в 5000 писем, чтобы затем соединиться С КАЖДЫМ сервером и отослать КАЖДОЕ письмо.
Собственно, я к чему привел такой перечень подробный - учтите, что у Вас на отправку одного письма будет уходить от долей секунды до десятков секунд время. Это к вопросу об отправке 50 писем в минуту. Одно письмо на несуществующий адрес - и все, пока отрезолвится, пока коннект поймет что IP нерабочий, пока то да се... Это все нужно учитывать.
Второй вариант - если вы отправляете почту через relay, то есть некий промежуточный сервер. Например, стоящий локально или на другой машине MDaemon или вообще через внешний сервер вашего провайдера. В таком случае вы формируете свои 10 писем по 5000 получателей, и передаете их серверу на обработку. Далее весь описанный процесс будет проблемой почтового сервера, который обычно немного умнее sendmail и может
а) сэкономить на дубликатах если домены для нескольких получателей находятся на одном физически IP (данная возможность должна быть реализована в почтовике (!)
б) распределять нагрузку на канал и процессов при отправке большого числа писем в соответствии со своими настройками, вести очередь и вообще очень корректно обрабатывать непростые ситуации
К вопросу о максимальной длине BCC - надо бы посмотреть RFC на эту тему, но мне кажется принципиального ограничения быть не должно, т.к. при первом способе все равно все письма сплитятся в одиночные на уровне отправителя, а при втором - все зависит от того как реализован почтовик. Теоретически ему все равно должно быть какой длины строки разбор делать.
Поэтому вообще самое оптимальное на мой взгляд решение, которое просто и примитивно реализуется - это поставить почтовый сервер типа MDaemon, а приложение будет просто писать письма в файлы в определенную папку типа Outbox, а MDaemon дальше уже сам разберется по сколько штук и с какой периодичностью что отправлять.
В противном случае ваш рассыльщик будет недостаточно жизнеспособен по ряду причин: обработка кривых ответов почтовиков, лишняя нагрузка, сложности в разработке параллельного обработчика. Плюс практически нулевая устойчивость к спам-фильтрам, которые порежут все ваши сообщения на раз, даже если они не спам а нормальная информационная рассылка с тучей подписчиков.
Зачем двойной трафик нужен? Это неправильно.
Эм.. Обрыв коннекта для одного только яндекса - так не бывает, это похоже какая-то проблема у самого яндекс-бота. Хедеры корректные, все давно проверено-перепроверено, опять же поддержка это подтверждала. WGet'ом все пересмотрел и побайтно все смотрел... Если только они у самого робота как-то хедеры интерпретируются некорректно... Знаю пару ситуаций когда бот точно перестает сайт есть, но сейчас это вроде бы не оно. Да и другие то сайты на том же самом движке на той же самой площадке нормально индексируются!
Хотя по идее даже если кривые хедера парсить то, наверное, можно... В том плане что content-length в HTTP заголовке вроде как хедер необязательный и все такое.
Или речь о длине пакетов на уровнях ниже HTTP? Тогда сайт бы вообще не работал...
В общем странно все это, пойду на всякий случай в 150ый раз проверю, но по всем признакам засада вовне нашего сайта.
Мне пришел вот ответ: от "Платона" (мою ситуацию см. в треде выше).
"Последний раз сайт отвечал роботу кодом 1001 и 1015 вместо 200. Ошибки нет, я еще раз все проверил. Вам нужно проверить настройки сервера и ждать переиндексации."
Может я чего то не знаю, но в RFC вроде явно написано - код HTTP ответа трехзначный! Что это за коды такие могут быть у индексирующего робота, может кто из Юниксовых специалистов в курсе? Расширенных подкодов у кодов 100 и 101 вроде бы быть не должно?
Количеством - это да, но че то мой гастрит последнее время не очень этот метод одобряет.
Боярскую пробовал, не вставила. Но тут как известно на вкус и цвет... МЖК собственно мне кажется имеет по крайней мере натурально горчичный вкус, а то как то несколько раз брал немецкие какие-то баночки - это была виселица. Непонятно что и со вкусом чего.
Баночную горчицу тоже брал. Чего то не понравилось по вкусу, не помню чего. Ну и не люблю я фасовку такую, надо или быстро всю банку уминать, или приходится выбрасывать продукт (жалко!) - окисляется, сволочь, моментально.
Как коренной дальневосточник поддерживаю миграцию на хрен! Хрен сделанный своими руками - это вещь.
+1, лучше пока не находил
Точно такой ответ был на мои запросы - у меня на одной из площадок два новых сайта не появляются в индексе более 1.5 месяцев. Проверил логи - в логах написано что на каждый запрос был ответ 200 ОК. Отправил логи обратно (коротенькую выдержку), но думаю разбираться они не станут.
За 15 дней к каждому из сайтов было всего по 50-60 обращений роботов Яндекса (всех до кучи). Выводов много это или мало сделать не могу, мало данных.
Sun, не путайте людей.
1. Скорость разработки приложения от языка практически не зависит, приведенный в посте выше пример неверен в корне.
2. Если Вы посмотрели на сайт топикстертера и предполагаете что там Руби, то я делаю вывод, что Вы не видели ни исходного кода, ни структуры базы. Почему Вы утверждаете, что нужно все переписывать на PHP? Вы уверены что это не тормоза на уровне СУБД? Вы уверены, что это не тормоза сервера? Как Вы провели тестирование? Где описание Ваших действий, почему сразу идут безосновательные выводы?
Не употребляйте для объяснения причин чего-бы то ни было слова "кривизна". Оно беспомощно и бездоказательно, поскольку становится ясно только то, что Вы не уверены, что знаете причины происходящего.
Я уверен, что Ваши посты оказывают медвежью услугу топикстартеру. Уже писал выше, что переписывать приложение на другом языке без изменения подхода - второй раз наступать на те же грабли.
Топикстартер - я бы настоятельно рекомендовал потратить какую-то сумму денег на аудитора по Ruby, только дать ему доступ к проекту на уровне кода и структуры СУБД. За эти деньги ваша компания получит опыт, который не даст возможности в следующий раз совершить аналогичную ошибку. А если денег не платить - компания ничему не научится и в следующий раз вам проект напишут на Лиспе или Прологе, и вы это прощелкаете. А переписывать проект на другом языке или нет - это уже будет понятно исходя из аудита.
Вообще, Вы бы рассказали подробнее что за проект, что за функционал и что за архитектура. Глядишь, публика и подскажет узкие места. Или за деньги, или "за так". Тут много неглупых людей бывает в этом разделе, как мне кажется по постам.
Физически, кстати, это может находиться где угодно, но вообще смена хостинга в текущей ситуации на рынке - задача тривиальная (см. раздел Хостинг форума в помощь). Установить свой колокол можно за "от 45$ в месяц". Сервер стоит копейки, даже 1U сервер можно взять менее чем за 1000$. И все - вы отвязаны от хостинга "где-то там" с их определенными рисками, вы контролируете сервер и все что с ним связано. Правда нужен будет сисадмин, но там есть ряд простых решений задачи, в.т.ч. можно взять простые операции обслуживания и переложить за скромную сумму на хостера (есть и такие услуги) но это частности.
В любом случае задача поиска вменяемого системного архитектора (на худой конец сойдет и опытный разработчик) проще чем задача переписывания всего заново на новом языке. Тем более, что это принципиально не решит проблему.
Ну, вообще-то надо просто посчитать затраты.
Очень грубо если (не зная задачи):
Перенос системы, состоящей из 10-50 различных скриптов с типовыми операциями для интернет или интранет системы с одного языка на другой - от 2 до 8 недель, в зависимости от опыта разработчика. Необходимыми (!) условиями успеха являются:
а) доскональное знание обеих технологий (языков + среды разработки (если есть) + набора идеологических тонкостей и т.д.)
б) доскональное знание логики работы существующей системы. если ТЗ человек увидит впервые - по сути это написание новой системы с нуля, а это совсем другие затраты.
в) наличие грамотного тестировщика, который также досконально знает как система должна работать, который будет париться вместе с программистом все это время практически с первого дня. зачастую в качестве тестировщика выступает проджект менеджер.
Итого имеем 160-640 ч.ч. работы. При среднем рейте 5-15 баксов в час по Москве... Хотя, возьмем даже нижнюю планку - 5 баксов в час. Перемножим и получим, что переписывание с одного языка на другой приличной по функционалу веб-системы будет стоить от 800 до 3200 долларов.
Альтернатива: установить mod_... или чего там "криво встало" путем
а) нажима на админа с помощью пива, биты, бабы, жалобы начальству (нужное вычеркнуть)
б) приезда на хостинг и постановки всего самостоятельно или с привлечением внешнего эксперта за бабки (пиво, бабу и т.д.)
Мне кажется что за 1 рабочий день используя советы бывалых, или даже имея опыт администрирования но не имея понятия с чем столкнешься, поставить можно что угодно и куда угодно. При рэйте опытного админа в 20$ в час можно посчитать, что за рабочий день он запросит примерно 150 баксов. Ну 200.
Имеем по второму варианту в 4 раза меньше затрат, в 20 раз меньше рисков, в 50-100 раз больше выигрыш по времени (а следовательно меньше упущенная выгода бизнесу будет меньше).
Вроде бы все понятно должно быть. Другое дело, что нужно еще посчитать во сколько обойдется поддержка сайта в дальнейшем на Ruby и на PHP. Не думаю, что зарплаты спецов будут сильно различаться, все таки хоть Ruby и экзотика, но и спрос на нее мал. Просто найти специалиста будет сложнее, наверное. То есть выше затраты на подбор персонала, так сказать.
Так что вот вам все риски, которые можно исходя из здравого смысла накидать на стол для дальнейшего изучения.
А вообще, я считаю, что технология не имеет значения для веб-проектов. Роль кода в проектах достаточно невелика.
