20091005

Рассылка сообщений подписчикам на виртуальном сервере-тугодуме.

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


Подписчики есть, а «создатель» (мать его-так этого шабашника) сайта — тот человек, который его устанавливал за деньги, не удосужился проверить работоспособность большинства функций.
В результате после трех долгих и нудных дней перебора кода:
— убрал хлам, который этот творец оставил в виде набора файлов с предыдущего хостинга;
— нормализовал работу hfu, которая базируется на стандартном модуле мамбо sef;
— нормализовал бэкап;
— нормализовал шаблон, убрав лишние div-ы. С ним еще придется повозиться, но уже лучше;
— самое главное и интересное — малыми трудовыми затратами организовал отправку сообщений подписчикам с сайта.
Лирическое отступление:
  • Мало того, что у меня и так чуть было не случился вывих мозга от того, что на сайте используется старый движок,
  • так еще и чуть не появился нервный тик, когда я узнал, что хостер работает под linux-ом, ядро которого последний раз обновлялось в 2005 году,
  • в качестве верси php у него висит (ну, иногда работает) php 4.0.1,
  • в качестве расширений php стоит только поддержка mysql,
  • что такое сессии эта (!?!!) версия php вообще не знает — судя по всему — самопальная сборка.
  • В качестве субд на хостере доступна только mysql 3.1 с поддержкой исключительно myIsam.
  • При любой попытке модификации. htaccess иначе, чем установкой правил ModRewrite сайт падает с 500-й ошибкой.
  • В довесок всё усугубилось тем, что ограничение времени выполнения скрипта — 30 секунд, а сообщений, как и подписчиков — более пяти сотен.
  • Исходя из этих возможностей идея быстро накидать нормальный движок на zendFramework-е отпала. Так же, как и идея хранения сессионных данных в heap-таблицах MySql.
Задачу надо выполнять. При этом на момент постановки вопроса  скорость работы сайта мало имела значение — основной критерий срочность реализации возможностей. Разумеется, в ближайшее время я соберу из своей коллекции классов нормальный движок для сайта и размещу его на стабильном хостинге, но это потом.
Для начала пришлось исправить множество багов мелких и крупных. Начиная от уборки присваивания значения функции по ссылке, заканчивая сложно обнаруживаемыми кусками кода, которые не работали, либо работали неправильно, ибо выключены глобальные переменные.Но вот, как пришлось выкрутиться из ситуации с ограничением времени работы скрипта.

Идея не нова: не успеваешь — раздели задания на несколько частей.
Реализацией стал следующий алгоритм:
Оригинальный почтовик mambo не отправляет письма, а сохраняет их во временном каталоге. На это и 10 секунд хватает выше крыши. что будет далее — надо думать (но это потом).
Далее скрипт передает управлению новому для него модулю — отправителю писем.
Отправитель первым делом засекает время своего старта, затем начинает перебирать имеющиеся сообщения и отправлять их по одному.
После отправки сообщение удаляется.
Проверяется время, затраченное на общее выполнение скрипта. Если оно более 20 секунд, то производится перенаправление на самого себя — рекурсия, так сказать.
В конце работы (если сообщений для отправки не найдено), производится перенаправление назад в mambo.
Как мне кажется, учитывая такую ущемленность в технологиях я выбрал неплохое решение.
Надеюсь, что временное, ибо протискиваться в такие рамки, учитывая 21 век — глупо.

Комментариев нет: