Расписание работы Cron

У меня есть веб-страница PHP, которая обслуживает RSS-канал, но для генерации ответа требуется около 15-20 секунд (который затем будет кэшироваться на 10 минут на сервере для более быстрых ответов).

Как я могу установить время работы cron для этой операции? У меня проблема с этим. Я думаю, что если я вызову страницу до 10 минут, она запустит кешированную страницу, поэтому я не получу последнюю обновленную страницу, это правда? И если я позвоню на эту страницу через 10 минут, мне придется ждать 15-20 секунд, чтобы получить ответ?

Как мне организовать этот процесс, при котором я буду получать обновленную ленту с быстрым ответом? Я никогда не пробовал работу cron раньше, это мой первый раз, поэтому я нахожу это запутанным.

Моя команда cron: */10 * * * * wget http//www.example.com/multifeed.php

Это правильно?


person Roon13    schedule 16.04.2015    source источник
comment
Вы можете сделать что-то вроде */10 * * * * php /path/to/script.php > /path/to/rss.xml. Ваш cron обычно настраивается с помощью crontab -e, но некоторые хосты вместо этого предлагают панель управления. Да, если вы кешируете каждые 10 минут, то ваш обслуживаемый RSS будет где-то между 0-10 минутами, в зависимости от времени срабатывания вашего cron и времени посещения пользователем.   -  person halfer    schedule 16.04.2015
comment
(Кэширование, как правило, хорошая идея, хотя 15-20 секунд кажутся довольно медленными, и вы также можете исправить это).   -  person halfer    schedule 16.04.2015
comment
@halfer получает ленту со стороннего сайта, поэтому я считаю, что для вызова сторонней страницы и ее обслуживания требуется столько же. Но проблема в том, когда я должен вызвать php-скрипт для запуска этой страницы?   -  person Roon13    schedule 16.04.2015
comment
Ах да, сторонние системы, вероятно, будут медленнее, хорошо. Я не уверен, что понимаю ваш последующий вопрос - приведенная выше строка идет в ваш crontab. Cron автоматически запускает скрипт каждые 10 минут и записывает XML-файл, который ваш веб-сервер может обслуживать как есть.   -  person halfer    schedule 16.04.2015
comment
Команда @halfer cron в порядке, но я столкнулся с другой проблемой.   -  person Roon13    schedule 16.04.2015
comment
@halfer извините, я говорил, как написать cron для этого процесса, так как я не хочу видеть старые каналы с кэшированной страницы. каким должно быть время вызова сценария cron для этой проблемы?   -  person Roon13    schedule 16.04.2015
comment
@halfer я думал, что не проявил уважения к моему предыдущему комментарию, говоря, что я столкнулся с другой проблемой, не указав точную проблему, с которой я столкнулся   -  person Roon13    schedule 17.04.2015
comment
@halfer Если страница не кэшируется, пользователь получает пустой экран, потому что это занимает 15-20 секунд. После обработки он будет храниться в течение 10 минут, но я не хочу, чтобы это происходило, пустой экран. Поэтому я ищу идеальный процесс работы cron   -  person Roon13    schedule 17.04.2015
comment
Пожалуйста, отредактируйте свой вопрос, чтобы показать, что у вас есть: (а) как вы запускаете свой процесс cron? (б) какой у вас PHP-код? Спасибо.   -  person halfer    schedule 17.04.2015
comment
Вы multifeed.php скрипт записываете данные в конце? Если да, то не должно быть 15-20-секундного периода, когда файл XML не существует. С другой стороны, если вы удаляете файл в начале и записываете его в конце, это ваша проблема.   -  person halfer    schedule 19.04.2015
comment
Я нашел способ решить эту проблему, увеличив время ожидания. Я знаю, что это не лучшая практика. Таким образом, один пользователь теперь должен ждать 15 секунд, а другие получат более быстрый ответ. В Multifeed.php я не использовал ни одной строки кода xml.   -  person Roon13    schedule 20.04.2015


Ответы (1)


У вас не будет идеального cron для доставки свежих данных, как только они станут доступны. Я думаю, это ограничение, с которым вам придется жить.

Я бы запускал этот cron каждые 2 минуты и пытался получить новые данные, я бы проверил, отличается ли последнее обновление от того, что у меня уже есть, и если да, обновите файл, если нет, ничего не делайте. и дождитесь следующего cron.

Этот метод предоставит не более двух минут устаревших данных.

Другой вариант — проверить mtime файла hte: http://php.net/manual/en/function.filemtime.php

В основном, я захожу на вашу страницу, мы проверяем mtime файла, если оно превышает 10 минут, мы извлекаем свежие данные, это в сочетании с cron может предоставить пользователям возможность всегда видеть свежие данные. Если свежесть информации не так важна (вы можете жить с двухминутными устаревшими данными?), если это не так важно, просто запустите двухминутный cron.

Надеюсь, поможет.

person Patrick    schedule 16.04.2015
comment
Единственное предостережение заключается в том, устраивает ли сторонний сайт 720 запросов каждый день из одного источника. Это не большая нагрузка, но если операторы сайта видят частые и регулярные IP-адреса в своих журналах, они могут быть склонны к блокировке (особенно если каждый из них занимает 15+ секунд для рендеринга). В конце концов, это зависит от того, есть ли у OP разрешение на выборку. - person halfer; 16.04.2015
comment
@halfer Я получаю rss-ленту с их сайта, что я делаю, так это конвертирую их в полную ленту, поэтому, я думаю, это заняло 15-20 секунд. - person Roon13; 16.04.2015
comment
@ Roon13 У Халфера есть точка зрения: если у вас есть метод получения времени последнего обновления с сервера, это было бы еще лучше, так как запросы стали бы намного дешевле и быстрее. - person Patrick; 16.04.2015
comment
Теперь я понимаю вашу точку зрения. У меня нет этой реализации, поэтому я сначала поработаю над ней, а затем дам вам знать, сработало это или нет. Спасибо, Халфер и Патрик. - person Roon13; 16.04.2015