분류 php

비동기 PHP에 대한 오해 : 진정한 비동기가 아니다

컨텐츠 정보

  • 조회 126 (작성일 )

본문

최근에 저는 PHP의 성능에 대해 많은 논의를 했습니다. PHP 8, JIT 및 기타 모든 개선 사항이 있지만 사람들은 여전히 ​​PHP에 대해 불평합니다.


요청-응답 서클 만의 언어입니다. 그 PHP는 매우 느리며 고부하 시스템에서 사용할 수 없습니다. 한편으로는 사실입니다. 정말로 성능이 좋은 무언가를 만들고 싶다면 고전적인 차단 PHP는 올바른 선택이 아닙니다. 대부분의 PHP 함수와 라이브러리는 전통적인 차단 환경에서 작동하도록 만들어졌지만 사실은 성능에 관한 것이 아닙니다.

실망시키지 말고 다른 언어를 사용하여 성능에 민감한 작업을 해결하십시오. PHP는 빠를 수 있으며, 게다가 정말 빠를 수 있습니다. 어떻게?

성능에 영향을 미칠 수 있는 두 가지 이유는 복잡한 것을 계산할 때나 차단 I / O가있을 때입니다.

첫 번째는 PHP에서 해결할 수 없거나 해결할 수 있으며 50 개 이상의 중첩 된 GraphQL 리졸버를 해결하려는 경우 PHP가 (NodeJ와 마찬가지로) 최선의 선택이 아닐 수 있습니다.

차단 I / O의 두 번째 문제는 실제로 PHP의 문제가 아닙니다 (NodeJ와 마찬가지로).

커뮤니티는 수년 동안 비동기 PHP 코드를 작성해 왔습니다. 그리고 지난 몇 년 동안 PHP 커뮤니티의 일부가 비동기 도구를 계속 사용하고 작성하는 동안, 대부분의 PHP 개발자 (PHP뿐만 아니라)는 여전히 비동기 PHP를 "야생적인"것으로 간주합니다. “PHP로 비동기 코드를 작성한다면 정말 절망적 일 것입니다.”-나는 많이 들었습니다.

솔직히 말해서 PHP가 이런 종류의 도구에 적합한 도구가 아니라는 편견이 있습니다. 대부분의 경우 이러한 편향은 PHP와 "비동기"라는 단어에 대한 잘못된 가정을 기반으로 합니다. 잘못된 가정은 잘못된 기대로 이어지며, 이로 인해 비동기 PHP가 "진정한 비동기"가 아니라고 비난하게 됩니다.

이 기사에서는 몇 가지 일반적인 잘못된 가정에 대해 논의하고 비동기 PHP를 믿습니다. 비동기 PHP에 대해 논의하기 전에 기본 사항을 이해하는 것이 중요합니다. 여행을 시작하십시오!


동시성 및 병렬성 


먼저 동기 실행과 비동기 실행의 차이점을 이해해야 합니다. 우리가 같은 페이지에 있는지 확인하기 위해 빠르게 수정하겠습니다. 그런 다음 더 복잡한 주제로 넘어갈 것입니다. 두 개의 네트워크 요청을 하는 프로그램을 고려하십시오. 전통적인 동기식 접근 방식에서는 코드가 순차적으로 실행됩니다.

  • 첫 번째 요청을 보내다
  • 응답을 받을 때까지 기다리십시오
  • 두 번째 요청 보내기
  • 두 번째 응답을 받을 때까지 기다립니다

여기서 각 작업은 흐름을 차단합니다. 대부분의 경우 이 방법은 괜찮습니다. 성능이 중요하지만 차단 작업이 많으면 문제가 발생합니다. 이 프로그램은 사용 가능한 모든 리소스를 활용하지 않으므로 대기하고 아무것도 하지 않는 데 많은 시간을 소비 할 수 있습니다. 네트워크 요청이 완료되기를 기다리는 동안 (I / O 바운드 작업) CPU는 유휴 상태로 유지됩니다. 그리고 무언가를 계산하는 동안 (CPU 바운드 작업) 프로그램이 "고정"되고 입력에 응답하지 않습니다.

