Async, Swoole 및 Parallel을 사용하여 Tarantool용 PHP 커넥터 가속화

PHP 생태계에는 현재 Tarantool 서버와 작업하기 위한 두 개의 커넥터가 있습니다. 이는 공식 PECL 확장입니다. 타란툴/tarantool-php, C로 작성, tarantool-php/클라이언트, PHP로 작성되었습니다. 나는 후자의 저자이다.

이 기사에서는 두 라이브러리의 성능 테스트 결과를 공유하고 코드를 최소한으로 변경하여 3-5 성능 향상을 달성할 수 있는 방법을 보여주고 싶습니다(합성 테스트에!).

우리는 무엇을 테스트할 것인가?

위에서 언급한 것들을 테스트해 보겠습니다. 동기 비동기식, 병렬 및 비동기식 병렬로 실행되는 커넥터입니다. 🙂 또한 커넥터 자체의 코드를 건드리고 싶지 않습니다. 현재 원하는 것을 달성하는 데 사용할 수 있는 몇 가지 확장이 있습니다.

• 스울 ― PHP용 고성능 비동기 프레임워크입니다. Alibaba 및 Baidu와 같은 거대 인터넷 기업이 사용합니다. 버전 4.1.0부터 매직 메소드가 등장했습니다. SwooleRuntime::enableCoroutine(), 이를 통해 "한 줄의 코드로 동기식 PHP 네트워크 라이브러리를 비동기식으로 변환"할 수 있습니다.
• Async는 최근까지 PHP의 비동기 작업을 위한 매우 유망한 확장 기능이었습니다. 최근까지 왜? 안타깝게도 제가 알 수 없는 이유로 작성자가 저장소를 삭제했으며 프로젝트의 향후 운명은 불분명합니다. 꼭 써봐야겠어요 한 포크에서. Swoole과 마찬가지로 이 확장 기능을 사용하면 TCP 및 TLS 스트림의 표준 구현을 비동기 버전으로 대체하여 손목을 가볍게 움직여 바지를 쉽게 켤 수 있습니다. 이는 '옵션을 통해 수행됩니다.비동기.tcp = 1".
• 평행 ― phpdbg, apcu, pthreads, pcov, uopz와 같은 라이브러리의 저자이자 잘 알려진 Joe Watkins의 상당히 새로운 확장입니다. 이 확장은 PHP의 멀티스레딩을 위한 API를 제공하며 pthread를 대체하는 역할을 합니다. 라이브러리의 중요한 제한은 PHP의 ZTS(Zend Thread Safe) 버전에서만 작동한다는 것입니다.

어떻게 테스트할까요?

미리 쓰기 로깅이 비활성화된 Tarantool 인스턴스를 시작하겠습니다(wal_mode = 없음) 및 증가된 네트워크 버퍼(미리 읽기 = 1 * 1024 * 1024). 첫 번째 옵션은 디스크 작업을 제거하고, 두 번째 옵션은 운영 체제 버퍼에서 더 많은 요청을 읽을 수 있게 하여 시스템 호출 수를 최소화합니다.

데이터(삽입, 삭제, 읽기 등)로 작업하는 벤치마크의 경우 벤치마크를 시작하기 전에 memtx 공간이 (재)생성되며, 여기서 기본 인덱스 값은 정렬된 정수 값 생성기에 의해 생성됩니다. ​(순서).
공간 DDL은 다음과 같습니다.

space = box.schema.space.create(config.space_name, {id = config.space_id, temporary = true})
space:create_index('primary', {type = 'tree', parts = {1, 'unsigned'}, sequence = true})
space:format({{name = 'id', type = 'unsigned'}, {name = 'name', type = 'string', is_nullable = false}})

필요한 경우 벤치마크를 실행하기 전에 공간이 다음 형식의 10,000개 튜플로 채워집니다.

{id, "tuplе_<id>"}

튜플은 임의의 키 값을 사용하여 액세스됩니다.

벤치마크 자체는 서버에 대한 단일 요청으로, 10,000회(회전) 실행되어 반복적으로 실행됩니다. 5회 반복 사이의 모든 시간 편차가 허용 가능한 오류 3%* 내에 포함될 때까지 반복이 반복됩니다. 그 후 평균 결과가 취해집니다. 프로세서가 조절되는 것을 방지하기 위해 반복 사이에 1초의 일시 중지가 있습니다. Lua의 가비지 수집기는 각 반복 전에 비활성화되고 완료되면 강제로 시작됩니다. PHP 프로세스는 출력 버퍼링이 활성화되고 가비지 수집기가 비활성화된 상태에서 벤치마크에 필요한 확장으로만 시작됩니다.

