Ускоряване на PHP конекторите за Tarantool с Async, Swoole и Parallel

В екосистемата на PHP в момента съществуват два конектора за работа с Tarantool сървър — това е официалното PECL разширение tarantool/tarantool-php, написано на C, и tarantool-php/client, написан на PHP. Аз съм авторът на последния.

В тази статия бих искал да споделя резултатите от тестовете за производителност на двете библиотеки и да покажа как с минимални изменения в кода може да се постигне 3-5% увеличение на производителността (при синтетичните тестове!).

Какво ще тестваме?

Ще тестваме споменатите по-горе синхронни конектори, пуснати асинхронно, паралелно и асинхронно-паралелно. 🙂 Също така не искаме да засягаме кода на самите конектори. В момента има няколко разширения, които могат да постигнат желаното:

• Swoole — високо производителен асинхронен фреймуърк за PHP. Използва се от интернет гиганти като Alibaba и Baidu. С версия 4.1.0 се появи магическият метод SwooleRuntime::enableCoroutine(), който позволява с една линия код да преобразува синхронните мрежови библиотеки на PHP в асинхронни.
• Async — до неотдавна доста перспективно разширение за асинхронна работа в PHP. Защо до неотдавна? За съжаление, по неизвестни за мен причини, авторът премахна репозитория и бъдещето на проекта е неясно. Ще се наложи да се възползваме от един от форковете. Както Swoole, това разширение позволява с лека ръка да превърнете стандартната реализация на TCP и TLS потоките с асинхронни версии. Това се прави чрез опцията „async.tcp = 1«.
• Parallel — доста ново разширение от известния Joe Watkins, автора на библиотеки като phpdbg, apcu, pthreads, pcov, uopz. Разширението предоставя API за многопоточна работа в PHP и се позиционира като заместител на pthreads. Значително ограничение на библиотеката е, че тя работи само с ZTS (Zend Thread Safe) версия на PHP.

Как ще тестваме?

Ще стартираме инстанция на Tarantool с изключен журнал на предварителните записи (wal_mode = none) и увеличен мрежов буфер (readahead = 1 * 1024 * 1024). Първата опция ще изключи работа с диска, а втората ще позволи да се прочетат повече заявки от буфера на операционната система, минимизирайки по този начин количеството на системните повиквания.

За бенчмарковете, които работят с данни (вмъкване, изтриване, четене и т.н.) преди старта на бенчмарка ще се (пре)създаде memtx-пространство, в което стойностите на първичния индекс се генерират от генератор на подредени стойности на цели числа (sequence).
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е_"}

Достъпът до кортежите се осъществява случайно по стойността на ключа.

Самият бенчмарк представлява единен запрос до сървъра, който се изпълнява 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
Docker: 19.03.3, build a872fc2f86
PHP: 7.3.11 (cli) (изградена: 22 Окт 2019 08:11:04)
tarantool/client: 0.6.0
rybakit/msgpack: 0.6.1
ext-tarantool: 0.3.2 (+ патч за 7.3)*
ext-msgpack: 2.0.3
ext-async: 0.3.0-8c1da46
ext-swoole: 4.4.12
ext-parallel: 1.1.3

* За съжаление, официалният конектор не работи с версия на PHP > 7.2. За да компилирам и стартирам разширението на PHP 7.3, трябваше да използвам патч.

Резултати

Синхронен режим

Протоколът на Tarantool използва бинарен формат MessagePack за сериализация на съобщения. В конектора PECL сериализацията е дълбоко скрита в недрата на библиотеката и влиянието върху процеса на кодиране от userland-код не е възможно. Конектор на чист PHP, от друга, предлагая възможност за персонализиране на процеса на кодиране чрез разширяване на стандартния кодер или с възможността да се използва собствена реализация. Предоставят се два кодера от кутията, един основан на msgpack/msgpack-php (официалното разширение MessagePack PECL), а другият — на rybakit/msgpack (на чист PHP).

Преди да сравним конекторите, ще измерим производителността на кодерите на MessagePack за PHP-конектора и в по-нататъшните тестове ще използваме този, който покаже най-добър резултат:

Въпреки че PHP версията (Pure) отстъпва на PECL разширението по скорост, в реални проекти все пак бих препоръчал да се използва именно rybakit/msgpack, тъй като в официалното разширение MessagePack спецификацията на формата е реализирана само частично (например, няма поддръжка за потребителски типове данни, без която не можете да използвате Decimal — нов тип данни, представен в Tarantool 2.3) и има редица други проблеми (включително проблеми със съвместимостта с PHP 7.4). И в общи линии проектът изглежда забравен.

И така, ще измерим производителността на конекторите в синхронен режим:

