Accelerera PHP-kopplingen för Tarantool med Async, Swoole och Parallel

I PHP-ekosystemet finns det för närvarande två kopplingar för att arbeta med Tarantool-servern - det officiella PECL-tillägget tarantool/tarantool-php, skrivet i C, och tarantool-php/client, skrivet i PHP. Jag är författaren till det sistnämnda.

I den här artikeln tänkte jag dela resultaten av prestandatestningen av båda biblioteken och visa hur man med minimala kodändringar kan uppnå en prestandaökning på 3-5i syntetiska tester!).

Vad ska vi testa?

Vi kommer att testa de ovan nämnda synkrona kopplingarna, körda asynkront, parallellt och asynkront-parallellt. 🙂 Vi vill också undvika att röra kopplingarnas kod. För närvarande finns det flera tillägg som gör det möjligt att uppnå önskat resultat:

• Swoole – en högpresterande asynkron ramverk för PHP. Används av internetjättar som Alibaba och Baidu. Från version 4.1.0 finns det en magisk metod SwooleRuntime::enableCoroutine(), som möjliggör 'att med en rad kod omvandla synkrona nätverksbibliotek i PHP till asynkrona'.
• Async – ett lovande tillägg för asynkron drift i PHP som fram till nyligen var populärt. Varför fram till nyligen? Tyvärr har författaren av okända skäl tagit bort arkivet och projektets framtid är osäker. Vi får använda ett av forkarna. Precis som Swoole gör detta tillägg det enkelt att implementera asynkronitet genom att ersätta den standardiserade TCP- och TLS-implementeringen med deras asynkrona versioner. Det görs genom alternativet 'async.tcp = 1«.
• Parallel – ett ganska nytt tillägg från den välkända Joe Watkins, skaparen av bibliotek som phpdbg, apcu, pthreads, pcov, uopz. Tillägget tillhandahåller ett API för flertrådad drift i PHP och marknadsförs som en ersättning för pthreads. Ett betydande begränsning av biblioteket är att det endast fungerar med ZTS (Zend Thread Safe) versionen av PHP.

Hur ska vi testa?

Vi kommer att köra en Tarantool-instans med logg över förhandsinspelning avstängd (wal_mode = none) och en ökad nätverksbuffer (readahead = 1 * 1024 * 1024). Det första alternativet eliminerar diskåtkomst, det andra ger möjlighet att läsa fler förfrågningar från operativsystemets buffer och därmed minimera antalet systemanrop.

För benchmarktester som arbetar med data (infogning, borttagning, läsning osv.) kommer en memtx-space att (åter)skapas innan testet startar, där värdena för den primära indexen skapas av en generator för ordnade heltalsvärden (sequence).
DDL-space ser ut så här:

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}})

Vid behov, innan benchmarktestet startar, fylls spacet med 10 000 tupler av typen

{id, "tuple_"}

Åtkomst till tuplerna sker med ett slumpmässigt värde av nyckeln.

Själva benchmarktestet består av en enskild begäran till servern, som utförs 10 000 gånger (varv), vilket i sin tur utförs i iterationer. Iterationerna upprepas tills alla avvikelser i tiden mellan 5 iterationer är inom en acceptabel felmarginal på 3 %*. Efter det tas ett genomsnittligt resultat. Mellan iterationerna är det en paus på 1 sekund för att förhindra att processorn går in i throttling. Lua-skräpunsamlaren stängs av före varje iteration och tvingas att starta efter dess avslutande. PHP-processen startas endast med de nödvändiga för benchmarktestet förlängningarna, med utdata-puffring aktiverad och skräpunsamlaren avstängd.

* Antalet varv, iterationer och felgränser kan ändras i inställningarna för benchmarktestet.

Testmiljö

De publicerade resultaten nedan uppnåddes på en MacBookPro (2015), operativsystemet är Fedora 30 (kernelversion 5.3.8-200.fc30.x86_64). Tarantool kördes i Docker med parametern ‘--network host".

Paketversioner:

Tarantool: 2.3.0-115-g5ba5ed37e
Docker: 19.03.3, build a872fc2f86
PHP: 7.3.11 (cli) (byggd: 22 okt 2019 08:11:04)
tarantool/client: 0.6.0
rybakit/msgpack: 0.6.1
ext-tarantool: 0.3.2 (+ patch för 7.3)*
ext-msgpack: 2.0.3
ext-async: 0.3.0-8c1da46
ext-swoole: 4.4.12
ext-parallel: 1.1.3

* Tyvärr fungerar den officiella kopplingen inte med PHP-versioner > 7.2. För att kompilera och köra tillägget på PHP 7.3 var jag tvungen att använda patchen.

Resultat

Synkront läge

Tarantool-protokollet använder ett binärt format MessagePack för serialisering av meddelanden. I PECL-kopplingen är serialiseringen djupt gömd i bibliotekets inre och det är inte möjligt att påverka kodningsprocessen från userland-kod inte är möjligt.. En ren PHP-connector ger å sin sida möjlighet att anpassa kodningsprocessen antingen genom att utvidga standardkodaren eller genom att använda sin egen implementering. Två kodare finns tillgängliga från början, en baserad på msgpack/msgpack-php (den officiella MessagePack PECL-tillägget), den andra på rybakit/msgpack (ren PHP).

Innan vi jämför connectorn, låt oss mäta prestandan hos MessagePack-kodare för PHP-connectorn och i de kommande testerna kommer vi använda den som visar det bästa resultatet:

