자동 업데이트는 정확히 어떻게 작동합니까?


28

오늘 아침에 Wordpress 사이트가 자동으로 최신 버전으로 업데이트되었다는 내용의 이메일을 받았습니다. 나는 그 기능에 대해 알고 있었지만 항상 그것이 어떻게 작동하는지 궁금했습니다.

PHP는 영구적으로 실행되는 프로세스가 아닙니다. 요청 된 경우에만 실행됩니다. 내가 알 수있는 한 Wordpress는 누군가 웹 페이지를로드 할 때만 자체 업데이트 할 수 있습니다. 그러나 업데이트 프로세스는 즉각적이지 않으므로 사이트를 방문하는 사용자는 페이지로드 속도가 느려질 것입니다.

자동 업데이트에 사용하는 다른 방법이 있습니까? 나는 모든 곳을 수색했지만 설명을 찾지 못했습니다.


정확히 말하면 3.8에서 3.8.1과 같이 새로운 부 또는 보안 업데이트가 릴리스 될 때만 업데이트되지만 3.9가 주 버전 업데이트로 릴리스되면 수동으로 업데이트해야합니다.
보렉

답변:


15

PHP는 영구적으로 실행되는 프로세스가 아닙니다. 요청 된 경우에만 실행됩니다. 내가 알 수있는 한 Wordpress는 누군가 웹 페이지를로드 할 때만 자체 업데이트 할 수 있습니다. 그러나 업데이트 프로세스는 즉각적이지 않으므로 사이트를 방문하는 사용자는 페이지로드 속도가 느려질 것입니다.

자동 업데이트에 사용하는 다른 방법이 있습니까? 나는 모든 곳을 수색했지만 설명을 찾지 못했습니다.

여기서 찾고있는 시스템을 "WP Cron"이라고합니다. WordPress의 백그라운드 프로세스 시스템으로 이벤트가 일반 처리 외부에서 발생할 수 있습니다. 여전히 시작하기 위해 트리거가 필요하지만 백그라운드 프로세스로 인해 페이지로드를 방해하지 않습니다.

예, 누군가 페이지를로드해야합니다. default-filters.php 파일에서 다음 코드 행을 찾을 수 있습니다.

add_action( 'init', 'wp_cron' );

따라서 모든 페이지로드시 wp_cron 함수가 실행됩니다. 이 함수는 wp-includes / cron.php에서 끝났으며 데이터베이스에서 예약 된 이벤트를 확인하는 것입니다. 백그라운드에서 실행해야하는 프로세스가 있으면 spawn_cron 함수를 호출합니다.

스폰 크론에는 두 가지 가능한 작동 방법이 있지만 가장 일반적이고 가장 흔한 방법은 wp_remote_post 함수를 호출하여 wp-cron.php의 URL에서 다시 연결하는 것입니다. 이 추가 HTTP 요청을 작성하면 실제 작업을 모두 수행하기 위해 다른 PHP 프로세스를 시작합니다. 여기에서 요청은 0.01 초의 시간 초과로 비 차단입니다. 따라서 실제로 결과를 얻지 못합니다. 요청의 목적은 단순히 백그라운드에서 새로운 프로세스를 시작하는 것입니다. 이 작업이 끝나면 단순히 반환되므로 시청하는 사용자는 지연이 없습니다.

wp-cron.php 프로세스는 실제 작업, 업데이트 및 기타 모든 작업을 수행합니다. 워드 프레스의 많은 프로세스는 크론 시스템에 의해 처리됩니다. 예약 된 게시 후 처리, 핑 처리, 업데이트 확인, 정상 흐름 외부에서 발생해야하는 모든 작업을 예약 한 다음 필요에 따라 실행할 수 있습니다.

그러나 예, 사이트에 대한 정상적인 타격은 실제로 프로세스를 시작해야합니다. WordPress.org는 사이트에 직접 연락하지 않고 사이트를 시작하기 때문에 어떤 형태의 트래픽을 수신해야합니다. 모든 형태의 트래픽이 가능합니다.


17

실제로 자동 업데이트는에서 푸시되었습니다 wp.org. 업데이트 프로세스는 여전히 사이트에서 실행되지만을 통해 백그라운드에서 실행됩니다 wp-cron.

