PHP ekotizimida hozirda Tarantool serveri bilan ishlash uchun ikkita ulagich mavjud - bu rasmiy PECL kengaytmasi , C tilida yozilgan va , PHP da yozilgan. Men ikkinchisining muallifiman.
Ushbu maqolada men ikkala kutubxonaning ishlashini sinab ko'rish natijalarini baham ko'rmoqchiman va kodga minimal o'zgartirishlar kiritib, unumdorlikni 3-5 ga oshirishga qanday erishish mumkinligini ko'rsatmoqchiman (sintetik testlarda!).
Biz nimani sinab ko'ramiz?
Biz yuqorida aytib o'tilganlarni sinab ko'ramiz sinxron asinxron, parallel va asinxron-parallel ishlaydigan ulagichlar. π Shuningdek, biz ulagichlarning kodiga tegmoqchi emasmiz. Hozirda siz xohlagan narsaga erishish uchun bir nechta kengaytmalar mavjud:
- β PHP uchun yuqori samarali asinxron ramka. Alibaba va Baidu kabi internet gigantlari tomonidan foydalaniladi. 4.1.0 versiyasidan boshlab sehrli usul paydo bo'ldi SwooleRuntime::enableCoroutine(), bu sizga "sinxron PHP tarmoq kutubxonalarini bir qator kod bilan asinxronlarga aylantirish" imkonini beradi.
- Async yaqin vaqtgacha PHP da asinxron ish uchun juda istiqbolli kengaytma edi. Nega yaqin vaqtgacha? Afsuski, menga noma'lum sababga ko'ra, muallif omborni o'chirib tashladi va loyihaning kelajakdagi taqdiri noaniq. Men undan foydalanishim kerak vilkalardan. Swoole singari, bu kengaytma ham TCP va TLS oqimlarining standart amalga oshirilishini ularning asinxron versiyalari bilan almashtirish orqali asinxronlikni yoqish uchun bilakni silkitib osongina shimingizni ochish imkonini beradi. Bu "variant" orqali amalga oshiriladi.async.tcp = 1".
- β phpdbg, apcu, pthreads, pcov, uopz kabi kutubxonalar muallifi taniqli Jo Uotkinsning yangi kengaytmasi. Kengaytma PHP-da ko'p ish zarralari uchun API taqdim etadi va pthreads o'rnini bosuvchi sifatida joylashtirilgan. Kutubxonaning sezilarli cheklovi shundaki, u faqat PHP ning ZTS (Zend Thread Safe) versiyasi bilan ishlaydi.
Qanday sinov qilamiz?
Oldindan yozish o'chirilgan holda Tarantool misolini ishga tushiramiz (wal_mode = yo'q) va kengaytirilgan tarmoq buferi (oldinga o'qish = 1 * 1024 * 1024). Birinchi variant disk bilan ishlashni bartaraf qiladi, ikkinchisi operatsion tizim buferidan ko'proq so'rovlarni o'qish imkonini beradi va shu bilan tizim qo'ng'iroqlari sonini kamaytiradi.
Ma'lumotlar bilan ishlaydigan ko'rsatkichlar uchun (qo'shish, o'chirish, o'qish va h.k.) benchmarkni boshlashdan oldin memtx maydoni yaratiladi (qayta), unda asosiy indeks qiymatlari tartiblangan butun qiymatlar generatori tomonidan yaratiladi. (ketma-ketlik).
DDL maydoni quyidagicha ko'rinadi:
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}})Agar kerak bo'lsa, benchmarkni ishga tushirishdan oldin, bo'sh joy shaklning 10,000 XNUMX korteji bilan to'ldiriladi.
{id, "tuplΠ΅_<id>"}Kortejlarga tasodifiy kalit qiymati yordamida kirish mumkin.
Benchmarkning o'zi serverga bitta so'rov bo'lib, u 10,000 5 marta (inqiloblar) bajariladi, bu esa o'z navbatida iteratsiyalarda bajariladi. Takrorlashlar 3 ta takrorlash orasidagi barcha vaqt og'ishlari 1% * qabul qilinadigan xatolik chegarasida bo'lguncha takrorlanadi. Shundan so'ng o'rtacha natija olinadi. Protsessorning siqilishiga yo'l qo'ymaslik uchun takrorlashlar orasida XNUMX soniyalik pauza mavjud. Lua axlat yig'uvchisi har bir iteratsiyadan oldin o'chiriladi va u tugallangandan keyin ishga tushishga majbur bo'ladi. PHP jarayoni faqat benchmark uchun zarur bo'lgan kengaytmalar bilan ishga tushiriladi, chiqish buferlash yoqilgan va axlat yig'uvchi o'chirilgan.
* Inqiloblar soni, takrorlashlar va xato chegarasi benchmark sozlamalarida o'zgartirilishi mumkin.
Sinov muhiti
Quyida e'lon qilingan natijalar MacBookPro (2015), operatsion tizimi - Fedora 30 (yadro versiyasi 5.3.8-200.fc30.x86_64) da qilingan. Tarantool dockerda "parametri bilan ishga tushirildi.--network host".
Paket versiyalari:
Tarantool: 2.3.0-115-g5ba5ed37e
Docker: 19.03.3, a872fc2f86 tuzing
PHP: 7.3.11 (cli) (qurilgan: 22 yil 2019 oktyabr 08:11:04)
tarantool/mijoz: 0.6.0
rybakit/msgpack: 0.6.1
ext-tarantool: 0.3.2 (+ 7.3 uchun yamoq)*
ext-msgpack: 2.0.3
ext-async: 0.3.0-8c1da46
ext-swoole: 4.4.12
tashqi parallel: 1.1.3
* Afsuski, rasmiy ulagich PHP versiyasi > 7.2 bilan ishlamaydi. PHP 7.3 da kengaytmani kompilyatsiya qilish va ishga tushirish uchun men foydalanishim kerak edi .
Natijalar
Sinxron rejim
Tarantool protokoli ikkilik formatdan foydalanadi xabarlarni ketma-ketlashtirish uchun. PECL ulagichida ketma-ketlashtirish kutubxonaning chuqurligida yashiringan va foydalanuvchi kodidan kodlash jarayoniga ta'sir qiladi. . Sof PHP ulagichi, aksincha, standart kodlovchini kengaytirish yoki o'zingizning dasturingizdan foydalanish orqali kodlash jarayonini sozlash imkoniyatini beradi. Ikkita enkoder mavjud, ulardan biri asoslangan (rasmiy MessagePack PECL kengaytmasi), ikkinchisi yoqilgan (sof PHP da).
Ulagichlarni solishtirishdan oldin, biz PHP ulagichi uchun MessagePack kodlovchilarining ishlashini o'lchaymiz va keyingi testlarda biz eng yaxshi natijani ko'rsatadiganidan foydalanamiz:
PHP versiyasi (Pure) tezligi bo'yicha PECL kengaytmasidan past bo'lsa ham, haqiqiy loyihalarda men undan foydalanishni tavsiya qilaman. , chunki rasmiy MessagePack kengaytmasida format spetsifikatsiyasi qisman amalga oshirilgan (masalan, maxsus ma'lumotlar turlarini qo'llab-quvvatlamaydi, ularsiz siz Decimal - Tarantool 2.3 da kiritilgan yangi ma'lumotlar turidan foydalana olmaysiz) va boshqalar soni (PHP 7.4 bilan moslik muammolari, shu jumladan). Umuman olganda, loyiha tashlab ketilgan ko'rinadi.
Shunday qilib, keling, sinxron rejimda ulagichlarning ishlashini o'lchaymiz:
Grafikdan ko'rinib turibdiki, PECL ulagichi (Tarantool) PHP ulagichiga (mijoz) nisbatan yaxshiroq ishlashni ko'rsatadi. Ammo bu ajablanarli emas, chunki ikkinchisi sekinroq tilda amalga oshirilishidan tashqari, aslida ko'proq ish qiladi: har bir qo'ng'iroq bilan yangi ob'ekt yaratiladi. so'rov ΠΈ javob (Tanlash holatida - shuningdek Mezonlar, va Yangilash/Yuqorlash holatida β operatsiyalar), alohida ob'ektlar Ulanish, Packer ΠΈ Ishlov beruvchi ular ham qo'shimcha xarajatlarni qo'shadilar. Shubhasiz, moslashuvchanlik qimmatga tushadi. Ammo, umuman olganda, PHP tarjimoni yaxshi samaradorlikni ko'rsatadi, garchi farq bor bo'lsa-da, u ahamiyatsiz va PHP 7.4 da oldindan yuklashdan foydalanganda, PHP 8 da JIT haqida gapirmasa ham, undan ham kamroq bo'ladi.
Keling, davom etaylik. Tarantool 2.0 SQL qo'llab-quvvatlashini qo'shdi. Keling, SQL protokoli yordamida Tanlash, Insert, Update va Delete operatsiyalarini bajarishga harakat qilaylik va natijalarni noSQL (ikkilik) ekvivalentlari bilan solishtiramiz:
SQL natijalari unchalik ta'sirchan emas (sizga eslatib o'tamanki, biz hali ham sinxron rejimni sinab ko'rmoqdamiz). Biroq, men bundan oldin xafa bo'lmayman; SQL-ni qo'llab-quvvatlash hali ham faol ishlab chiqilmoqda (nisbatan yaqinda, masalan, qo'llab-quvvatlash qo'shildi. ) va ro'yxatga ko'ra , SQL dvigateli kelajakda bir qator optimallashtirishlardan o'tadi.
Asenkron
Keling, Async kengaytmasi yuqoridagi natijalarni yaxshilashga qanday yordam berishi mumkinligini ko'rib chiqaylik. Asinxron dasturlarni yozish uchun kengaytma koroutinlarga asoslangan APIni taqdim etadi, biz undan foydalanamiz. Biz empirik tarzda aniqlaymizki, bizning atrof-muhitimiz uchun optimal koroutinlar soni 25 ta:
10,000 ta koroutin bo'ylab 25 XNUMX ta operatsiyani "tarqang" va nima sodir bo'lishini ko'ring:
uchun soniyada operatsiyalar soni 3 baravardan ko'proq oshdi !
Afsuski, PECL ulagichi ext-async bilan boshlanmadi.
SQL haqida nima deyish mumkin?
Ko'rib turganingizdek, asinxron rejimda ikkilik protokol va SQL o'rtasidagi farq xatolik chegarasida bo'ldi.
Swoole
Yana biz Swoole uchun koroutinlarning optimal sonini topamiz:
Keling, 25 da to'xtaymiz. Async kengaytmasi bilan bir xil nayrangni takrorlaymiz - 10,000 ta koroutin o'rtasida 25 2 operatsiyani taqsimlang. Bundan tashqari, biz yana bir test qo'shamiz, unda biz barcha ishni 5,000 ta ikkita jarayonga ajratamiz (ya'ni, har bir jarayon 25 ta koroutinda XNUMX ta operatsiyani bajaradi). Jarayonlar yordamida yaratiladi SwooleProcess.
Natijalar:
Swole bir jarayonda ishga tushirilganda Async bilan solishtirganda biroz pastroq natijani ko'rsatadi, lekin 2 jarayon bilan rasm keskin o'zgaradi (2-raqam tasodifan tanlanmagan; mening mashinamda 2 ta jarayon eng yaxshi natijani ko'rsatdi).
Aytgancha, Async kengaytmasida jarayonlar bilan ishlash uchun API ham mavjud, ammo u erda men bir yoki bir nechta jarayonlarda benchmarklarni ishga tushirishdan hech qanday farqni sezmadim (qaerdadir aralashgan bo'lishim mumkin).
SQL va ikkilik protokol:
Async bilan bo'lgani kabi, ikkilik va SQL operatsiyalari o'rtasidagi farq asinxron rejimda yo'q qilinadi.
Parallel
Parallel kengaytma koroutinlar haqida emas, balki iplar haqida bo'lgani uchun, keling, parallel iplarning optimal sonini o'lchaymiz:
Bu mening mashinamda 16 ga teng. Keling, 16 ta parallel iplar bo'yicha konnektor benchmarklarini bajaramiz:
Ko'rib turganingizdek, natija asinxron kengaytmalardan ham yaxshiroq (2 ta jarayonda ishlaydigan Swooleni hisobga olmaganda). PECL ulagichi uchun Yangilash va Upsert operatsiyalari bo'sh ekanligini unutmang. Buning sababi, bu operatsiyalar xato bilan muvaffaqiyatsiz tugadi - bu tashqi parallel, ext-tarantool yoki ikkalasining aybi ekanligini bilmayman.
Endi SQL ish faoliyatini solishtiramiz:
Sinxron ishlaydigan ulagichlar uchun grafik bilan o'xshashlikka e'tibor bering?
Hamma birgalikda
Va nihoyat, sinovdan o'tgan kengaytmalarning umumiy rasmini ko'rish uchun barcha natijalarni bitta grafikda umumlashtiramiz. Keling, diagrammaga hali bajarilmagan bitta yangi testni qo'shamiz - Parallel* yordamida parallel ravishda Async koroutinlarini ishga tushiramiz. Yuqoridagi kengaytmalarni birlashtirish g'oyasi allaqachon mavjud mualliflar, lekin konsensusga erishilmadi, buni o'zingiz qilishingiz kerak bo'ladi.
* Parallel bilan Swoole koroutinlarini ishga tushirishning iloji bo'lmadi; bu kengaytmalar mos kelmaydiganga o'xshaydi.
Shunday qilib, yakuniy natijalar:
Xulosa o'rniga
Menimcha, natijalar juda munosib bo'ldi va negadir men bu chegara emasligiga aminman! Buni faqat o'zingiz uchun haqiqiy loyihada hal qilishingiz kerakmi yoki yo'qmi, shuni aytamanki, men uchun bu qiziqarli eksperiment bo'lib, sizga minimal harakat bilan sinxron TCP ulagichidan qanchalik "siqib chiqish" mumkinligini baholashga imkon beradi. Agar sizda ko'rsatkichlarni yaxshilash bo'yicha g'oyalaringiz bo'lsa, men sizning tortishish so'rovingizni ko'rib chiqishdan mamnun bo'laman. Ishga tushirish bo'yicha ko'rsatmalar va natijalar bilan barcha kod alohida nashr etiladi .
Manba: www.habr.com