Comments 29
Как пример норм, но в реальном приложении файл реализующий отправку сообщений будет действительно слабым местом в системе
Поясните пожалуйста.
Я бы использовал полиморфизм, работая с нужным потомком абстрактного класса, в зависимости от типа БД, кто-то другой, делал бы запросы средствами ZF, но использование родных ф-ций php для работы с базой — ограничит ваше приложение только базой MySql. Как я уже сказал для примера — норм, в реальных приложениях — слабое место. Учитывая, что остальной код вполне себе ООП
Слабое место тут как раз не столько в использовании pure php, сколько в том, что нет никакой обработки критических ситуаций. Например, как уже спрашивал markPnk, что будет, если отправка письма вдруг заняла больше минуты? Или что будет, если скрипт умрёт после того как mail() отработала, но запись ещё не удалилась из базы? Или письмо было отклонено почтовым сервером?
А почему сам файл который по крону пускается на plain php? Помоему было бы логичнее что же ZF использовать. Или это просто пример?
А почему вы почту не отправляете Zend_Mail и с базой не работаете классами зенда? На чём именно вы пытались сэкономить в этом случае?
Любой MTA, тот же сендмейл, лучше управится с очередью писем, чем `if ($isSent) {` + mail()
Любой MTA, тот же сендмейл, лучше управится с очередью писем, чем `if ($isSent) {` + mail()
«А почему вы почту не отправляете Zend_Mail » — потому, что данные записанные в БД уже подготовлены Zend_Mail и обрабатывать их повторно абсолютно бессмысленно.
«На чём именно вы пытались сэкономить в этом случае?» — не вижу смысла подключать фреймворк, если требуется сделать цикл по базе и вызвать функцию mail(). Данный файл вызывается с периодичностью раз в минуту, поэтому, чем меньше он будет потреблять ресурсов за раз, тем лучше.
«На чём именно вы пытались сэкономить в этом случае?» — не вижу смысла подключать фреймворк, если требуется сделать цикл по базе и вызвать функцию mail(). Данный файл вызывается с периодичностью раз в минуту, поэтому, чем меньше он будет потреблять ресурсов за раз, тем лучше.
Эм, кого обрабатывать? Как подготовлены?
А вы пробовали измерять разницу? Подключаемые файлы, которые, кстати говоря, будут закешированы оптимизатором, будут загружаться, ну, к примеру 0.01. А сколько вы времени потратили, используя pure php, а не ZF? ;-)
Вам теперь нужно поддерживать 2 кодовых базы, в то время как в случае с единым — вы просто могли re-use те же самые классы. Не?
На том ли вы экономите?
А вы пробовали измерять разницу? Подключаемые файлы, которые, кстати говоря, будут закешированы оптимизатором, будут загружаться, ну, к примеру 0.01. А сколько вы времени потратили, используя pure php, а не ZF? ;-)
Вам теперь нужно поддерживать 2 кодовых базы, в то время как в случае с единым — вы просто могли re-use те же самые классы. Не?
На том ли вы экономите?
«А вы пробовали измерять разницу?» — зачем? я могу поспорить, что код на нативном php будет работать быстрее и потреблять меньше памяти.
«Вам теперь нужно поддерживать 2 кодовых базы, в то время как в случае с единым — вы просто могли re-use те же самые классы. Не?» — Блин, код элементарный, в десять строчек! Реализация таких мелочей не требует мощи фрейморка.
«Вам теперь нужно поддерживать 2 кодовых базы, в то время как в случае с единым — вы просто могли re-use те же самые классы. Не?» — Блин, код элементарный, в десять строчек! Реализация таких мелочей не требует мощи фрейморка.
> зачем? я могу поспорить, что код на нативном php будет работать быстрее и потреблять меньше памяти.
Процессорное время стоит дешевле работы программиста. Зачем вы в принципе тогда пользуетесь фреймворками?
Почему там, где это действительно нужно (фронтенд — куча запросов) вы не экономите на спичках, а в бэкграундной задаче, которая (просто невероятно!) запускается раз в минуту — считаете это экономией? Всё таки определитесь, вам важен или качественный поддерживаемый код, тогда используем фреймворк везде и пишем нормальный код с нормальными логгерами, а не echo без перевода строки непонятно куда, или экономим спички везде и выкидываем фреймворк совсем.
Процессорное время стоит дешевле работы программиста. Зачем вы в принципе тогда пользуетесь фреймворками?
Почему там, где это действительно нужно (фронтенд — куча запросов) вы не экономите на спичках, а в бэкграундной задаче, которая (просто невероятно!) запускается раз в минуту — считаете это экономией? Всё таки определитесь, вам важен или качественный поддерживаемый код, тогда используем фреймворк везде и пишем нормальный код с нормальными логгерами, а не echo без перевода строки непонятно куда, или экономим спички везде и выкидываем фреймворк совсем.
> Блин, код элементарный, в десять строчек
И вы размазываете зависимости по куче файлов. Компоненты должны между собой общаться посредством интерфейсов, а не договорённостей вроде «там всё просто, там я никогда не ошибусь и никогда ничего не забуду»
И вы размазываете зависимости по куче файлов. Компоненты должны между собой общаться посредством интерфейсов, а не договорённостей вроде «там всё просто, там я никогда не ошибусь и никогда ничего не забуду»
Разве оптимизатор будет работать в консольном режиме? (я надеюсь вы скрипты в кроне запускаете именно в консольном режиме, а не дергаете их каким нибудь wget`ом)
`attempts = '. $row['attempts'] + 1. ' `
==
`attempts = attempts + 1`
==
`attempts = attempts + 1`
UFO just landed and posted this here
UFO just landed and posted this here
Дельное замечание. Можно добавить в таблицу поле «in_process» и перед mail() выполнять апдейт соответствующей строки: mysql_query('UPDATE email_queue SET in_process = 1 WHERE id = '. $row['id']); И получать массив писем из БД с учётом этого значения (in_process = 0).
Внёс соответствующие изменения в статью.
P.S. В примерах я использовал Zend Framework 2.0, которая на момент написания статьи ещё находится на стадии бета-тестирования. Если вы работаете с версией 1.*, то нужно переименовать классы ...
Вы уверены что этот код работает в zf2? Что-то я не нахожу public function _sendMail() {… }
в Zend/Mail/Transport/Sendmail.php.
С интересом прочитал, т.к. делал что-то похожее.
1. Вместо in_process было введено поле status типа ENUM('new', 'in progress', 'sent', 'failed') + поле error_message, куда записывается текст ошибки в случае status=failed. Очень удобно потом в PhpMyAdmin клацать «показать уникальные значения» и смотреть сколько сообщений каждого типа.
2. У вас никогда вот тут код не ломался?
Ситуация: у вас открылась транзакция, апдейт завалился — залогировали, сделали continue, опять вызовется $db->beginTransaction() и будет исключительная ситуация.
1. Вместо in_process было введено поле status типа ENUM('new', 'in progress', 'sent', 'failed') + поле error_message, куда записывается текст ошибки в случае status=failed. Очень удобно потом в PhpMyAdmin клацать «показать уникальные значения» и смотреть сколько сообщений каждого типа.
2. У вас никогда вот тут код не ломался?
$db->beginTransaction()
Ситуация: у вас открылась транзакция, апдейт завалился — залогировали, сделали continue, опять вызовется $db->beginTransaction() и будет исключительная ситуация.
Sign up to leave a comment.
Простой способ организации очереди e-mail с помощью Zend_Mail