Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > PHP: Общие вопросы > выполнение алгоритма в определенное время

Автор: Alix36 10.7.2011, 12:39

Предположим есть такая задача. В неком хранилище (Таблица в базе, стэк в кэше) храниться список отложенных задач. Нужно написать к ним обработчик. Вопрос как лучше это сделать.  Варианты 1) Хранилище: БД? память? файл? Поскольку задачи могут быть запланированы даже на соседние секунды, то запрос к бд придется делать ежесекундно, что может пагубно сказаться на БД, даже если каждый запрос будет возвращать по 2 строки. С файлом еще хуже, мало того что может сильно обидеться контроллер диска на ежесекундное чтение/добавление, так еще и интерфейс обращение не такой удобный. Выбор однозначно память? или все таки вариант с БД имеет право на жизнь? 2) "Выполнятор": Cron, демон Насколько плох ежесекундный вызов cron'ом какого-либо скрипта?  Хотя плюсы демона мне тоже не очевидны. Как стоит реализовывать демона, выполняющего отложенные таски? Как вечный цикл, проверяющий "просроченные" таски? тогда обращение к хранилищу будет чаще чем ежесекундно... Даст ли реализация с демоном какие-либо преимущества? или все же демоны хороши исключительно для отлова входящих "сигналов"(пакетов, сообщений)

Автор: ivashka 10.7.2011, 12:51

Как по мне то однозначно БД только таблица MEMORY (если нужно что бы надежность была выше, задания хранятся в обычной таблице, а при старте скрипта копируем в таблицу мемори). В таком случае будет и интерфес удобный, и скорость норм, и хард дольше и лучше жить. На счет реализации, то как я понимаю будет пхп, тогда вариант с демоном.  Логика следующая, запускается демон, смотрит есть ли задачи к выполнению, если есть, передает берет задачу, форкается и форк исполняет задание, главный процесс смотрит дальше есть ли задачи. Такой вариат у меня работает без перерыва уже 9 месяц.

Автор: Alix36 10.7.2011, 21:30

Цитата(ivashka @  10.7.2011,  12:51 ) (если нужно что бы надежность была выше, задания хранятся в обычной таблице, а при старте скрипта копируем в таблицу мемори) Вот тут не понял, зачем вторая таблица? Цитата(ivashka @  10.7.2011,  12:51 )  главный процесс смотрит дальше есть ли задачи Вот это тоже интересный моменет. "Смотреть, есть ли задачи" получается можно только выборкой из БД.  Тогда в главном треде получаем while(1) с селектом внутри...  Соотв. селект будет выполняться до нескольких десятков раз в секунду.  --- Может тогда лучше так.  Главный тред - хранит в памяти всю очередь. Зациклен и вызывает в отдельных тредах обработку каждого "подоспевшего" таска.  Так же главный тред разово стартует вторичный тред, который так же живет "вечно", выбирает и добавляет в  основную очередь новые таски и sleep'ает себя на 30* секунд. *- минимальное время "задержки" выполнения таска.

Автор: ivashka 11.7.2011, 11:36

По поводу второй таблицы: если у вас сервер упадет, все данные с мемори удалятся, соответственно и выходит 2 таблицы. Одна допустим innoDB вторая Memory. Выгребать все таски не знаю стоит ли, дело в том, что в таком случае вы не сможете добавить заданий во время работы.  Лучше выгребать хотябы по 5, или другое количество, но не всю, хотя вариант, выгребать все, проходится, слипнуться, выгребать все и т.д. вполне вменяем. А зачем вторичный процес держать вечно, лучше форкать, одно задание одному ребенку.

Автор: solenko 11.7.2011, 13:05

Цитата(Alix36 @  10.7.2011,  11:39 ) список отложенных задач Это задачи, которые нужно выполнять "как только получится", или "строго по расписанию"? Если как только получится -- http://www.amqp.org

Автор: Alix36 12.7.2011, 16:32

Цитата(ivashka @  11.7.2011,  11:36 ) По поводу второй таблицы: если у вас сервер упадет, все данные с мемори удалятся, соответственно и выходит 2 таблицы. Одна допустим innoDB вторая Memory. Я имел ввиду, что если у нас появляется inno-таблица то теряется смысл memory-таблицы. Зачем дублировать информацию, если и так уже храним в стабильной таблице. Цитата(solenko @  11.7.2011,  13:05 ) Это задачи, которые нужно выполнять "как только получится", или "строго по расписанию"? как только задача "просрочилась") В любом случае вопрос именно в решении на php, а не в отдельном демоне.

Автор: baldina 12.7.2011, 16:50

Цитата(Alix36 @  12.7.2011,  16:32 ) В любом случае вопрос именно в решении на php, а не в отдельном демоне. почему? просто интересно Цитата(Alix36 @  10.7.2011,  12:39 ) Насколько плох ежесекундный вызов cron'ом какого-либо скрипта?  в принципе неплох. cron как таковой очень мало нагружает систему. и уж по крайней мере не надо думать о "тредах и слипах" cron+БД+скрипт на любом языке позволят решить задачу быстро. если упрется в эффективность, тогда рассматривать другие варианты такое решение позволяет провести быстрое прототипирование, сосредоточиться на главном. а что известно про задачи и их количество? скажем, если задач немного, но они ёмкие, механизм вызова не влияет на загрузку, и наоборот про БД думаю беспокоиться не стоит, её для того и придумали, штоб работала. ежесекундный запрос для базы, возвращающий 2 короткие записи - сущий пустяк. к тому же в таком режиме оно вероятно в кэше поселится.

Автор: Alix36 12.7.2011, 18:55

Цитата(baldina @  12.7.2011,  16:50 ) в принципе неплох. cron как таковой очень мало нагружает систему. и уж по крайней мере не надо думать о "тредах и слипах"  форкать все равно нужно будет, если будут массивные задачи. и по несколько в секунду, их нужно разносить на форки. или каждую секунду выбирать по 1 таску, тогда получим накопление очереди, точнее можем получить Цитата(baldina @  12.7.2011,  16:50 ) почему? просто интересно вопрос просто в основном теоретический. Просто ради того, что-бы узнать что можно, что нельзя и что лучше.

Автор: srt 12.7.2011, 18:59

Alix36, как тебе удобно, так и сделай крон или крен - пофик

Автор: baldina 12.7.2011, 19:03

Цитата(Alix36 @  12.7.2011,  18:55 ) форкать все равно нужно будет форкать в баше попроще чем в php ;-)

Автор: srt 12.7.2011, 19:11

отложенные задачи - отложенные задачи реализовать либо по времени либо по событию ну дык

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)