Както се вижда от графика, конекторът PECL (Tarantool) показва по-добра производителност в сравнение с конектора на PHP (Client). Но това не е изненадващо, имайки предвид, че последният, освен че е реализиран на по-бавен език, всъщност извършва повече работа: при всяко извикване се създава нов обект Request и Response (в случай на Select — още и Criteria, а в случай на Update/Upsert — Operations), отделни единици Connection, Packer и Handler също добавят оверхед. Очевидно е, че за гъвкавостта трябва да се плаща. Въпреки това, като цяло PHP интерпретаторът показва добра производителност, макар и разликата да съществува, но тя не е значителна и, може би, ще бъде още по-малка при използване на preloading в PHP 7.4, да не говорим за JIT в PHP 8.

Продължаваме напред. В Tarantool 2.0 беше добавена поддръжка за SQL. Нека опитаме да извършим операции Select, Insert, Update и Delete, използвайки SQL протокола и да сравним резултатите с noSQL (бинарни) еквиваленти:

Резултатите от SQL не впечатляват много (напомням, че все още тестваме синхронния режим). Въпреки това, не бих се разочаровал преждевременно, поддръжката на SQL все още е в активна разработка (относително скоро, например, беше добавена поддръжка за prepared statements) и, съдя по списъка issues, SQL двигателят очаква редица оптимизации в бъдеще.

Асинхронен

Сега нека видим как разширението Async може да ни помогне да подобрим резултатите по-горе. За писането на асинхронни програми разширението предоставя API на базата на корутини (coroutines), и ние ще ги използваме. Опитвайки се, установяваме, че оптималното количество корутини за нашата среда е 25:

„Разпределяме“ 10,000 операции между 25 корутини и виждаме какво се получи:

Количество операции в секунда се увеличи повече от 3 пъти за tarantool-php/client!

Тъжно, но конекторът PECL не стартира с ext-async.

А какво с SQL?

Както виждате, в асинхронен режим разликата между бинарния протокол и SQL стана в пределите на грешката.

Swoole

Отново установяваме оптималното количество корутини, сега за Swoole:

Ще се спрем на 25. Повтаряме същия трик, както с разширението Async ― разпределяме 10,000 операции между 25 корутини. Освен това, добавяме още един тест, в който разделяме цялата работа на 2 процеса (тоест, всеки процес ще изпълнява 5,000 операции в 25 корутини). Процесите ще бъдат създадени с помощта на SwooleProcess.

Резултати:

Swole показва малко по-нисък резултат в сравнение с Async при стартиране в един процес, но с 2 процеса картината се променя коренно (числото 2 не е избрано случайно; на моята машина именно 2 процеса показаха най-добри резултати).

Между другото, в разширението Async също има API за работа с процеси, но там не забелязах някаква разлика при стартиране на бенчмаркове в един или повече процеси (не е изключено, че аз някъде сбърках).

SQL срещу бинарния протокол:

Както и с Async, разликата между бинарни и SQL операции се неутрализира в асинхронен режим.

Parallel

Тъй като разширението Parallel не е за корутини, а за потоци, измерваме оптималното количество паралелни потоци:

То е равно на 16 на моята машина. Стартираме бенчмаркове на конекторите на 16 паралелни потока:

Както виждате, резултатът е дори по-добър отколкото с асинхронните разширения (с изключение на Swoole, стартирано на 2 процеса). Обърнете внимание, че за конектора PECL на мястото на Update и Upsert операции е празно. Това е свързано с факта, че данните операции излязоха с грешка ― не знам, по вина на ext-parallel, ext-tarantool или и двете.

Сега сравняваме производителността на SQL:

Забелязахте ли подобие с графика за конекторите, стартирани синхронно?

Всичко заедно

Накрая ще обединим всички резултати в един график, за да видим общата картина за тестваните разширения. Ще добавим към графика само един нов тест, който не сме провеждали – ще стартираме корутините Async паралелно с помощта на Parallel*. Идеята за интеграцията на споменатите разширения вече е обсъждана от авторите, но консенсус все още не е постигнат, ще трябва да го направим сами.

* Не успяхме да стартираме корутините Swoole с Parallel, изглежда тези разширения са несъвместими.

И така, финалните резултати:

Вместо заключение

Според мен резултатите са доста впечатляващи и по някаква причина съм уверен, че това не е пределът! Решението дали да го използвате в реален проект е изцяло ваше, само ще кажа, че за мен това беше интересен експеримент, който позволява да оценя колко можем да "изстискаме" от синхронния TCP конектор с минимални усилия. Ако имате идеи за подобрение на бенчмарковете – с радост ще разгледам вашия пул реквест. Целият код с инструкции за стартиране и резултати е публикуван в отделен репозитории.

Източник: habr.com