Trots att PHP-versionen (Pure) är långsammare än PECL-tillägget, skulle jag fortfarande rekommendera att använda just rybakit/msgpack, eftersom det officiella MessagePack-tillägget endast delvis implementerat formatets specifikation (till exempel finns inget stöd för användardefinierade datatyper, vilket gör att du inte kan använda Decimal – en ny datatyp som introducerades i Tarantool 2.3) och har en rad andra av problem (inklusive kompatibilitetsproblem med PHP 7.4). Dessutom ser projektet i allmänhet övergivet ut.

Så, låt oss mäta prestandan hos connectorn i synkront läge:

Som man kan se från diagrammet visar PECL-connectorn (Tarantool) bättre prestanda jämfört med PHP-connectorn (Client). Men detta är inte förvånande, med tanke på att den senare, förutom att den är implementerad i ett långsammare språk, gör mer arbete: vid varje anrop skapas ett nytt objekt Begäran och Response (i fallet Select – även Criteria, och i fallet Update/Upsert – Operations), separata entiteter Connection, Packer och Handler tillför också overhead. Det är uppenbart att man får betala för flexibiliteten. Men generellt visar PHP-tolken bra prestanda, även om det finns en skillnad, men den är obetydlig och kommer sannolikt att bli ännu mindre vid användning av preloading i PHP 7.4, för att inte tala om JIT i PHP 8.

Låt oss gå vidare. I Tarantool 2.0 introducerades stöd för SQL. Låt oss försöka utföra operationerna Select, Insert, Update och Delete med hjälp av SQL-protokollet och jämföra resultaten med noSQL (binära) motsvarigheter:

Resultaten från SQL imponerar inte så mycket (jag påminner om att vi fortfarande testar det synkrona läget). Men jag skulle inte oroa mig för detta i förtid, stöd för SQL är fortfarande under aktiv utveckling (relativt nyligen, till exempel, lades stöd för prepared statements) till, och judging efter listan issues, SQL-motorn väntar på en rad optimeringar.

Async

Låt oss nu se hur Async-tillägget kan hjälpa oss att förbättra resultaten ovan. För att skriva asynkrona program erbjuder tillägget ett API baserat på korutiner (coroutines), som vi kommer att använda. Genom försök har vi kommit fram till att det optimala antalet korutiner för vår miljö är 25:

Vi "sprider ut" 10,000 operationer över 25 korutiner och ser vad resultatet blev:

Antalet operationer per sekund ökade mer än tre gånger för tarantool-php/client!

Tyvärr startade inte PECL-anslutningen med ext-async.

Hur står det till med SQL?

Som ni ser, i asynkront läge är skillnaden mellan det binära protokollet och SQL inom felmarginalen.

Swoole

Vi undersöker åter det optimala antalet korutiner, nu för Swoole:

Vi stannar vid 25. Vi upprepar samma trick som med Async-tillägget – sprider 10,000 operationer mellan 25 korutiner. Dessutom lägger vi till ett test där vi delar hela arbetet på 2 processer (det vill säga varje process kommer att utföra 5,000 operationer i 25 korutiner). Processerna kommer att skapas med hjälp av SwooleProcess.

Resultat:

Swoole visar något lägre resultat jämfört med Async vid körning i en process, men med 2 processer förändras bilden radikalt (siffran 2 valdes inte av en slump, på min maskin visade just 2 processer det bästa resultatet).

För övrigt har Async-tillägget också ett API för att arbeta med processer, men jag har inte märkt någon skillnad mellan att köra benchmarktester i en eller flera processer (det är möjligt att jag kan ha gjort ett misstag någonstans).

SQL mot det binära protokollet:

Precis som med Async, jämnas skillnaden mellan binära och SQL-operationer ut i asynkront läge.

Parallel

Eftersom Parallel-tillägget inte handlar om korutiner utan om trådar, mäter vi det optimala antalet parallella trådar:

Det är 16 på min maskin. Låt oss köra benchmarktester på anslutningarna med 16 parallella trådar:

Som ni ser, är resultatet till och med bättre än med de asynkrona tilläggen (förutom Swoole som kördes på 2 processer). Observera att för PECL-anslutningen är fältet för Update och Upsert-operationer tomt. Detta beror på att dessa operationer misslyckades med ett fel – jag vet inte om det beror på ext-parallel, ext-tarantool eller båda.

Nu jämför vi SQL-prestanda:

Ser ni likheten med grafen för anslutningar som kördes synkront?

Allt tillsammans

Till sist, låt oss sammanställa alla resultat i en graf för att se den övergripande bilden för de testade tilläggen. Vi lägger till ett nytt test på grafen, som vi inte har gjort tidigare – vi kör Async-koroutiner parallellt med hjälp av Parallel*. Idén om att integrera de nämnda tilläggen har redan diskuterats av författarna, men någon konsensus har ännu inte nåtts. Vi får göra detta själva.

* Det gick inte att köra Swoole-koroutiner med Parallel, det verkar som om dessa tillägg är inkompatibla.

Så, de slutgiltiga resultaten:

Avslutande

Jag tycker resultaten är ganska lovande, och jag är övertygad om att detta inte är slutet! Huruvida detta är något ni behöver i ert verkliga projekt, det avgör ni helt själva. Jag vill bara säga att detta var ett intressant experiment som ger en uppfattning om hur mycket man kan "pressa" ur en synkron TCP-anslutning med minsta möjliga ansträngning. Om ni har idéer för att förbättra benchmarkningarna – jag ser gärna över er pull request. All kod med instruktioner för körning och resultat har publicerats i ett separat förrådet.

Källa: habr.com