Конфигурирование Крона.

Зачем нужен Крон?

Чтобы иметь возможность отсылать письма скриптом, необходимо внешнее приложение, которое бы этот скрипт периодически запускало (не руками же Вы это будете делать). Иначе никакой рассылки не случится.

Кроме того, любой хостер имеет лимиты на число отправленных писем. Эти лимиты могут быть чётко оговорены в тарифе (например, 600 писем в час), а могут вообще никак не фигурировать на сайте хостера. Но такие лимиты всегда есть, в этом даже не сомневайтесь. И нужно тщательно планировать процедуру рассылки таким образом, чтобы не выйти за "красную линию", обозначенную хостером. Потому как по ту сторону красной линии начинаются санкции. Иногда очень жестокие.

Информация к размышлению::

Тот, кто считает, что можно по-быстрому отправить рассылку из 10 тысяч писем за полчасика, прямо с этого места на основании вышеизложенного начинает знать, что хостер просто не даст Вам сделать этого.

Хотя Почтовая Нана способна отправить 144 тысячи писем в сутки, в реальной жизни Вы будете ограничены почтовым трафиком раз в десять меньше.

Единственный способ эффективно воспользоваться лимитом хостера на отправку писем - установить правильное число единовременно отсылаемых писем в настройках скрипта, и равномерно распределить процедуру таких отсылок по времени. Чтобы максимально полно использовать каждый часовой лимит.

Вот тут и понадобится так называемый Крон, который запускается строго по расписанию. С его помощью можно управлять плотностью потока писем, укладываясь в лимиты хостера. Никак иначе этого не сделать.

К чему применять Крон?

Прямо на морде админки будут два длинных и затейливых URL-а.
На примере демоверсии админки они выглядят так:

URL-ы для Кронтаба хостера:

  1. URL рассыльщика:
    http://nanocms.name/postman/demo/admin_5400c8a53025875b1b018f4593f2baba.htm

  2. URL бэкапера:
    http://nanocms.name/postman/demo/admin_a073def688102efc77668143100a4978.htm

  1. URL рассыльщика - его надо запускать регулярно.
    Именно там проистекает отправка писем почтовых рассылок.

  2. URL бэкапера - запускается раз в сутки.
    Создаёт полный бэкап всех баз и писем для каждой службы.

    Крайне рекомендуется пользоваться этим автоматическим бэкапером.
    У Вас всегда будут архивы за последние десять дней.
    Или сколько зададите в настройках.

Информация к размышлению::

Обратите внимание, что Крон адресуется именно к URL-ам, а не к каким-то локальным файлам. И Вы должны чётко понимать, почему делается именно так. Соображений тут всего два.

  1. Овнер при запуске локального файла и при доступе к скрипту из WEB-а будет разный, и, соответственно, начнётся свистопляска с правами доступа. Для локальной машины их будет достаточно, для WEB-доступа их может не хватить. Соответственно, админка окажется бессильна.

    Хоть хостеры и настраивает свои сервера так, чтобы пользователь по возможности не сталкивался с подобным, тем не менее такие коллизии на практике случаются регулярно. В рамках борьбы с чем разработчик Почтовой Наны поступил кардинально - запуск всех скриптов возможен только из WEB-а. Строго по URL-у. И никак иначе.

  2. Возможность дистанцирования Крона и Почтовой Наны.

    Обращение Крона именно к URL-ам позволяет держать Почтовую Нану на одном сервере (где, быть может, вообще нет никакого Крона, а потому скрипты аналогичного назначения там жить не могут, ввиду чего пользователи из-за отсутствия конкуренции за ресурсы имеют совершенно шикарные лимиты на отправку писем), а систему запуска рассыльщика и бэкапера - на другом сервере.

Про синтаксис Крона.

Узнавайте про него у своего хостера.
Никто, кроме хостера, того синтаксиса не знает.

Только при затребовании синтаксиса Крона от хостера оговаривайте, чтобы вывод шёл на нулевое устройство. Иначе отчёт о каждом запуске Кроном любого задания будет поступать либо на Ваш e-mail, либо в виде файлика записываться в корень сервера. Ни один из вариантов не несёт в себе никакого смысла, а лишь создаёт мусор в e-mail клиенте или на сервере, и понапрасну расходует ресурсы.

Классический вариант синтаксиса Крона, например, у хостера данного сайта, выглядит так:

GET http://nanocms.name/postman/demo/admin_cron_xxx.htm > /dev/null

Правее от URL-а как раз и прописан вывод на нулевое устройство.

Периодичность запуска Крона.
Что нужно знать для расчёта.

