Ускоряваме 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 пространство, в което стойностите на първичния индекс се създават от генератора на последователни стойности от цели числа (последователност).
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 пъти (реvolucii), които от своя страна се изпълняват в итерации. Итерациите се повтарят, докато всички отклонения във времето между 5 итерации не останат в допустимата граница на грешка от 3 %*. След това се взима средният резултат. Между итерациите има пауза от 1 секунда, за да не се позволи на процесора да влезе в throttling. Garbage collector на Lua се деактивира преди всяка итерация и се стартира принудително след нейното завършване. PHP процесът се стартира само с необходимите разширения за бенчмарка, с активирано буфериране на изхода и деактивиран garbage collector.

* Броят на реvolucii, итерации и праг на грешка може да се промени в настройките на бенчмарка.

Тестова среда

Опубликованите по-долу резултати бяха получени на 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 и Отговор (в случай на 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, базирано на корутини, които и ще използваме. Опитно установяваме, че оптималното количество корутини за нашата среда е 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.

Резултати:

Swoole показва малко по-нисък резултат в сравнение с 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