sync-flow.png 

비동기식 접근 방식은 물건을 차단하는 솔루션을 제공합니다. 비동기 흐름은 한 번에 여러 작업을 실행하며 다음 작업으로 이동하기 전에 현재 작업이 완료 될 때까지 기다릴 필요가 없습니다. 비동기 작업은 비 차단이며 작업 만 시작합니다. 이전 예제 네트워크 요청을 계속하면 이제 동시에 실행됩니다. 또한 병렬로 실행되는 것처럼 보일 수 있습니다 (실제로는 그렇지 않습니다).


async-flow.png 

비동기 PHP에 대해 논쟁 할 때의 핵심 문제는 실제로 동시성이 무엇을 의미하는지에 대한 오해입니다. 종종 사람들은 비동기 실행과 병렬 실행을 혼동합니다. “PHP는 병렬로 작업을 실행할 수 없기 때문에 진정한 비동기식이 아닙니다.”-나는 여러 번 들었습니다. 주요 차이점은 동시성이 병렬 처리보다 훨씬 광범위하고 일반적인 문제라는 것입니다.


동시 실행에는 겹치는 기간에 시작, 실행 및 완료 할 수 있는 두 가지 작업이 있습니다. 동시에 실행된다는 의미는 아닙니다. 아주 좋은 예는 컴퓨터입니다. 단일 코어 CPU에서 두 개의 프로그램 (또는 하나의 멀티 스레드 프로그램)을 실행할 때 이러한 프로그램을 병렬로 실행할 방법이 없습니다. 단일 CPU 시간을 공유해야 합니다. 따라서 OS는 먼저 한 프로그램을 실행 한 다음 다른 프로그램을 실행하기로 결정합니다. 또는 한 프로그램의 작은 부분과 다른 프로그램의 작은 부분을 실행하기로 결정할 수도 있습니다. 두 번째 프로그램은 첫 번째 프로그램이 끝나기도 전에 시작할 수 있습니다.


반대로 병렬 처리는 두 작업이 문자 그대로 동시에 실행되는 경우입니다. 위와 같은 예제를 계속 진행한다면 멀티 코어 프로세서의 멀티 스레드 프로그램을 상상해보십시오. 병렬 실행에는 여러 처리 장치가 있는 하드웨어가 필요합니다. 단일 코어 CPU를 사용하면 동시성을 달성 할 수 있지만 병렬성은 달성 할 수 없습니다. 병렬 처리는 작업이 실제로 동시에 실행되는 특정 종류의 동시성입니다.


concurrent-vs-parallel.png 

앞서 언급 한 내용에서 응용 프로그램이 동시에 작동 할 수는 있지만 병렬이 될 수는 없습니다. 즉, 동시에 둘 이상의 작업을 처리하지만 두 작업이 동시에 실행되지 않습니다.


자, 이제 동시성과 병렬성의 차이는 분명하지만 PHP는 단일 스레드 프로그래밍 언어입니다. 단일 스레드라는 것은 한 번에 한 줄의 PHP 코드 만 실행할 수 있음을 의미합니다. 아하! PHP는 진정한 비동기식이 아닙니다! 하지만 실제로 코드를 비동기 적으로 실행하려면 여러 스레드가 필요합니까? 이러한 질문에 답하려면 다시 이론을 파헤쳐 스레드와 프로세스의 차이를 확인해야합니다.


스레드 및 프로세스 


우리는 프로그래머로서 나중에 컴퓨터에 의해 실행되는 코드를 작성합니다. C, Lisp 또는 PHP 중 어떤 언어를 사용하는지는 중요하지 않습니다. 하루가 끝나면 우리 코드는 바이너리 파일로 컴파일 되거나 해석됩니다. 이 바이너리 코드를 실행할 때 프로그램은 메모리 주소 공간, PID (프로세스 ID) 등을 실행하기 위해 OS의 리소스가 필요합니다. 실행 중인 동일한 프로그램의 여러 인스턴스가 있을 수 있으며 각 인스턴스는 OS 내에서 별도의 프로세스입니다. 한 프로세스에서 다른 프로세스로 전환하려면 CPU 레지스터, 메모리 및 기타 리소스를 저장하고 로드 하는 데 약간의 시간이 필요합니다. 모든 프로세스가 격리됩니다. 우리는 각 프로세스가 자신을 컴퓨터에서 실행되는 유일한 것으로 간주하고 현재 다른 프로그램이 실행되고 있지 않다고 말할 수 있습니다. 프로그램 중 하나가 "정지"되는 상황을 분명히 보았지만 다른 프로그램에 영향을 주지 않고 종료 할 수 있었습니다.


따라서 프로세스가 시작되고 자체 메모리와 리소스를 받습니다. 프로세스 내의 모든 스레드는 해당 메모리와 리소스를 공유합니다. 각 프로세스에는 기본 스레드로 알려진 하나 이상의 스레드가 있습니다. 기본 스레드가 실행을 완료하면 프로세스와 프로그램 자체가 종료됩니다. 프로세스를 컴파일 된 코드, 메모리 및 다양한 OS 리소스가 있는 컨테이너로 취급 할 수 있습니다.


thread-process.png 


단일 스레드 동시성 


프로세스 (멀티 스레드 프로세스) 내에 여러 스레드가 있으면 한 번에 여러 작업을 처리 할 수 ​​있습니다. 또한 대부분의 경우 여러 프로세스 또는 스레드가 병렬로 실행될 수 있는 여러 프로세서 또는 CPU 코어가 있는 시스템이 있습니다. 이를 통해 프로그램에서 동시성을 구현할 수 있습니다.


그러나 동시성이 멀티 스레딩을 의미하지는 않는다는 것을 이해하는 것이 중요합니다. 많은 경우 (실제로 대부분의 경우) 단일 스레드 동시성이 갈 길입니다. 스레드의 이러한 모든 이점으로 인해 다중 스레드 프로그램은 스레드로 인해 과부하가 걸리는 괴물이 될 수 있습니다. 예, 스레드 간의 통신 비용은 낮지 만 프로세스 내에서 한 스레드의 문제가 다른 스레드와 프로세스 자체에 영향을 미친다는 단점이 있습니다 (동기화 및 교착 상태에 대해 "안녕"이라고 말하십시오).


응용 프로그램 성능은 사용 가능한 리소스 (CPU, 메모리 등)를 얼마나 최적으로 사용하는지에 따라 달라집니다. 프로그램의 일부 작업은 완료하는 데 상당한 시간이 걸리며 이 기간 동안 다른 작업을 수행 할 수 있기를 원합니다. 동시성이 필요한 곳입니다. 작업에 시간이 많이 걸리는 두 가지 주요 이유를 살펴 보겠습니다.


  • CPU 바운드 작업에는 많은 계산이 포함됩니다. 실제로 CPU 시간이 필요합니다.
  • I / O 바인딩 작업은 네트워크 / 하드웨어 / 사용자 상호 작용 등에 따라 다릅니다. 그들은 시간이 필요합니다. 어떤 일이 일어나기를 기다려야 하기 때문입니다.

CPU 바운드 차단을 사용하면 스레드가 능동적으로 실행되기 때문에 차단됩니다. 예를 들어, 무언가를 계산하거나 3D 모델을 렌더링 할 때. CPU 바운드 작업의 경우 멀티 스레딩이 선호됩니다. 멀티 프로세서 시스템에서는 실제로 여러 스레드가 동시에 실행될 수 있기 때문입니다. 이렇게 하면 전반적인 성능이 향상됩니다.


그러나 I / O 바운드 작업에서는 일부 I / O 소스 (네트워크, 하드 드라이브 등)에서 데이터가 반환 될 때까지 기다려야 하기 때문에 스레드가 차단됩니다. OS는 현재 사용 가능한 데이터가 없음을 확인하여 스레드를 절전 상태로 만듭니다. 이 경우 스레드는 적극적으로 실행되지 않습니다. 사실은 아무것도 하지 않지만 기다립니다. 여기서 멀티 스레딩은 쓸모가 없습니다. 일부 조건 (네트워크 응답 또는 파일 시스템)이 발생할 때까지 대기하는 여러 스레드를 생성하는 것은 이러한 조건이 더 빨리 발생하는 데 도움이 되지 않습니다. 실제로 단일 스레드는 지정된 조건이 발생할 때까지 기다렸다가 이에 필요한 작업을 수행 할 수 있습니다.


이제 PHP에 대해 이야기하겠습니다. 대부분의 경우 웹 애플리케이션을위한 언어로, 많은 I / O를 처리합니다. 파일 시스템에 무언가를 쓰거나 네트워크 요청을 하거나 콘솔을 처리합니다. 이를 염두에 두고 단일 스레드 PHP는 동시성을 구현하기 위한 제한이 아니라 기회라는 점을 고려해야 합니다.


Non-blocking I/O 


단일 스레드가 있다고 해서 프로그램이 비 동기화 되는 것은 아닙니다. 더욱이 PHP의 I / O에 대해 이야기 할 때 PHP는 동기와 차단을 목적으로 만들어진 것 같습니다. I / O 작업을 처리하는 모든 기본 기능은 전체 애플리케이션을 차단합니다.


  • fopen ()으로 파일을 읽었습니까? 신청을 기다리고 있습니다.
  • PDO로 데이터베이스를 쿼리합니까? 응용 프로그램이 중단됩니다.
  • file_get_contents ()로 무언가를 읽고 싶습니까? 아, 당신은 답을 알고 있습니다.

차단이 항상 나쁜 것은 아닙니다. PHP에서는 애플리케이션의 I / O가 차단되는지 여부를 종종 생각하지 않습니다. 사실, PHP 애플리케이션에서 비 차단 I / O를 갖는 것은 매우 드문 일입니다. 특히 우리가 일반적으로 수행하는 I / O 유형 (HTTP 요청, 데이터베이스 쿼리 등)에 관해서는 더욱 그렇습니다. 요청-응답 모델에서는 작업이 완료되고 결과가 있을 때를 알 수 있는 유일한 방법이기 때문에 차단할 항목이 필요합니다.

예를 들어, 요청을 받고, 데이터베이스를 쿼리하고, 어떻게 든 결과를 처리하고, HTML 또는 JSON을 렌더링하고, 응답으로 클라이언트에 다시 반환합니다. 여기에는 차단하지 않는 물건을 위한 공간이 없습니다. 이 모든 단계에서 우리는 기다려야 합니다. 계속하려면 이전 작업의 결과가 필요합니다. 비 블로킹 I / O는 잠재적으로 수천 개의 병렬 클라이언트 요청을 처리 할 때 서버 측 코드에서 훨씬 더 유용합니다. 예, 물론 PHP는 서버 측 코드이지만 그 앞에 항상 Nginx 또는 Apache가 있습니다. 그리고 이러한 도구를 사용하면 차단 동기식 PHP 코드를 작성할 수 있습니다. 기존 PHP에서는 항상 단일 HTTP 요청을 처리하며 실제로 코드가 차단되는지 여부는 신경 쓰지 않습니다.


하지만 순수 PHP에서 HTTP 서버를 구현하려면 어떻게 해야 할까요? 아니면 소켓 서버? 수천 개의 동시 요청을 처리 할 수 있는 서비스를 PHP로 구현하려고 하면 어떨까요? 즉, 비동기 코드를 작성할 수 있다는 것은 이전에 PHP에서 사용할 수 없었던 수많은 애플리케이션을 만들 수 있는 기회를 제공합니다.


예, "PHP는 이를 위해 설계되지 않았습니다"라는 일반적인 대답을 이미 알고 있습니다. 하지만 내가 할 수 있다고 말하면 어떨까요? 그것을 위한 도구가 있습니다. 단일 스레드 PHP 코드를 동시에 실행하기 위해 추가 확장을 설치할 필요도 없습니다.

choice.jpeg 


어떻게? I / O를 처리하기 위해 네이티브 PHP 함수 (예 : file_get_contents ())를 차단하는 대신 PHP에서 비 차단 I / O를 구현하기 위한 높은 수준의 추상화를 제공하는 라이브러리 (ReactPHP 및 Amp)를 사용할 수 있습니다. 비동기식 비 차단 I / O를 사용하면 많은 스레드가 필요하지 않습니다. 운영 체제는 I / O 코드를 병렬로 실행합니다.

코드가 비 차단 API를 호출 할 때이 API가 응답 할 때까지 기다리지 않습니다. PHP 스레드는 이 I / O 호출 이후에 나오는 코드를 즉시 계속 실행할 수 있습니다. OS가 준비되고 데이터를 PHP로 다시 보낼 때가 되면 알림을 받게 됩니다. 이상하게 들린다는 것을 알고 있습니다. 특히 전통적인 요청-응답 모델을 염두에 두십시오. 비 차단 / 비동기 API 소비자는 어떻게 알림을 받습니까? 일종의 신호입니까?

아니면 데이터가 준비되었는지 여부를 지속적으로 확인하는 메커니즘이 있습니까? 명령을 순차적으로 실행하는 CPU에 대해 생각할 때 데이터가 준비되면 프로그램이 이벤트를 수신 할 수 있는 방법이 있습니까? 이는 일반적으로 결과 데이터에 대한 액세스 권한이 있는 콜백으로 수행됩니다. 우리가 작업하는 대부분의 운영 체제 (Linux, Mac OS, Windows)에는 비동기 핸들러가 있습니다. 물론 프라미스, 코 루틴 등으로 non-blocking 액션을 표현하는 다른 많은 방법이 있습니다.

그러나 내부적으로는 모두 I / O를 위해 데이터가 반환 되면 호출되는 루틴 (함수)을 기반으로 합니다. OS에는 많은 스레드가 있으므로 다른 시스템 리소스에 액세스하는 데 도움이 됩니다. OS는 파일 시스템에 액세스하거나 다른 스레드에서 네트워크 호출을 할 수 있습니다. 따라서 PHP 프로그램은 I / O 바인딩 된 작업 만 OS에 위임 한 다음 콜백에서 받은 결과에 대해 작동합니다.


문제는 전통적인 "순차적"PHP 스크립트가 이러한 콜백을 처리 할 수 ​​없다는 것입니다. 예를 들어, PHP에서 두 개의 동시 HTTP 요청을 만들고 싶습니다.


$client = new Browser();

$result1 = $client->get('http://google.com/');
$result2 = $client->get('https://github.com/reactphp');


두 개의 동시 요청을 작성하려는 이 코드를 상상해보십시오. HTTP 요청은 I / O 바운드 작업을 나타내므로 이 코드를 비동기 적으로 실행하면 OS에 위임되어야 합니다. 첫 번째 요청을 시작하고 완료 될 때까지 기다리지 않고 즉시 두 번째 요청을 시작합니다. OS가 이러한 요청을 완료하면 스크립트에 알림이 전송됩니다. 하지만… 여기서 문제가 보이십니까? 단일 스레드 PHP는 한 줄씩 실행됩니다. 요청이 완료되면 스크립트가 종료 될 가능성이 높습니다. 더 이상 할 일이 없습니다. 여기서도 응답을 기다리지 않고 네트워크 요청 만 시작합니다. 응답을 처리하려면 두 가지가 필요합니다.


  • I / O 이벤트를 청취 할 수 있는 기회입니다.
  • I / O 작업이 백그라운드에서 실행 중인 경우 스크립트를 종료하지 않습니다.


두 문제 모두 이벤트 루프로 해결할 수 있습니다. 이전 예제는 다음과 같은 방법으로 다시 작성할 수 있습니다.


use React\Http\Browser;
use Psr\Http\Message\ResponseInterface;

$loop = React\EventLoop\Factory::create();
$client = new Browser($loop);

$result1 = $client->get('http://google.com/');
$result2 = $client->get('https://github.com/reactphp');

$loop->run();


새로운 객체 인 이벤트 루프의 인스턴스를 도입했습니다. ReactPHP 루프 구현을 사용했습니다. 스크립트 시작 부분에서 루프를 만들고 스크립트 끝 부분에서 실행 ()합니다. 이것이 이 PHP 코드를 비동기 적으로 만드는 것입니다. 마지막 줄에서 프로그램은 종료되지 않고 이벤트 수신을 시작합니다. 두 개의 동시 네트워크 요청을 만들었으므로 응답을 기다려야 합니다. 또한이 명령은 실제로 네트워크 요청을 보내지 않습니다.


$result1 = $client->get('http://google.com/');


요청을 보내려는 의도 만 설명합니다. 루프가 실행되기 시작할 때만 요청이 전송됩니다. 잠깐 ... 요청이 전송되지 않으면 ... $ result1 및 $ result2 내에 어떤 값이 있습니까? 둘 다 null로 설정되어 있습니까? 비동기식 (ReactPHP) 세계에서 지금은 사용할 수 없는 값이 필요할 때 약속을 처리합니다. 미래 가치를 위한 자리 표시 자로 promise를 고려하십시오. 기본 약속은 네트워크 요청이 완료되면 수신 된 응답으로 해결됩니다.


$printResponse = fn (ResponseInterface $response) => var_dump((string)$response->getBody());

$promise1 = $client->get('http://google.com/');
$promise2 = $client->get('https://github.com/reactphp');

$promise1->then($printResponse);
$promise2->then($printResponse);


이러한 약속에 핸들러를 추가하고 사용 가능한 즉시 응답을 인쇄 할 수 있습니다. 뒤에서 어떻게 작동합니까? 내부의 이벤트 루프는 특정 이벤트를 수신하고 해당 이벤트에 대한 핸들러를 호출하는 "무한"루프입니다. 두 개의 I / O 비 차단 작업을 시작하고 OS에 이러한 네트워크 요청을 수행하도록 지시합니다. 그게 다야. 그러면 실행 흐름이 다른 작업을 수행 할 수 있습니다. 이러한 작업을 시작했으며 완료 될 때까지 기다리지 않습니다. OS가 네트워크 응답을 수신하면 수신 된 데이터와 함께 이벤트를 보냅니다. 이 이벤트의 레코드가 이벤트 큐에 추가됩니다. 실행 스레드는 대기열에서 첫 번째 이벤트를 가져와 이 이벤트에 해당하는 처리기를 호출합니다. 우리의 경우 두 작업에 동일한 핸들러를 추가했습니다. 응답 본문을 인쇄합니다.


event-loop.png 



결론 


이 모든 것 : 단일 스레드 PHP, 이벤트 기반 아키텍처의 비 차단 I / O는 PHP를 비동기식으로 쉽게 만들 수 있습니다. 예, 현재 언어에 대한 기본 고급 지원은 없지만 우리를 도울 수있는 라이브러리가 있습니다. 또한 PHP는 추가 확장없이 바로 비동기식으로 사용할 수 있습니다. 현재 주요 문제는 높은 수준의 추상화 및 I / O 기능에 대한 기본 지원이 부족하다는 것입니다. 우리는 수년 동안 요청-응답 모델에 살고 있습니다. 따라서 우리가 보유한 대부분의 라이브러리는 차단 환경에서 작동하도록 되어 있습니다. 그러나 우리는 또한 언어가 매우 빠르게 진화하는 것을 볼 수 있습니다. 곧 PHP에서 비동기 코드의 기본 지원을 위한 첫 번째 단계를 보게 될 가능성이 높습니다 (파이버에 "안녕하세요").


이 기사의 목적은 PHP로 무엇이든 작성할 수 있다고 말하는 것이 아닙니다. 물론 은색 총알이 없으며 다른 작업에는 다른 도구가 필요합니다. 개발자는 PHP가 작업에 적합한 지 또는 다른 언어가 필요한지 결정하는 것은 사용자에게 달려 있습니다. 비동기 PHP가 작동하는 방식을 설명하고 싶었습니다. 내부에는 마법이 없으며 비동기 PHP는 실제로 비동기입니다. 코드를 동시에 실행하기 위해 여러 스레드가 필요하지 않습니다. 더욱이, PHP가 단일 스레드라는 것에 대해 이야기하고 있다면 여기서 장점이 아니라 제한이 아닙니다.