* 회전수, 반복 및 오류 임계값은 벤치마크 설정에서 변경할 수 있습니다.

테스트 환경

아래 게시된 결과는 MacBookPro(2015), 운영 체제인 Fedora 30(커널 버전 5.3.8-200.fc30.x86_64)에서 수행되었습니다. Tarantool은 " 매개변수를 사용하여 docker에서 시작되었습니다.--network host".

패키지 버전:

Tarantool: 2.3.0-115-g5ba5ed37e
도커: 19.03.3, a872fc2f86 빌드
PHP: 7.3.11 (cli) (빌드 날짜: 22년 2019월 08일 11:04:XNUMX)
타란툴/클라이언트: 0.6.0
리바킷/msgpack: 0.6.1
ext-tarantool: 0.3.2(7.3용 + 패치)*
ext-msgpack: 2.0.3
확장 비동기: 0.3.0-8c1da46
외부 스울: 4.4.12
외부 병렬: 1.1.3

* 안타깝게도 공식 커넥터는 PHP 버전 > 7.2에서는 작동하지 않습니다. PHP 7.3에서 확장 기능을 컴파일하고 실행하려면 다음을 사용해야 했습니다. 반점.

조사 결과

동기 모드

Tarantool 프로토콜은 바이너리 형식을 사용합니다. 메시지팩 메시지를 직렬화합니다. PECL 커넥터에서 직렬화는 라이브러리 깊숙한 곳에 숨겨져 있으며 사용자 영역 코드의 인코딩 프로세스에 영향을 미칩니다. 불가능한. 반면 순수 PHP 커넥터는 표준 인코더를 확장하거나 자체 구현을 사용하여 인코딩 프로세스를 사용자 정의하는 기능을 제공합니다. 기본적으로 두 개의 인코더를 사용할 수 있으며, 그 중 하나는 다음을 기반으로 합니다. msgpack/msgpack-php (공식 MessagePack PECL 확장), 다른 하나는 켜져 있습니다. 리바킷/msgpack (순수한 PHP에서).

커넥터를 비교하기 전에 PHP 커넥터에 대한 MessagePack 인코더의 성능을 측정하고 추가 테스트에서는 최상의 결과를 보여주는 인코더를 사용할 것입니다.

PHP 버전(Pure)은 PECL 확장보다 속도가 떨어지지만 실제 프로젝트에서는 여전히 사용하는 것이 좋습니다. 리바킷/msgpack, 공식 MessagePack 확장에서는 형식 사양이 부분적으로만 구현되고(예를 들어 사용자 정의 데이터 유형에 대한 지원이 없으므로 Tarantool 2.3에 도입된 새로운 데이터 유형인 Decimal을 사용할 수 없습니다) 다른 사람의 수 проблем (PHP 7.4와의 호환성 문제 포함) 글쎄, 일반적으로 프로젝트는 포기된 것처럼 보입니다.

이제 동기 모드에서 커넥터의 성능을 측정해 보겠습니다.

그래프에서 볼 수 있듯이 PECL 커넥터(Tarantool)는 PHP 커넥터(클라이언트)에 비해 더 나은 성능을 보여줍니다. 그러나 후자가 느린 언어로 구현되는 것 외에도 실제로 더 많은 작업을 수행한다는 점을 고려하면 이는 놀라운 일이 아닙니다. 호출할 때마다 새 객체가 생성됩니다. 의뢰 и 응답 (Select의 경우 - 또한 기준, 그리고 업데이트/업서트의 경우 ― 행정부), 개별 엔터티 연결, 포장 기계 и 처리기 그들은 또한 오버헤드를 추가합니다. 분명히 유연성에는 대가가 따릅니다. 그러나 일반적으로 PHP 인터프리터는 좋은 성능을 보여 주지만 차이는 있지만 미미하며 PHP 7.4의 JIT는 말할 것도 없고 PHP 8에서 사전 로드를 사용하면 훨씬 더 낮아질 수도 있습니다.

계속 진행합시다. Tarantool 2.0에서는 SQL 지원이 도입되었습니다. SQL 프로토콜을 사용하여 선택, 삽입, 업데이트 및 삭제 작업을 수행하고 그 결과를 noSQL(바이너리)과 비교해 보겠습니다.

SQL 결과는 그리 인상적이지 않습니다(아직 동기 모드를 테스트하고 있음을 상기시켜 드리겠습니다). 그러나 미리 이에 대해 화를 내지는 않을 것입니다. SQL 지원은 아직 활발하게 개발 중입니다(비교적 최근에는 지원이 추가되었습니다). 준비된 진술) 그리고 목록으로 판단하면 문제, SQL 엔진은 향후 여러 가지 최적화를 거칠 예정입니다.

비동기

자, 이제 Async 확장이 위의 결과를 개선하는 데 어떻게 도움이 되는지 살펴보겠습니다. 비동기 프로그램을 작성하기 위해 확장 프로그램은 우리가 사용할 코루틴 기반 API를 제공합니다. 우리 환경에 대한 최적의 코루틴 수는 25개라는 것을 경험적으로 알아냈습니다.

10,000개의 코루틴에 25개의 작업을 "분산"하고 어떤 일이 일어나는지 확인하세요.

초당 작업 횟수가 3배 이상 증가했습니다. tarantool-php/클라이언트!

안타깝게도 PECL 커넥터는 ext-async로 시작되지 않았습니다.

SQL은 어떻습니까?

보시다시피 비동기 모드에서는 바이너리 프로토콜과 SQL의 차이가 오류 범위 내에 있게 되었습니다.

스울

이번에도 Swoole에 대한 최적의 코루틴 수를 알아냅니다.

25에서 멈추겠습니다. Async 확장과 동일한 트릭을 반복해 보겠습니다. 10,000개의 코루틴 간에 25개의 작업을 배포합니다. 또한 모든 작업을 2개의 프로세스로 나누는 또 다른 테스트를 추가할 것입니다(즉, 각 프로세스는 5,000개의 코루틴에서 25개의 작업을 수행합니다). 프로세스는 다음을 사용하여 생성됩니다. 스울프로세스.

결과 :

Swole은 하나의 프로세스에서 실행될 때 Async에 비해 약간 낮은 결과를 보여 주지만, 2개의 프로세스를 사용하면 그림이 크게 달라집니다(숫자 2는 우연히 선택된 것이 아닙니다. 제 컴퓨터에서는 2개의 프로세스가 가장 좋은 결과를 보여주었습니다).

그건 그렇고, Async 확장에는 프로세스 작업을 위한 API도 있지만 하나 이상의 프로세스에서 벤치마크를 실행하는 것과 어떤 차이도 발견하지 못했습니다(어딘가에서 실수를 했을 수도 있습니다).

SQL 대 바이너리 프로토콜:

비동기와 마찬가지로 비동기 모드에서는 바이너리 작업과 SQL 작업 간의 차이가 제거됩니다.

평행

병렬 확장은 코루틴이 아니라 스레드에 관한 것이므로 최적의 병렬 스레드 수를 측정해 보겠습니다.

내 컴퓨터에서는 16과 같습니다. 16개의 병렬 스레드에서 커넥터 벤치마크를 실행해 보겠습니다.

보시다시피 결과는 비동기식 확장보다 훨씬 좋습니다(2개 프로세스에서 실행되는 Swoole은 제외). PECL 커넥터의 경우 업데이트 및 Upsert 작업이 비어 있습니다. 이는 이러한 작업이 오류로 인해 실패했기 때문입니다. 이것이 ext-parallel, ext-tarantool 또는 둘 다의 잘못인지는 알 수 없습니다.

이제 SQL 성능을 비교해 보겠습니다.

동기식으로 실행되는 커넥터의 그래프와 유사점을 확인하십니까?

함께

마지막으로 모든 결과를 하나의 그래프로 요약하여 테스트한 확장 프로그램의 전체 그림을 살펴보겠습니다. 아직 수행하지 않은 새로운 테스트를 차트에 하나만 추가해 보겠습니다. Parallel*을 사용하여 비동기 코루틴을 병렬로 실행해 보겠습니다. 위의 확장 기능을 통합하려는 아이디어는 이미 논의 된 저자가 있지만 합의에 도달하지 못했으므로 직접 수행해야 합니다.

* Swoole 코루틴을 Parallel로 실행할 수 없었습니다. 이러한 확장 프로그램은 호환되지 않는 것 같습니다.

최종 결과는 다음과 같습니다.

대신 결론

제 생각에는 결과가 상당히 가치 있는 것으로 나타났으며 어떤 이유에서인지 이것이 한계가 아니라고 확신합니다! 실제 프로젝트에서 이것을 스스로 결정해야 하는지 여부에 관계없이 최소한의 노력으로 동기식 TCP 커넥터에서 얼마나 많은 것을 "압착"할 수 있는지 평가할 수 있는 흥미로운 실험이었다고만 말씀드리겠습니다. 벤치마크 개선을 위한 아이디어가 있으시면 귀하의 풀 요청을 기꺼이 고려해 드리겠습니다. 실행 지침 및 결과가 포함된 모든 코드는 별도의 문서로 게시됩니다. 저장소.

출처 : habr.com