Í PHP vistkerfinu eru sem stendur tveir tengi til að vinna með Tarantool þjóninum - þetta er opinbera PECL viðbótin , skrifað í C, og , skrifað í PHP. Ég er höfundur þess síðarnefnda.
Í þessari grein langar mig að deila niðurstöðum árangursprófunar beggja bókasöfnanna og sýna hvernig, með lágmarksbreytingum á kóðanum, geturðu náð 3-5 frammistöðuaukningu (á gerviprófum!).
Hvað munum við prófa?
Við munum prófa þau sem nefnd eru hér að ofan samstilltur tengi sem keyra ósamstillt, samhliða og ósamstillt-samsíða. 🙂 Við viljum heldur ekki snerta kóðann á tengjunum sjálfum. Eins og er eru nokkrar viðbætur í boði til að ná því sem þú vilt:
- ― afkastamikil ósamstilltur rammi fyrir PHP. Notað af netrisum eins og Alibaba og Baidu. Frá útgáfu 4.1.0 hefur töfraaðferð birst SwooleRuntime::enableCoroutine(), sem gerir þér kleift að „umbreyta samstilltum PHP netsöfnum í ósamstillt með einni kóðalínu.
- Async var þar til nýlega mjög efnileg viðbót fyrir ósamstillta vinnu í PHP. Af hverju þar til nýlega? Því miður, af ástæðu sem ég þekki ekki, eyddi höfundur geymslunni og framtíðarörlög verkefnisins eru óljós. Ég verð að nota það frá gafflum. Eins og Swoole, gerir þessi viðbót þér kleift að kveikja á buxunum þínum með því að smella á úlnliðinn til að virkja ósamstillingu með því að skipta út hefðbundinni útfærslu TCP og TLS strauma fyrir ósamstilltu útgáfur þeirra. Þetta er gert með valkostinum „async.tcp = 1".
- - frekar ný viðbót frá hinum þekkta Joe Watkins, höfundi slíkra bókasöfna eins og phpdbg, apcu, pthreads, pcov, uopz. Viðbótin veitir API fyrir multithreading í PHP og er staðsett sem staðgengill fyrir pthreads. Veruleg takmörkun á bókasafninu er að það virkar aðeins með ZTS (Zend Thread Safe) útgáfunni af PHP.
Hvernig munum við prófa?
Við skulum ræsa Tarantool tilvik þar sem framdrifsskráning er óvirk (wal_mode = enginn) og aukinn netbuffi (lesa á undan = 1 * 1024 * 1024). Fyrsti valkosturinn mun útrýma vinnu með diskinn, sá síðari gerir það mögulegt að lesa fleiri beiðnir úr biðminni stýrikerfisins og lágmarka þar með fjölda kerfiskalla.
Fyrir viðmið sem vinna með gögn (innsetning, eyðing, lestur o.s.frv.), áður en viðmiðið er hafið, verður memtx rými (endur) búið til, þar sem aðalvísitölugildin eru búin til af rafalli raðaðra heiltölugilda (röð).
Rýmið DDL lítur svona út:
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}})Ef nauðsyn krefur, áður en viðmiðið er keyrt, er plássið fyllt með 10,000 túllum af eyðublaðinu
{id, "tuplе_<id>"}Túllur eru aðgengilegar með því að nota tilviljunarkennd lykilgildi.
Viðmiðið sjálft er ein beiðni til netþjónsins, sem er framkvæmd 10,000 sinnum (snúningur), sem aftur á móti eru framkvæmdar í endurteknum hætti. Endurtekningarnar eru endurteknar þar til öll tímafrávik milli 5 endurtekninga eru innan viðsættanlegrar skekkju sem nemur 3%*. Eftir þetta er meðaltal niðurstaða tekin. Það er 1 sekúnda hlé á milli endurtekninga til að koma í veg fyrir að örgjörvinn kveiki. Sorpið hans Lua er óvirkt fyrir hverja endurtekningu og neyðist til að byrja eftir að henni lýkur. PHP ferlið er aðeins hleypt af stokkunum með viðbótunum sem nauðsynlegar eru fyrir viðmiðið, með úttaksbufferingu virkt og sorphirðu óvirk.
* Fjölda snúninga, endurtekningar og villuþröskulds er hægt að breyta í viðmiðunarstillingunum.
Próf umhverfi
Niðurstöðurnar sem birtar eru hér að neðan voru gerðar á MacBookPro (2015), stýrikerfi - Fedora 30 (kjarnaútgáfa 5.3.8-200.fc30.x86_64). Tarantool var hleypt af stokkunum í docker með færibreytunni "--network host".
Pakkaútgáfur:
Tarantool: 2.3.0-115-g5ba5ed37e
Hafnarvörður: 19.03.3, smíðaður a872fc2f86
PHP: 7.3.11 (cli) (smíðað: 22. október 2019 08:11:04)
tarantool/viðskiptavinur: 0.6.0
rybakit/msgpack: 0.6.1
ext-tarantool: 0.3.2 (+ plástur fyrir 7.3)*
ext-msgpack: 2.0.3
ext-async: 0.3.0-8c1da46
ext-wool: 4.4.12
ytri hliðstæðu: 1.1.3
* Því miður virkar opinbera tengið ekki með PHP útgáfu > 7.2. Til að setja saman og keyra viðbótina á PHP 7.3 þurfti ég að nota .
Niðurstöður
Samstilltur háttur
Tarantool samskiptareglur notar tvíundarsnið til að raða skilaboðum. Í PECL tenginu er raðgreining falin djúpt í djúpum bókasafnsins og hefur áhrif á kóðun ferlið frá kóða notendalands. . Hreint PHP tengi, þvert á móti, veitir möguleika á að sérsníða kóðunarferlið með því að framlengja staðlaða kóðara eða með því að nota þína eigin útfærslu. Það eru tveir umritarar fáanlegir úr kassanum, annar er byggður á (opinber MessagePack PECL eftirnafn), hin er á (í hreinu PHP).
Áður en tengin eru borin saman munum við mæla frammistöðu MessagePack kóðara fyrir PHP tengið og í frekari prófunum munum við nota þann sem sýnir bestu niðurstöðuna:
Þó að PHP útgáfan (Pure) sé óæðri PECL viðbótinni í hraða, þá myndi ég samt mæla með því að nota hana í raunverulegum verkefnum , vegna þess að í opinberu MessagePack viðbótinni er sniðforskriftin aðeins útfærð að hluta (til dæmis er enginn stuðningur við sérsniðnar gagnagerðir, án þeirra muntu ekki geta notað Decimal - ný gagnategund kynnt í Tarantool 2.3) og hefur fjölda annarra (þar á meðal samhæfnisvandamál við PHP 7.4). Jæja, almennt lítur verkefnið út fyrir að vera yfirgefið.
Svo, við skulum mæla frammistöðu tengi í samstilltum ham:
Eins og sést á línuritinu sýnir PECL tengið (Tarantool) betri frammistöðu samanborið við PHP tengið (Client). En þetta kemur ekki á óvart, í ljósi þess að hið síðarnefnda, auk þess að vera útfært á hægara tungumáli, virkar í raun meiri vinnu: nýr hlutur er búinn til með hverju símtali Beiðni и svar (ef um er að ræða Select - líka Viðmiðanir, og ef um er að ræða Update/Upsert - aðgerðir), aðskildar einingar Tenging, Pakkari и dýraþjálfari þeir bæta einnig við kostnaði. Augljóslega kostar sveigjanleiki. Hins vegar, almennt séð, sýnir PHP túlkurinn góða frammistöðu, þó það sé munur, þá er hann óverulegur og verður kannski enn minni þegar forhleðsla er notuð í PHP 7.4, svo ekki sé minnst á JIT í PHP 8.
Höldum áfram. Tarantool 2.0 kynnti SQL stuðning. Við skulum reyna að framkvæma Select, Insert, Update og Delete aðgerðir með því að nota SQL samskiptareglur og bera saman niðurstöðurnar við noSQL (tvíundir) jafngildin:
SQL niðurstöðurnar eru ekki mjög áhrifamiklar (mig minnir þig á að við erum enn að prófa samstilltan hátt). Hins vegar myndi ég ekki verða pirruð yfir þessu fyrirfram; SQL stuðningur er enn í virkri þróun (tiltölulega nýlega, til dæmis var stuðningi bætt við ) og af listanum að dæma , SQL vélin mun gangast undir fjölda hagræðinga í framtíðinni.
Ósamstilltur
Jæja, nú skulum við sjá hvernig Async viðbótin getur hjálpað okkur að bæta niðurstöðurnar hér að ofan. Til að skrifa ósamstillt forrit býður viðbótin upp á API byggt á coroutines, sem við munum nota. Við komumst að reynslunni að ákjósanlegur fjöldi coroutines fyrir umhverfi okkar er 25:
„Dreifðu“ 10,000 aðgerðum yfir 25 kóróútínur og sjáðu hvað gerist:
Fjöldi aðgerða á sekúndu jókst um meira en 3 sinnum fyrir !
Því miður byrjaði PECL tengið ekki með ext-async.
Hvað með SQL?
Eins og þú sérð, í ósamstilltum ham varð munurinn á milli tvíundarsamskiptareglunnar og SQL innan skekkjumarka.
Swoole
Aftur komumst við að ákjósanlegum fjölda coroutines, að þessu sinni fyrir Swoole:
Stoppum við 25. Endurtökum sama bragðið og með Async viðbótinni - dreifum 10,000 aðgerðum á milli 25 coroutines. Að auki munum við bæta við öðru prófi þar sem við munum skipta allri vinnu í 2 tvo ferla (það er, hvert ferli mun framkvæma 5,000 aðgerðir í 25 coroutines). Ferlar verða búnir til með því að nota SwooleProcess.
Úrslit:
Swole sýnir aðeins lægri niðurstöðu miðað við Async þegar hún er keyrð í einu ferli, en með 2 ferlum breytist myndin verulega (talan 2 var ekki valin af tilviljun; á minni vél voru það 2 ferli sem sýndu bestu niðurstöðuna).
Við the vegur, Async viðbótin er líka með API til að vinna með ferla, en þar tók ég ekki eftir neinum mun á því að keyra benchmarks í einum eða fleiri ferlum (það er hugsanlegt að ég hafi klúðrað einhvers staðar).
SQL vs tvöfaldur samskiptaregla:
Eins og með Async er munurinn á tvíundar- og SQL-aðgerðum eytt í ósamstilltum ham.
Samhliða
Þar sem samhliða framlengingin snýst ekki um coroutines, heldur um þræði, skulum við mæla ákjósanlegan fjölda samhliða þráða:
Það er jafnt og 16 á vélinni minni. Við skulum keyra tengiviðmið á 16 samhliða þræði:
Eins og þú sérð er útkoman jafnvel betri en með ósamstilltum framlengingum (svoole er ekki talið með í gangi á 2 ferlum). Athugaðu að fyrir PECL tengið eru uppfærslu- og uppfærsluaðgerðirnar tómar. Þetta er vegna þess að þessar aðgerðir mistókust með villu - ég veit ekki hvort það var ext-parallel, ext-tarantool eða hvort tveggja að kenna.
Nú skulum við bera saman SQL árangur:
Taktu eftir líkt með línuritinu fyrir tengi sem keyra samstillt?
Saman
Og að lokum skulum við draga saman allar niðurstöðurnar í einu línuriti til að sjá heildarmyndina fyrir prófuðu viðbæturnar. Við skulum bæta aðeins einu nýju prófi við töfluna, sem við höfum ekki gert enn - við skulum keyra Async coroutines samhliða með Parallel*. Hugmyndin um að samþætta ofangreindar viðbætur er nú þegar höfunda, en ekki náðist samstaða, þú verður að gera það sjálfur.
* Það var ekki hægt að ræsa Swoole coroutines með Parallel; það virðist sem þessar viðbætur séu ósamrýmanlegar.
Svo, lokaniðurstöður:
Í stað þess að niðurstöðu
Niðurstöðurnar reyndust að mínu mati nokkuð verðugar og af einhverjum ástæðum er ég viss um að þetta eru ekki takmörkin! Hvort sem þú þarft að ákveða þetta í alvöru verkefni eingöngu fyrir sjálfan þig, mun ég aðeins segja að fyrir mig var þetta áhugaverð tilraun sem gerir þér kleift að meta hversu mikið þú getur "kreist" út úr samstilltu TCP tengi með lágmarks fyrirhöfn. Ef þú hefur hugmyndir til að bæta viðmið, mun ég vera fús til að íhuga dráttarbeiðni þína. Allur kóði með ræsingarleiðbeiningum og niðurstöðum er birtur í sérstakri .
Heimild: www.habr.com