Como exatamente as atualizações automáticas funcionam?

Recebi um email nesta manhã informando que meu site Wordpress havia sido atualizado automaticamente para a versão mais recente. Eu sabia sobre o recurso, mas sempre me perguntei exatamente como ele funciona.

O PHP não é um processo em execução permanente: só é executado quando solicitado. Até onde eu sei, o Wordpress só pode se atualizar quando alguém carrega uma página da web. Mas o processo de atualização não é instantâneo; portanto, um usuário que visita o site tem um carregamento de página muito lento.

Existe um truque diferente que eles usam para atualizações automáticas? Eu procurei por todo o lugar, mas não encontrei nenhuma explicação.

O PHP não é um processo em execução permanente: só é executado quando solicitado. Até onde eu sei, o Wordpress só pode se atualizar quando alguém carrega uma página da web. Mas o processo de atualização não é instantâneo; portanto, um usuário que visita o site tem um carregamento de página muito lento.

Existe um truque diferente que eles usam para atualizações automáticas? Eu procurei por todo o lugar, mas não encontrei nenhuma explicação.

O sistema que você está procurando aqui é chamado "WP Cron". É um sistema de processo em segundo plano no WordPress que permite que eventos ocorram fora do processamento normal. Eles ainda precisam de um gatilho para iniciá-los, mas não interferem no carregamento da página por causa do processo em segundo plano.

Então, sim, alguém deve carregar sua página. Desativado no arquivo default-filters.php, você encontrará esta linha de código:

add_action( 'init', 'wp_cron' );

Portanto, em cada carregamento de página, a função wp_cron é executada. Essa função acabou no wp-includes / cron.php e o que faz é verificar os eventos agendados no banco de dados. Se houver algum processo que ele precise executar em segundo plano, ele chamará a função spawn_cron.

O cron de criação tem dois métodos possíveis de operação, mas o primeiro e mais comum é chamar a função wp_remote_post para fazer uma conexão de volta a si mesma, na URL do wp-cron.php. Ao fazer essa solicitação HTTP extra, ele inicia outro processo PHP para fazer todo o trabalho real. A solicitação feita aqui é sem bloqueio, com um tempo limite de 0,01 segundos. Portanto, ele não obtém nenhum resultado aqui. O objetivo da solicitação é simplesmente iniciar um novo processo em segundo plano. Depois disso, ele simplesmente retorna, para que o usuário que está vendo nunca tenha atrasos.

O processo wp-cron.php é o que faz o trabalho real, a atualização e tudo mais. Muitos processos no WordPress são tratados pelo sistema cron. Pós-publicação agendada, processamento de pings, verificações de atualização, qualquer coisa que precise acontecer fora do fluxo normal pode ser agendada e executada conforme a necessidade.

Mas sim, um hit normal no site deve realmente acontecer para iniciar o processo. E não, o WordPress.org não entra em contato diretamente com seu site para iniciar as atividades, ele precisa receber algum tipo de tráfego para iniciá-lo. Qualquer forma de tráfego serve.

Na verdade, a atualização automática é enviada por push wp.org. O processo de atualização ainda é executado no seu site, mas em segundo plano via wp-cron.

Quando uma nova atualização secundária é lançada, os funcionários do WordPress começam a lançar a atualização. O processo de atualização real é iniciado depois que seu site verifica se wp.orghá atualizações, teoricamente uma atualização está disponível e seu site é escolhido aleatoriamente para ser atualizado.

(Obrigado @otto por apontar minha redação incorreta :))

Como todo site verifica wp.orgnovas versões (geralmente usando duas vezes por dia wp-cron), o servidor de rollouts sabe quantos sites precisam de uma atualização.

Em seguida, o lançamento começa, iniciando lentamente - 1 de 128 sites é atualizado automaticamente. Isso está sendo monitorado e, se a taxa de êxito não indicar problemas com o lançamento, mais sites receberão a atualização automática (geralmente a próxima etapa seria 1 de 64 e continuará aumentando dessa maneira) até que todas as atualizações automáticas sejam entregues.

Isso permite que os desenvolvedores parem a distribuição se ocorrer algum problema, mas a última atualização de 3.8para 3.8.1teve uma taxa de sucesso de 100%.

Os sites selecionados pelo 1 out of 128são realmente aleatórios. Bem, na verdade não, mas se você quiser saber, funciona assim:

O URL do site que precisa de uma atualização é usado com hash MD5. Usando apenas os três primeiros caracteres desse hash e convertendo-o base10, isso resulta em 4096 possibilidades. A atualização foi iniciada para sites com um número calculado entre 0 e 31 (4096/32 = 128).

Ok, acho que é bem aleatório, afinal;)

No meu caso, como eu administro muitos sites do WordPress, as atualizações levaram 1 dia - foi muito engraçado ver quando todas as páginas foram atualizadas.

Apenas no caso de você estar se perguntando: D

Aliás, aqui está um artigo no make.wordpress.org descrevendo o processo, como aconteceu.

Em termos muito amplos, quando um usuário visita o site, o wordpress verifica a expiração do timer e se uma expiração é detectada, outra solicitação é enviada ao servidor para "executar" as ações associadas ao evento expirado. É por isso que o usuário não sente nenhum atraso perceptível no carregamento da página, pois o servidor está executando a ação real (atualização neste caso) em um processo separado.

Isso funciona, mas o tempo não é muito preciso. Quanto mais tráfego o seu site tiver, mais preciso será.

As pessoas que desejam obter melhor desempenho e tempo mais preciso podem bloquear o "processo" cron interno que o wordpress possui e usar o processo cron do SO para acionar a verificação dos cronômetros.