Скажем, вы пишете демона, который обслуживает очередь заданий. Различные другие программы записывают задания для демона в очередь. Демон проверяет очередь каждые несколько секунд для ожидающих заданий. Предположим, что очередь реализована в виде таблицы в базе данных MySQL и что демон представляет собой простой цикл:
Демон должен пережить прерывание службы с сервера БД MySQL и нарушение связей с БД.
Вы могли бы спроектировать демона для подключения к серверу БД один раз за цикл? т.е. подключиться до 1. и отключиться между 2 и 3?
Или у вас есть демон, открывающий соединение? В этом случае ему также необходимо: a) обнаружить, когда сервер или соединение не работают, b) отключить и снова подключиться, и c) сделать это, не накапливая соединения DB, дескрипторы соединения dud или другие мертвые ресурсы.
Если у вас есть предпочтение, почему?
За и против?
Факторы, которые входят в дизайн?
Любые другие подходы?
Ответ здесь: mysql connection from daemon, написанный на php , не говорит, почему лучше поддерживать соединение открытым. Я читал в другом месте, что накладные расходы на соединение в MySQL очень легкие. Поэтому неясно, почему постоянное потребление одного серверного соединения лучше, чем подключение / отключение каждые несколько секунд.
В моем случае демон написан на PHP.
Я на самом деле работаю над чем-то очень близким к тому, что вы описали, но в моем случае демон не проводит опрос на случай, когда он получает асинхронно через XMPP (но это не так).
Вырезать среднего человека
Я думаю, вместо хранения событий в базе данных и опроса w / MySQL вы, вероятно, могли бы использовать Gearman для отправки их от клиента асинхронно ( пример ).
Вывоз мусора
PHP на самом деле не предназначен для запуска в качестве демона, и только в PHP 5.3, когда он получил круговую сборку мусора , стал жизнеспособным вариантом. Очень важно, чтобы вы использовали PHP 5.3, если хотите, чтобы на долговременной работе не было утечек памяти.
Еще одна вещь, о которой нужно помнить о GC, – это то, что память доступна только в том случае, если она больше не упоминается (где угодно). Поэтому, если вы назначаете переменную глобальной области, она будет там до выхода демона. Важно, чтобы любой созданный вами код не создавал переменные в местах (т. Е. Статический журнал, не удаляя старые данные и т. Д.).
Статический кэш
Другое дело, что очень часто нужно запускать clearstatcache . Поскольку ваш процесс PHP не перезапускается, важно выполнить этот вызов вручную, чтобы предотвратить получение старых данных статистики (что может или не может повлиять на вас). Согласно документации эти функции кэшируются.
Затронутые функции включают stat (), lstat (), file_exists (), is_writable (), is_readable (), is_executable (), is_file (), is_dir (), is_link (), filectime (), fileatime (), filemtime () , fileinode (), filegroup (), fileowner (), filesize (), filetype () и fileperms ().
Управление ресурсами
Если вы собираетесь использовать такие вещи, как MySQL, в течение всего жизненного цикла вашего процесса, я бы предложил создать одно соединение при запуске и сохранить его в живых. Несмотря на то, что он может использовать больше бара на стороне MySQL, вы выберете некоторую задержку и накладные расходы процессора, не подключаясь через каждые 1 секунду.
Нет запроса URL
Это может показаться очевидным, но с CLI PHP нет информации о запросе URL. Некоторые библиотеки не написаны с учетом этого, и это может вызвать некоторые проблемы.
LooPHP
Я собираюсь выпустить бесстыдный плагин здесь для фреймворка, который я написал, чтобы помочь с управлением демонами PHP. LooPHP – это среда цикла выполнения, которая позволяет планировать событие или создавать прослушивание для абстрактных источников (сокет, поток и т. Д.). В моем случае у меня есть демон, делающий больше, чем 1 вещь, поэтому очень полезно, чтобы система отслеживала все таймеры для меня, чтобы я мог эффективно опросить stream_select для XMPP-соединения.
Если вы хотите сделать надежный демон, вам придется ломать ошибки базы данных / разъединения и повторно подключаться в любом случае (отключая или оставаясь подключенным). Поскольку вам все равно нужно это сделать, вы можете повторно использовать одно соединение.
Другими словами, только потому, что у вас недавно открытое соединение, это не означает, что запрос не будет терпеть неудачу, и соединение нужно будет снова открыть и повторить попытку.
Поэтому я считаю, что самым чистым способом было бы сохранить связь. Но только едва.
Я думаю, что самое лучшее, что вы можете сделать, это измерить время, необходимое для подключения / отключения к / из базы данных. Затем попытайтесь придумать какую-то вероятность того, что сервер базы данных станет недоступным. Определите стоимость постоянного подключения к серверу. И, наконец, попытайтесь определить стоимость (в часах, раздражении или что-то еще) добавления кода, который связан с проблемами подключения к базе данных. Если вы можете успешно определить эти числа и сравнить их, у вас есть ответ. Мне трудно (и я предполагаю, что кто-либо) придумать хорошие оценки для этих ценностей, но, вероятно, вывод будет заключаться в том, что это выбор между эффективностью и осуществимостью (с точки зрения более низкой стоимости).