У ПХП екосистему тренутно постоје два конектора за рад са Тарантоол сервером - ово је званична ПЕЦЛ екстензија , написано у Ц, и , написан у ПХП-у. Ја сам аутор овог другог.
У овом чланку желим да поделим резултате тестирања перформанси обе библиотеке и покажем како, уз минималне промене кода, можете постићи повећање перформанси за 3-5 (на синтетичким тестовима!).
Шта ћемо тестирати?
Ми ћемо тестирати горе поменуте синхрони конектори који раде асинхроно, паралелно и асинхроно-паралелно. 🙂 Такође не желимо да дирамо код самих конектора. Тренутно је доступно неколико проширења да бисте постигли оно што желите:
- ― асинхрони оквир високих перформанси за ПХП. Користе га Интернет гиганти као што су Алибаба и Баиду. Од верзије 4.1.0 појавио се магични метод СвоолеРунтиме::енаблеЦороутине(), који вам омогућава да „конвертујете синхроне ПХП мрежне библиотеке у асинхроне помоћу једног реда кода.“
- Асинц је донедавно био веома обећавајуће проширење за асинхрони рад у ПХП-у. Зашто донедавно? Нажалост, из мени непознатог разлога, аутор је обрисао спремиште и даља судбина пројекта је нејасна. Мораћу да га искористим од виљушке. Као и Свооле, ово проширење вам омогућава да лако укључите панталоне покретом ручног зглоба да бисте омогућили асинхронију заменом стандардне имплементације ТЦП и ТЛС токова њиховим асинхроним верзијама. Ово се ради преко опције „асинц.тцп = 1".
- ― прилично ново проширење познатог Џоа Воткинса, аутора библиотека као што су пхпдбг, апцу, птхреадс, пцов, уопз. Екстензија обезбеђује АПИ за вишенитност у ПХП-у и позиционирана је као замена за птхреадс. Значајно ограничење библиотеке је то што ради само са ЗТС (Зенд Тхреад Сафе) верзијом ПХП-а.
Како ћемо тестирати?
Хајде да покренемо инстанцу Тарантоол-а са онемогућеним евидентирањем унапред (вал_моде = ниједан) и повећан мрежни бафер (Реадахеад = 1 * 1024 * 1024). Прва опција ће елиминисати рад са диском, друга ће омогућити читање више захтева из бафера оперативног система и на тај начин минимизирати број системских позива.
За бенцхмаркове који раде са подацима (уметање, брисање, читање, итд.), пре покретања бенцхмарк-а, биће (ре)креиран мемтк простор у коме се примарне вредности индекса креирају помоћу генератора наређених целобројних вредности. (редослед).
Простор ДДЛ изгледа овако:
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 секунде како би се спречило смањење притиска процесора. Луа-ин сакупљач смећа је онемогућен пре сваке итерације и принуђен је да се покрене након што се заврши. ПХП процес се покреће само са екстензијама неопходним за бенцхмарк, са омогућеним баферовањем излаза и онемогућеним сакупљачем смећа.
* Број обртаја, итерација и праг грешке се могу променити у подешавањима бенцхмарк-а.
Тестно окружење
Резултати објављени у наставку су направљени на МацБоокПро (2015), оперативни систем - Федора 30 (верзија кернела 5.3.8-200.фц30.к86_64). Тарантоол је покренут у Доцкер-у са параметром "--network host".
Верзије пакета:
Tarantool: 2.3.0-115-g5ba5ed37e
Доцкер: 19.03.3, буилд а872фц2ф86
ПХП: 7.3.11 (цли) (изграђен: 22. октобар 2019. 08:11:04)
тарантоол/клијент: 0.6.0
рибакит/мсгпацк: 0.6.1
ект-тарантоол: 0.3.2 (+ закрпа за 7.3)*
ект-мсгпацк: 2.0.3
ект-асинц: 0.3.0-8ц1да46
ект-свооле: 4.4.12
ект-параллел: 1.1.3
* Нажалост, званични конектор не ради са ПХП верзијом > 7.2. Да бих компајлирао и покренуо проширење на ПХП 7.3, морао сам да користим .
Налази
Синхрони режим
Тарантоол протокол користи бинарни формат за серијализацију порука. У ПЕЦЛ конектору, серијализација је скривена дубоко у дубинама библиотеке и утиче на процес кодирања из корисничког кода . Чисти ПХП конектор, напротив, пружа могућност прилагођавања процеса кодирања проширењем стандардног кодера или коришћењем сопствене имплементације. Из кутије су доступна два енкодера, један је заснован на (званична екстензија МессагеПацк ПЕЦЛ), друга је укључена (у чистом ПХП-у).
Пре него што упоредимо конекторе, измерићемо перформансе МессагеПацк кодера за ПХП конектор и у даљим тестовима користићемо онај који показује најбољи резултат:
Иако је ПХП верзија (Пуре) инфериорнија од ПЕЦЛ екстензије у брзини, у стварним пројектима бих ипак препоручио да је користите , јер је у званичној екстензији МессагеПацк спецификација формата само делимично имплементирана (на пример, не постоји подршка за прилагођене типове података, без којих нећете моћи да користите Децимал – нови тип података уведен у Тарантоол 2.3) и има број других (укључујући проблеме компатибилности са ПХП 7.4). Па, генерално, пројекат изгледа напуштен.
Дакле, хајде да измеримо перформансе конектора у синхроном режиму:
Као што се види из графикона, ПЕЦЛ конектор (Тарантоол) показује боље перформансе у односу на ПХП конектор (Клијент). Али то није изненађујуће, с обзиром на то да овај други, поред тога што је имплементиран на споријем језику, заправо ради више: нови објекат се креира са сваким позивом Рекуест и одговор (у случају Селецт - такође kriterijumi, ау случају ажурирања/упсерт-а ― operacije), засебни ентитети веза, Пацкер и хандлер додају и режије. Очигледно, флексибилност има цену. Међутим, генерално, ПХП интерпретер показује добре перформансе, иако постоји разлика, она је безначајна и, можда, биће још мања када се користи прелоадинг у ПХП 7.4, а да не помињемо ЈИТ у ПХП 8.
Идемо даље. Тарантоол 2.0 је додао подршку за СКЛ. Хајде да покушамо да изведемо операције Селецт, Инсерт, Упдате и Делете користећи СКЛ протокол и упоредимо резултате са ноСКЛ (бинарним) еквивалентима:
СКЛ резултати нису баш импресивни (да вас подсетим да још увек тестирамо синхрони режим). Међутим, не бих се узнемиравао због овога пре времена; СКЛ подршка је још увек у активном развоју (релативно недавно, на пример, подршка је додата ) и, судећи по списку , СКЛ мотор ће у будућности бити подвргнут бројним оптимизацијама.
Асинц
Па, сада да видимо како нам проширење Асинц може помоћи да побољшамо резултате изнад. За писање асинхроних програма, проширење обезбеђује АПИ заснован на корутинама, које ћемо користити. Емпиријски сазнајемо да је оптималан број корутина за наше окружење 25:
„Распоредите“ 10,000 операција на 25 корутина и погледајте шта се дешава:
Број операција у секунди порастао је за више од 3 пута за !
Нажалост, ПЕЦЛ конектор није почео са ект-асинц.
Шта је са СКЛ-ом?
Као што видите, у асинхроном режиму разлика између бинарног протокола и СКЛ-а је била унутар границе грешке.
Свооле
Поново сазнајемо оптималан број корутина, овог пута за Свооле:
Зауставимо се на 25. Хајде да поновимо исти трик као са екстензијом Асинц - распоредите 10,000 операција између 25 корутина. Поред тога, додаћемо још један тест у коме ћемо сав рад поделити на 2 два процеса (то јест, сваки процес ће извршити 5,000 операција у 25 корутина). Процеси ће се креирати помоћу СвоолеПроцесс.
Резултати:
Своле показује нешто мањи резултат у поређењу са Асинц када се покрене у једном процесу, али са 2 процеса слика се драматично мења (број 2 није случајно изабран; на мојој машини су 2 процеса показала најбољи резултат).
Иначе, екстензија Асинц такође има АПИ за рад са процесима, али ту нисам приметио никакву разлику од покретања бенчмарка у једном или више процеса (могуће је да сам негде забрљао).
СКЛ наспрам бинарног протокола:
Као и код Асинц, разлика између бинарних и СКЛ операција је елиминисана у асинхроном режиму.
Паралелно
Пошто се паралелно проширење не односи на корутине, већ на нити, измеримо оптималан број паралелних нити:
На мојој машини је једнако 16. Хајде да покренемо тестове конектора на 16 паралелних нити:
Као што видите, резултат је чак и бољи него код асинхроних екстензија (не рачунајући Свооле који ради на 2 процеса). Имајте на уму да су за ПЕЦЛ конектор операције ажурирања и упсерт празне. То је због чињенице да ове операције нису успеле са грешком - не знам да ли је то била грешка ект-параллел, ект-тарантоол или обоје.
Сада упоредимо СКЛ перформансе:
Примећујете сличност са графиконом за конекторе који раде синхроно?
Заједно
И на крају, хајде да сумирамо све резултате у једном графикону да видимо општу слику за тестирана проширења. Хајде да додамо само један нови тест на графикон, који још нисмо урадили - покренимо асинц корутине паралелно користећи Параллел*. Идеја о интегрисању горњих екстензија већ постоји аутора, али није постигнут консензус, мораћете сами.
* Није било могуће покренути Свооле корутине са Параллел-ом; изгледа да су ове екстензије некомпатибилне.
Дакле, коначни резултати:
Уместо закључка
По мом мишљењу, резултати су се показали сасвим вредним, и из неког разлога сам сигуран да то није граница! Без обзира да ли у стварном пројекту то треба да одлучите искључиво за себе, рећи ћу само да је за мене то био занимљив експеримент који вам омогућава да процените колико можете да „исцедите“ из синхроног ТЦП конектора уз минималан напор. Ако имате идеје за побољшање референтних вредности, радо ћу размотрити ваш захтев за повлачење. Сав код са упутствима за покретање и резултатима објављен је у посебном .
Извор: ввв.хабр.цом