Сперва узнайте у своего хостера его лимиты на отправку писем.
Идеология ограничений может быть самой разнообразной, Вы её должны знать и понимать:

  1. По стоимости тарифа.

    Например, на самом дорогом тарифе Агавы есть ограничение в 900 писем в час. Больше послать физически нельзя (сверхнормативные письма просто пропадают). На тарифе подешевле- 500 писем в час, и так далее.

    Хостер может установить суточные лимиты.
    Это не важно, пересчитать их в часовой лимит несложно.

  2. Единый лимит.

    Хостер знает максимальную пропускную способность своего почтового шлюза, делит её на число пользователей хостинга, и ограничивает каждого из пользователей полученным значением. Значение то обычно получается небольшим, порядка ста писем в час. Или того меньше.

  3. Лимиты, обусловленные фильтрами контента.

    Экзотика, но тоже имеет место быть. К примеру, на той же Агаве есть исходящие почтовые фильтры, не дающие посылать письма чаще, чем 4 штуки в секунду.

Также учтите, что Крон в понимании хостера есть второстепенное, но ресурсоёмкое приложение. У популярных хостинговых компаний, обычно набирающих пользователей "под завязку", чтобы оборудование приносило максимально возможный доход, на обеспечение работы дополнительных приложений уже обычно не остаётся ресурсов. Либо их остаётся мало, и поэтому возникают ограничения на запуск Крона. Например, Вам могут заявить, что больше 12 раз в час запускать Крон нельзя, и баста. Пятиминутный Крон возможен, а чаще - даже не мечтай.

Теперь уже понимая, что жизнь у хостера непроста, и с ним нужно дружить, не внося своим необдуманным поведением ненужные осложнения в отношения, Вы в идеале должны потреблять только необходимые и достаточные ресурсы хостера, а не по максимуму. А потому требуется не просто вписать в задание крону предельные разрешённые значения, а оценить, что Вам в действительности необходимо.

Исходными данными для расчёта, как Вы уже поняли, служат два параметра:

a) Лимит на отправку писем в час.
b) Лимит на частоту запуска Крона в час.

Вычисление периода запуска Крона.

Зная два оговоренных выше лимита (спрашивайте о них у своего хостера) и свою потребность для рассылки, можно начинать деление циферок. Что, однако, тоже не просто для понимания.

Например, пусть у Вас в Почтовой Нане заведено пять служб серийных рассылок, в каждой из которых сформировано по пять писем, и Вы наблюдаете, что на каждую из рассылок в день подписываются в среднем по 50 человек.

Давайте считать, сколько же писем в сутки Вам нужно отправить.

250 подписчикам (умножаем 5 служб на 50 новых подписчиков) необходимо выслать письмо с подтверждением подписки, причём не все из них подтвердят свою подписку сразу. Возможно, некоторым с определённой периодичностью придётся потом напоминать о необходимости подтверждения подписки - Почтовая Нана умеет это делать. Так что с поправкой на нерасторопность это будет уже не 250, а примерно 270 писем в сутки.

Имея ввиду подписавшихся ранее, получающих сейчас ежедневные письма серийных рассылок с первого по пятое, мы имеем ещё 5*50 писем для каждой из служб, или 1250 для всех пяти.

Простое суммирование даст нам 1520 писем в сутки, или, при делении с округлением, 64 письма в час. Это и есть наша истинная потребность, которую теперь надо как-то привязать к лимитам хостера.

Тут мы уже видим, что от хостера нам требуется возможность отправки не менее 64 писем в час. В противном случае нам придётся либо уменьшить число служб, либо переструктурировать их письма, чтобы писем в серии было не 5, а меньше - тогда мы сможем уложиться в лимит хостера.

Но допустим, что в часовой лимит по почтовым отправлениям мы уложились - пусть у нас для определённости возможна отправка скромного числа в 150 писем в час (хостинг совсем уж начального уровня) - и теперь нас интересует лимит по запуску крона.

Опять-таки возьмём средний случай, когда хостер разрешает пятиминутный крон. Это 12 сработок в час. Из чего следует, что при делении 64 ежечасных писем от всех наших серийных рассылок на 12 сработок Крона в час, с округлением с избытком, мы получаем необходимость отправки всего лишь 6 серийных писем за одну сработку Крона.

В этом месте мы вспоминаем, что настройками скрипта предусмотрена различная толщина для пачек писем серийных и новостийных рассылок (выпадающие формочки "слать писем за раз"). И будет правильным установить в первой из них пачку из 6 писем, раз так получилось из наших расчётов.

Теперь мы должны понять, сколько писем может быть в пачке для новостийных рассылок.

Это просто - 150 разрешённых писем в час делим на 12 сработок крона в час же, получаем 12 писем (с округлением в меньшую сторону), и отнимаем от этого числа шесть писем, отведённых для серийных рассылок. Итого в обеих формах нам требуется поставить по шестёрке.

Теперь произведём перерасчёт в обратном порядке, и зафиксируем, что 6*12*24=1728 - такое максимальное письмо писем в сутки мы можем отправить в рамках серийных рассылок, и, как следует из лимитов хостера, ровно столько же мы можем послать и в рамках новостийных рассылок.