새로운 부 업데이트가 릴리스되면 WordPress의 사람들이 업데이트를 시작합니다. 실제 업데이트 프로세스는 사이트 wp.org에서 업데이트를 확인한 후 시작 되며 이론적으로 업데이트가 제공되며 업데이트 할 사이트가 무작위로 선택됩니다.


(나의 잘못된 말을 지적 해 주셔서 감사합니다 :)


모든 사이트 wp.org에서 새 버전을 확인하면 (일반적으로을 사용하여 하루에 두 번 wp-cron) 롤아웃 서버는 업데이트가 필요한 사이트 수를 알고 있습니다.

그런 다음 롤아웃이 시작되고 천천히 시작합니다. 128 개 사이트 중 1 개가 자동으로 업데이트됩니다. 이를 모니터링하고 있으며 성공률이 롤아웃에 아무런 문제가 없음을 나타내는 경우 모든 자동 업데이트가 제공 될 때까지 더 많은 사이트가 자동 업데이트를받습니다 (보통 다음 단계는 64 개 중 1 개이며 계속 증가합니다).

문제가 발생하면이 롤아웃을 중지 개발자 수 있지만에서 마지막 업데이트 3.8로는 3.8.1100 % 성공률을했다.

에서 선택한 사이트 1 out of 128는 실제로 임의입니다. 글쎄, 실제로는 아니지만 알고 싶다면 다음과 같이 작동합니다.

업데이트가 필요한 사이트의 URL은을 사용하여 해시됩니다 MD5. 이 해시의 처음 세 문자 만 사용하여로 변환하면 base104096 개의 가능성이 발생합니다. 계산 된 숫자가 0에서 31 사이 인 사이트에 대한 업데이트가 시작되었습니다 (4096/32 = 128).

좋아, 나는 그것이 결국 무작위라고 생각한다.)

필자의 경우 많은 WordPress 사이트를 운영함에 따라 업데이트가 하루가 걸렸습니다.

궁금한 경우를 대비하여 : D

btw, 여기 에 프로세스가 발생했을 때이를 설명하는 make.wordpress.org에 관한 기사가 있습니다.


"wp.org에서 귀하의 사이트로의 요청에 의해 시작된"경우 어떻게 안전합니까? 아무도 귀하의 사이트에 요청을 보낼 수 없습니까?
DisgruntledGoat

실제로, 이것이 기술적으로 어떻게 처리되는지 모르겠습니다. 그러나 nonce와 같은 보안 검사가 있거나 요청이 어디에서 왔는지 확신합니다.
fischi

1
@fischi wp.org가 업데이트를 시작하는 정보를 얻었습니까? wp.org에서 업데이트 시작 또는 wordpress 사이트에서 업데이트 확인 후 업데이트가 있음을 알리는 경우 업데이트 자체 시작 사이에는 큰 차이가 있습니다.
kraftner

1
이 답변은 실제로 잘못되었습니다. 업데이트 프로세스는 WordPress.org에서 귀하의 사이트로 시작되지 않습니다. 실제로 사이트를 시작하려면 특정 형태의 트래픽이 있어야하지만 WordPress.org는 사이트를 직접 핑하지 않습니다.
오토

1
그러나 "wp.org에서 귀하의 사이트로의 요청에 의해 시작된 것"은 올바르지 않습니다. 귀하의 사이트는 업데이트 요청을하고 응답은 업데이트가 있는지 여부를 알려줍니다. 다른 방법은 아니지만 사이트에서 프로세스를 시작해야합니다.
오토

1

매우 광범위한 용어로, 사용자가 사이트를 방문 할 때 wordpress는 타이머 만료를 확인하고 만료가 감지되면 만료 된 이벤트와 관련된 작업을 "실행"하기 위해 다른 요청이 서버로 전송됩니다. 서버가 별도의 프로세스에서 실제 작업 (이 경우 업그레이드)을 실행하고 있기 때문에 사용자가 페이지로드가 눈에 띄게 지연되지 않는 이유입니다.

이것은 작동하지만 타이밍이 매우 정확하지 않습니다. 사이트의 트래픽이 많을수록 더 정확합니다.

더 나은 성능과 더 정확한 타이밍을 원하는 사람들은 내부 크론 "프로세스"워드 프레스의 기능을 차단하고 OS 크론 프로세스를 사용하여 타이머 확인을 트리거 할 수 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.