Как работают автоматические обновления?

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

PHP не является постоянно работающим процессом: он запускается только по запросу. Насколько я могу судить, Wordpress может обновляться только тогда, когда кто-то загружает веб-страницу. Но процесс обновления не мгновенен, поэтому пользователь, посетивший сайт, будет иметь очень медленную загрузку страницы.

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

26 голосов | спросил DisgruntledGoat 27 Jpm1000000pmMon, 27 Jan 2014 14:32:35 +040014 2014, 14:32:35

3 ответа


14
  

PHP не является постоянно работающим процессом: он запускается только по запросу.   Итак, насколько я могу судить, Wordpress может обновлять себя только тогда, когда кто-то   загружает веб-страницу. Но процесс обновления не мгновенен, поэтому   конечно, пользователь, посетивший сайт, будет иметь очень медленную загрузку страницы.

     

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

Система, которую вы ищете, называется «WP Cron». Это система фонового процесса в WordPress, которая позволяет событиям происходить вне обычной обработки. Им по-прежнему нужен триггер, чтобы отбросить их, но они не мешают загрузке страниц из-за фонового процесса.

Итак, кто-то должен загрузить вашу страницу. Выключен в файле default-filters.php, вы найдете эту строку кода:

add_action( 'init', 'wp_cron' );

Таким образом, при каждой загрузке страницы выполняется функция wp_cron. Эта функция завершена в wp-includes /cron.php, и что она делает, это проверять запланированные события в базе данных. Если есть какие-то процессы, которые нужно запустить в фоновом режиме, тогда он вызывает функцию spawn_cron.

Spawn cron имеет два возможных метода работы, но первым и наиболее распространенным является вызов функции wp_remote_post для подключения к себе по URL-адресу wp-cron.php. Сделав этот дополнительный HTTP-запрос, он запустит другой процесс PHP, чтобы выполнить всю фактическую работу. Запрос, который он делает здесь, является неблокирующим с таймаутом 0,01 секунды. Таким образом, здесь нет никаких результатов. Цель запроса - просто начать новый процесс в фоновом режиме. После этого он просто возвращается, поэтому пользователь просмотра никогда не имеет задержек.

Процесс wp-cron.php - это то, что делает фактическая работа, а также обновление и все остальное. Многие процессы в WordPress обрабатываются системой cron. Запланированная публикация публикаций, обработка писем, проверка обновлений, все, что должно произойти за пределами обычного потока, могут быть запланированы и затем выполняться по мере необходимости.

Но да, нормальное попадание на сайт должно действительно произойти, чтобы начать процесс. И нет, WordPress.org не связывается с вашим сайтом напрямую, чтобы отбросить ситуацию, ваш сайт должен получить некоторую форму трафика для его запуска. Любая форма трафика будет делать.

ответил Otto 21 52014vEurope/Moscow11bEurope/MoscowFri, 21 Nov 2014 13:10:42 +0300 2014, 13:10:42
16

Фактически, автоматическое обновление выводится из wp.org. Процесс обновления по-прежнему выполняется на вашем сайте, но в фоновом режиме с помощью wp-cron.

Когда выпущено новое незначительное обновление, ребята из WordPress начинают развертывать обновление. Фактический процесс обновления запускается после проверки вашего сайта wp.org, обновление теоретически доступно, и ваш сайт выбирается случайным образом для обновления.


  

(Спасибо @otto за указание моей неправильной формулировки :))


Поскольку каждый сайт проверяет с помощью wp.org для новых версий (обычно дважды в день с использованием wp-cron), сервер rollouts знает, сколько сайтов нуждается в обновлении.

Затем начинается развертывание, начиная медленно - 1 из 128 сайтов обновляется автоматически. Это отслеживается, и если успех не показывает никаких проблем с развертыванием, большинство сайтов получают автоматическое обновление (обычно следующим шагом будет 1 из 64 и будет продолжать увеличиваться) до тех пор, пока все автоматические обновления не будут доставлены.

Это позволяет разработчикам остановить развертывание, если возникнут какие-либо проблемы, но последнее обновление от 3.8 до 3.8.1 имеет 100% -ный шанс успеха.

Сайты, выбранные 1 out of 128, на самом деле случайны. Ну, не совсем, но если вы хотите знать, он работает следующим образом:

URL-адрес сайта, нуждающегося в обновлении, получает хеширование с использованием MD5. Используя только первые три символа этого хэша и преобразовывая его в base10, это приводит к 4096 возможностям. Обновление началось для сайтов, имеющих расчетное число от 0 до 31 (4096/32 = 128).

Хорошо, я предполагаю, что это довольно случайно в конце концов;)

В моем случае, когда я запускал много сайтов WordPress, обновления заняли 1 день - было довольно забавно видеть, когда были обновлены все страницы.

На всякий случай вам интересно: D

btw, здесь - статья на make.wordpress.org, описывающий процесс, как это произошло.

ответил fischi 27 Jpm1000000pmMon, 27 Jan 2014 15:25:08 +040014 2014, 15:25:08
1

В очень широких терминах, когда пользователь посещает сайт, Wordpress проверяет истечение срока действия таймера и, если обнаруживается истечение срока действия другой запрос отправляется на сервер для «запуска» действий, связанных с истекшим событием , Вот почему пользователь не ощущает заметной задержки загрузки страницы, так как сервер выполняет фактическое действие (обновление в этом случае) в отдельном процессе.

Это работает, но время не очень точное. Чем больше трафика на вашем сайте будет, тем точнее будет.

Люди, которые хотят повысить производительность и более точное время, могут блокировать внутренний процесс cron «wordpress», и использовать процесс cron для запуска проверки таймеров.

ответил Mark Kaplun 27 Jpm1000000pmMon, 27 Jan 2014 14:55:03 +040014 2014, 14:55:03

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132