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

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

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

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

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

• Swoole ― високоефективна асинхронна рамка за PHP. Използва се от такива интернет гиганти като Alibaba и Baidu. От версия 4.1.0 се появи магически метод SwooleRuntime::enableCoroutine(), което ви позволява да „конвертирате синхронни PHP мрежови библиотеки в асинхронни с един ред код“.
• Async доскоро беше много обещаващо разширение за асинхронна работа в PHP. Защо доскоро? За съжаление по неизвестна за мен причина авторът изтри хранилището и бъдещата съдба на проекта е неясна. Ще трябва да го използвам един от вилици. Подобно на Swoole, това разширение ви позволява лесно да включите панталоните си с едно движение на китката, за да активирате асинхронност, като замените стандартната реализация на TCP и TLS потоци с техните асинхронни версии. Това става чрез опцията „async.tcp = 1".
• Паралелно ― сравнително ново разширение от добре познатия Джо Уоткинс, автор на библиотеки като phpdbg, apcu, pthreads, pcov, uopz. Разширението предоставя API за многопоточност в PHP и е позиционирано като заместител на pthreads. Значително ограничение на библиотеката е, че тя работи само с ZTS (Zend Thread Safe) версия на PHP.

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

Нека стартираме екземпляр на 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 XNUMX кортежа от формата

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

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

Самият бенчмарк е една заявка към сървъра, която се изпълнява 10,000 5 пъти (обороти), които от своя страна се изпълняват на итерации. Итерациите се повтарят, докато всички времеви отклонения между 3 итерации са в рамките на приемлива грешка от 1%*. След това се взема средният резултат. Има пауза от XNUMX секунда между итерациите, за да се предотврати дроселиране на процесора. Събирачът на боклук на Lua се дезактивира преди всяка итерация и се принуждава да стартира, след като завърши. PHP процесът се стартира само с разширенията, необходими за бенчмарка, с активирано буфериране на изхода и дезактивиран събирач на отпадъци.

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

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

Публикуваните по-долу резултати са направени на MacBookPro (2015), операционна система - Fedora 30 (версия на ядрото 5.3.8-200.fc30.x86_64). Tarantool беше стартиран в докер с параметъра "--network host".

Версии на пакета:

Tarantool: 2.3.0-115-g5ba5ed37e
Docker: 19.03.3, компилация a872fc2f86
PHP: 7.3.11 (cli) (създаден: 22 октомври 2019 г. 08:11:04)
tarantool/клиент: 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
външен паралел: 1.1.3

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

резултати

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

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

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

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

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

Както може да се види от графиката, PECL конекторът (Tarantool) показва по-добра производителност в сравнение с PHP конектора (клиент). Но това не е изненадващо, като се има предвид, че последният, освен че е имплементиран на по-бавен език, всъщност върши повече работа: с всяко извикване се създава нов обект Поискайте и Отговор (в случая на Select - също Критерии, а в случай на Update/Upsert ― Операции), отделни обекти Връзка, Опаковчик и треньор те също добавят режийни разходи. Очевидно гъвкавостта си има цена. Като цяло обаче интерпретаторът на PHP показва добра производителност, въпреки че има разлика, тя е незначителна и може би ще бъде дори по-малка при използване на предварително зареждане в PHP 7.4, да не говорим за JIT в PHP 8.

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

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

Асинхронизиране

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

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

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

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

Какво ще кажете за SQL?

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

Swoole

Отново откриваме оптималния брой корутини, този път за Swoole:

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

Резултати:

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

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

SQL срещу двоичен протокол:

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

Паралелно

Тъй като паралелното разширение не е свързано с съпрограми, а с нишки, нека измерим оптималния брой паралелни нишки:

На моята машина е 16. Нека изпълним бенчмаркове на конектори на 16 паралелни нишки:

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

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

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

Заедно

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

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

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

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

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

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