Забрзување на PHP конектори за Tarantool користејќи Async, Swoole и Parallel

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

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

Што ќе тестираме?

Ќе ги тестираме споменатите погоре синхрони конектори кои работат асинхроно, паралелно и асинхроно-паралелно. 🙂 Исто така, не сакаме да го допираме кодот на самите конектори. Во моментов има неколку достапни екстензии за да го постигнете она што го сакате:

• Свул ― асинхрона рамка со високи перформанси за 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). Првата опција ќе ја елиминира работата со дискот, втората ќе овозможи да се читаат повеќе барања од баферот на оперативниот систем и со тоа да се минимизира бројот на системски повици.

За одредниците што работат со податоци (вметнување, бришење, читање, итн.), пред да започне реперот, ќе се (повторно)создаде мемткс простор, во кој вредностите на примарниот индекс се креирани од генератор на подредени цели броеви (секвенца).
Просторот 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 секунда помеѓу повторувањата за да се спречи пригушување на процесорот. Собирачот на ѓубре на Луа е оневозможен пред секое повторување и е принуден да започне откако ќе заврши. Процесот на PHP се стартува само со екстензии неопходни за репер, со овозможено баферирање на излезот и оневозможен собирач на ѓубре.

* Бројот на вртежи, повторувања и прагот на грешки може да се сменат во поставките за репер.

Тест средина

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

Верзии на пакетот:

Tarantool: 2.3.0-115-g5ba5ed37e
Докер: 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 (+ patch за 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 користи бинарен формат Пакет за пораки да се серијализираат пораки. Во PECL конекторот, серијализацијата е скриена длабоко во длабочините на библиотеката и влијае на процесот на кодирање од кодот на корисничката земја се чини дека не е можно. Чистиот 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). Но, ова не е изненадувачки, имајќи предвид дека вториот, покрај тоа што е имплементиран на побавен јазик, всушност работи повеќе: се создава нов објект со секој повик Побара и Одговор (во случај на Изберете - исто така Критериуми, а во случај на Ажурирање/Постави ― операции), поединечни субјекти врска, Пакувач и управувачот додаваат и режиски трошоци. Очигледно, флексибилноста има своја цена. Сепак, генерално, 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 корутини и видете што се случува:

Бројот на операции во секунда се зголеми за повеќе од 3 пати за tarantool-php/клиент!

За жал, PECL конекторот не започна со ext-async.

Што е со SQL?

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

Свул

Повторно го дознаваме оптималниот број на корутини, овој пат за Свул:

Да застанеме на 25. Да го повториме истиот трик како со екстензијата Async - дистрибуирајте 10,000 операции помеѓу 25 корутини. Дополнително, ќе додадеме уште еден тест во кој целата работа ќе ја поделиме на 2 два процеса (односно, секој процес ќе изврши 5,000 операции во 25 корутини). Процесите ќе се креираат со користење SwooleProcess.

Резултати:

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

Патем, екстензијата Async има и API за работа со процеси, но таму не забележав разлика од водење бенчмаркови во еден или повеќе процеси (можно е да сум збркал некаде).

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

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

Паралелни

Бидејќи наставката Parallel не се однесува на корутини, туку за нишки, ајде да го измериме оптималниот број на паралелни нишки:

Тоа е еднакво на 16 на мојата машина. Ајде да извршиме репери за конектори на 16 паралелни нишки:

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

Сега да ги споредиме перформансите на SQL:

Забележете ја сличноста со графикот за конекторите кои работат синхроно?

Заедно

И, конечно, да ги сумираме сите резултати во еден графикон за да ја видиме целокупната слика за тестираните екстензии. Ајде да додадеме само еден нов тест на графиконот, кој сè уште не сме го направиле - ајде паралелно да ги извршиме Async корутините со помош на Parallel*. Идејата за интегрирање на горенаведените екстензии е веќе се разговараше автори, но не е постигнат консензус, тоа ќе треба да го направите сами.

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

Значи, конечните резултати:

Наместо заклучок

Според мое мислење, резултатите се покажаа сосема достојни, и поради некоја причина сигурен сум дека ова не е граница! Дали треба да го решите ова во вистински проект само за себе, само ќе кажам дека за мене тоа беше интересен експеримент кој ви овозможува да оцените колку можете да „исцедите“ од синхрониот TCP конектор со минимален напор. Ако имате идеи за подобрување на одредниците, со задоволство ќе го разгледам вашето барање за повлекување. Целиот код со инструкции за лансирање и резултати е објавен во посебна складишта.

Извор: www.habr.com