Async، Swoole ۽ Parallel استعمال ڪندي Tarantool لاءِ PHP ڪنيڪٽرز کي تيز ڪرڻ

PHP ايڪو سسٽم ۾ في الحال ٻه رابطا آهن Tarantool سرور سان ڪم ڪرڻ لاءِ - هي آهي سرڪاري PECL ايڪسٽينشن tarantool/tarantool-phpسي ۾ لکيل آهي، ۽ tarantool-php/clientPHP ۾ لکيل آهي. مان بعد ۾ ليکڪ آهيان.

هن آرٽيڪل ۾، مان ٻنهي لائبريرين جي ڪارڪردگي جاچ جا نتيجا حصيداري ڪرڻ چاهيندس ۽ ڏيکاريو ته ڪيئن، ڪوڊ ۾ گهٽ ۾ گهٽ تبديلين سان، توهان حاصل ڪري سگهو ٿا 3-5 ڪارڪردگي واڌارو (مصنوعي تجربن تي!).

اسان ڇا امتحان ڪنداسين؟

اسان مٿي ذڪر ڪيل ٽيسٽ ڪنداسين هم وقت ساز ڪنيڪٽر هلن ٿا هم وقت سازي سان، متوازي ۾، ۽ متوازي طور تي متوازي. 🙂 اسان پڻ نه ٿا چاهيون ته ڪنيڪٽرن جي ڪوڊ کي پاڻ کي ڇڪي. في الحال ڪيترائي توسيع موجود آھن حاصل ڪرڻ لاءِ جيڪي توھان چاھيو ٿا:

• سوؤل - PHP لاءِ اعليٰ ڪارڪردگي وارو هم وقت ساز فريم ورڪ. علي بابا ۽ بيدو جي طور تي اهڙين انٽرنيٽ جي ديو طرفان استعمال ٿيل. نسخو 4.1.0 کان وٺي هڪ جادو طريقو ظاهر ٿيو آهي SwooleRuntime ::enableCoroutine()، جيڪو توهان کي اجازت ڏئي ٿو "هم وقت سازي PHP نيٽ ورڪ لائبريرين کي ڪوڊ جي هڪ لائن سان هم وقت سازي ۾ تبديل ڪريو."
• Async تازو ئي PHP ۾ غير مطابقت واري ڪم لاءِ هڪ تمام واعدو ڪندڙ واڌارو هو. آخر تائين ڇو؟ بدقسمتي سان، مون کي اڻڄاتل سببن لاء، مصنف مخزن کي ختم ڪري ڇڏيو ۽ منصوبي جي مستقبل جي قسمت واضح ناهي. مون کي ان کي استعمال ڪرڻو پوندو هڪ ڪانٽو کان. Swoole وانگر، هي ايڪسٽينشن توهان کي آساني سان توهان جي پتلون کي کلائي جي هڪ فلڪ سان آن ڪرڻ جي اجازت ڏئي ٿي ته جيئن TCP ۽ TLS اسٽريمز جي معياري عمل کي انهن جي غير مطابقت واري ورزن سان تبديل ڪري اسينڪروني کي فعال ڪري. اهو اختيار ذريعي ڪيو ويندو آهي "async.tcp = 1".
• متوازي - هڪ بلڪل نئين توسيع جيڪا مشهور جوئي واٽڪنز طرفان، ليکڪ جي اهڙي لائبريرين جهڙوڪ phpdbg، apcu، pthreads، pcov، uopz. ايڪسٽينشن PHP ۾ ملٽي ٿريڊنگ لاءِ هڪ API مهيا ڪري ٿي ۽ پيٿريڊس جي متبادل طور تي رکيل آهي. لائبريري جي هڪ اهم حد اها آهي ته اها صرف PHP جي ZTS (Zend Thread Safe) ورجن سان ڪم ڪري ٿي.

اسان ڪيئن جانچ ڪنداسين؟

اچو ته هڪ Tarantool مثال شروع ڪريون لکت-اڳتي لاگنگ معذور سان (wal_mode = ڪو به نه) ۽ وڌايو نيٽ ورڪ بفر (پڙهو هيڊ = 1 * 1024 * 1024). پهريون اختيار ڊسڪ سان ڪم کي ختم ڪري ڇڏيندو، ٻيو اهو ممڪن ٿيندو ته آپريٽنگ سسٽم بفر کان وڌيڪ درخواستون پڙهڻ ۽ انهي سان سسٽم ڪالن جو تعداد گھٽائي.

معيارن لاءِ جيڪي ڊيٽا سان ڪم ڪن ٿا (داخل ڪرڻ، حذف ڪرڻ، پڙهڻ، وغيره)، بينچ مارڪ شروع ڪرڻ کان اڳ، هڪ memtx اسپيس (ٻيهر) ٺاهي ويندي، جنهن ۾ بنيادي انڊيڪس ويلز ٺاهيا ويندا آهن ترتيب ڏنل انٽيجر ويلز جي جنريٽر طرفان. (سلسله).
خلائي 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>"}

Tuples تائين رسائي حاصل ڪئي وئي آھي بي ترتيب واري ڪي قدر استعمال ڪندي.

معيار پاڻ سرور ڏانهن هڪ واحد درخواست آهي، جيڪو 10,000 ڀيرا (انقلابن) تي عمل ڪيو ويو آهي، جنهن جي نتيجي ۾، ٻيهر ورهاڱي ۾ عمل ڪيو ويو آهي. ورجائي ورجايو ويندو آهي جيستائين 5 ورهاڱي جي وچ ۾ هر وقت انحراف 3٪ * جي قابل قبول غلطي جي اندر آهي. ان کان پوء، سراسري نتيجو ورتو وڃي. پروسيسر کي ٺڪرائڻ کان روڪڻ لاءِ تکرارن جي وچ ۾ 1 سيڪنڊ جو وقفو آهي. لوا جي گاربيج ڪليڪٽر کي هر عمل کان اڳ بند ڪيو ويندو آهي ۽ ان کي مڪمل ٿيڻ کان پوءِ شروع ڪرڻ تي مجبور ڪيو ويندو آهي. PHP عمل صرف بينچ مارڪ لاءِ ضروري ايڪسٽينشن سان شروع ڪيو ويو آهي، ان سان گڏ آئوٽ پُٽ بفرنگ کي فعال ڪيو ويو آهي ۽ ڪچرو گڏ ڪندڙ کي غير فعال ڪيو ويو آهي.

* انقلابن جو تعداد، ورجائي ۽ غلطي جي حد کي معيار جي سيٽنگن ۾ تبديل ڪري سگھجي ٿو.

ٽيسٽ ماحول

هيٺ شايع ٿيل نتيجا MacBookPro (2015) تي ڪيا ويا، آپريٽنگ سسٽم - Fedora 30 (kernel version 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 (+ پيچ 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 پروٽوڪول هڪ بائنري فارميٽ استعمال ڪري ٿو ميسيج پيڪ پيغامن کي ترتيب ڏيڻ لاء. پي اي سي ايل ڪنيڪٽر ۾، سيريلائيزيشن لائبريري جي کوٽائي ۾ لڪايل آهي ۽ صارف لينڊ ڪوڊ کان انڪوڊنگ جي عمل کي متاثر ڪري ٿو. ممڪن نه ٿو لڳي. هڪ خالص PHP کنیکٹر، ان جي برعڪس، معياري انڪوڊر کي وڌائڻ يا توهان جي پنهنجي عمل کي استعمال ڪندي انڪوڊنگ جي عمل کي ڪسٽمائي ڪرڻ جي صلاحيت ڏئي ٿو. دٻي مان ٻاهر موجود ٻه انڪوڊر موجود آهن، هڪ تي ٻڌل آهي msgpack/msgpack-php (رسمي MessagePack PECL توسيع)، ٻيو جاري آهي rybakit/msgpack (خالص PHP ۾).

ڪنيڪٽرن جو مقابلو ڪرڻ کان اڳ، اسان پي ايڇ پي ڪنيڪٽر لاءِ MessagePack انڪوڊرز جي ڪارڪردگي کي ماپينداسين ۽ وڌيڪ ٽيسٽن ۾ اسان اھو استعمال ڪنداسين جيڪو بھترين نتيجو ڏيکاريندو:

جيتوڻيڪ پي ايڇ پي ورزن (خالص) رفتار ۾ پي اي سي ايل جي واڌ کان گهٽ آهي، حقيقي منصوبن ۾ آئون اڃا تائين ان کي استعمال ڪرڻ جي صلاح ڏيندس rybakit/msgpack, ڇاڪاڻ ته سرڪاري MessagePack ايڪسٽينشن ۾ فارميٽ جي وضاحت صرف جزوي طور تي لاڳو ڪئي وئي آهي (مثال طور، ڪسٽم ڊيٽا جي قسمن لاءِ ڪا به سپورٽ ناهي، جنهن کان سواءِ توهان Decimal استعمال ڪرڻ جي قابل نه هوندا - هڪ نئون ڊيٽا جو قسم Tarantool 2.3 ۾ متعارف ڪرايو ويو آهي) ۽ هڪ آهي. ٻين جو تعداد مسئلا (PHP 7.4 سان مطابقت جي مسئلن سميت). خير، عام طور تي، پروجيڪٽ ڇڏيل نظر اچي ٿو.

تنهن ڪري، اچو ته ڪنيڪٽرز جي ڪارڪردگي کي هم وقت سازي موڊ ۾ ماپون:

جيئن گراف مان ڏسي سگھجي ٿو، PECL کنیکٹر (Tarantool) PHP کنیکٹر (ڪلائنٽ) جي مقابلي ۾ بهتر ڪارڪردگي ڏيکاري ٿو. پر اها تعجب جي ڳالهه ناهي، جنهنڪري، دير سان، سست زبان ۾ لاڳو ٿيڻ کان علاوه، اصل ۾ وڌيڪ ڪم ڪري ٿو: هر ڪال سان هڪ نئون اعتراض پيدا ٿئي ٿو. درخواست и جواب (چوڻ جي صورت ۾ - پڻ معيار، ۽ تازه ڪاري/اپسٽٽ جي صورت ۾ - آپريشنز)، الڳ الڳ ادارا ڪنيڪشن, پيڪر и هٽلر اهي پڻ مٿي شامل ڪن ٿا. ظاهر آهي، لچڪدار قيمت تي اچي ٿو. بهرحال، عام طور تي، PHP مترجم سٺي ڪارڪردگي ڏيکاري ٿو، جيتوڻيڪ اتي هڪ فرق آهي، اهو غير معمولي آهي ۽، شايد، اڃا به گهٽ ٿيندو جڏهن PHP 7.4 ۾ اڳ لوڊنگ استعمال ڪندي، PHP 8 ۾ JIT جو ذڪر نه ڪرڻ.

اچو ته اڳتي وڌون. Tarantool 2.0 متعارف ڪرايو SQL سپورٽ. اچو ته SQL پروٽوڪول استعمال ڪندي عملن کي چونڊيو، داخل ڪريو، تازه ڪاري ۽ حذف ڪرڻ جي ڪوشش ڪريون ۽ نتيجن جو مقابلو noSQL (بائنري) برابري سان ڪريون:

SQL جا نتيجا ڏاڍا متاثر ڪندڙ نه آھن (مون کي توھان کي ياد ڏيارڻ ڏيو ته اسان اڃا تائين هم وقت ساز موڊ جي جانچ ڪري رھيا آھيون). بهرحال، مان هن وقت کان اڳ پريشان نه ٿيندس؛ SQL سپورٽ اڃا تائين فعال ترقي هيٺ آهي (نسبتا تازو، مثال طور، سپورٽ شامل ڪئي وئي هئي) تيار ڪيل بيان) ۽، فهرست جي حساب سان مسئلن, SQL انجڻ مستقبل ۾ ڪيترن ئي اصلاحن مان گذرندو.

اسنڪ

خير، هاڻي اچو ته ڏسون ته ڪيئن Async ايڪسٽينشن اسان جي مدد ڪري سگهي ٿي مٿين نتيجن کي بهتر ڪرڻ ۾. هم وقت سازي پروگرامن کي لکڻ لاءِ، ايڪسٽينشن ڪوروٽين جي بنياد تي هڪ API مهيا ڪري ٿي، جنهن کي اسين استعمال ڪنداسين. اسان کي تجرباتي طور تي معلوم ٿئي ٿو ته اسان جي ماحول لاء ڪوروٽين جو بهترين نمبر 25 آهي:

10,000 آپريشنز کي 25 ڪوروٽينن ۾ ”پکڙيو“ ۽ ڏسو ته ڇا ٿئي ٿو:

في سيڪنڊ جي عملن جو تعداد 3 ڀيرا کان وڌيڪ وڌي ويو tarantool-php/client!

افسوس، PECL کنیکٹر ext-async سان شروع نه ٿيو.

SQL بابت ڇا؟

جئين توهان ڏسي سگهو ٿا، غير مطابقت واري موڊ ۾ بائنري پروٽوڪول ۽ SQL جي وچ ۾ فرق غلطي جي حد اندر ٿي ويو.

سوؤل

ٻيهر اسان ڳوليون ٿا ڪوروٽين جو بهترين نمبر، هن وقت سوول لاءِ:

اچو ته 25 تي روڪيون. اچو ته ساڳي چال کي ورجايون جيئن Async ايڪسٽينشن سان - 10,000 عملن کي 25 ڪوروٽين جي وچ ۾ ورهايو. ان کان علاوه، اسان هڪ ٻيو امتحان شامل ڪنداسين جنهن ۾ اسان سڀني ڪم کي 2 ٻن عملن ۾ ورهائينداسين (يعني، هر عمل 5,000 عملن کي 25 ڪوروٽين ۾ انجام ڏيندو). استعمال ڪندي پروسيس ٺاهيا ويندا Swoole پروسيس.

نتيجا:

Swole ڏيکاري ٿو ٿورڙو گهٽ نتيجو Async جي مقابلي ۾ جڏهن هڪ عمل ۾ هلندي آهي، پر 2 عملن سان تصوير ڊرامائي طور تي تبديل ٿي ويندي آهي (نمبر 2 اتفاق سان نه چونڊيو ويو هو؛ منهنجي مشين تي، اهو 2 عمل هئا جن بهترين نتيجا ڏيکاريا).

رستي ۾، Async ايڪسٽينشن وٽ پروسيس سان ڪم ڪرڻ لاءِ هڪ API پڻ آهي، پر اتي مون هڪ يا وڌيڪ پروسيس ۾ معيارن کي هلائڻ کان ڪو به فرق محسوس نه ڪيو (اهو ممڪن آهي ته مون ڪٿي گڙٻڙ ڪئي هجي).

SQL بمقابله بائنري پروٽوڪول:

جيئن Async سان، بائنري ۽ SQL عملن جي وچ ۾ فرق ختم ٿي ويو آهي asynchronous mode ۾.

متوازي

جيئن ته متوازي توسيع ڪوروٽين بابت نه آهي، پر ٿريڊن جي باري ۾، اچو ته متوازي ٿريڊن جي بهتر تعداد کي ماپون:

اهو منهنجي مشين تي 16 جي برابر آهي. اچو ته ڪنيڪٽر بينچ مارڪ کي 16 متوازي ٿريڊن تي هلون:

جئين توهان ڏسي سگهو ٿا، نتيجو اڃا به بهتر آهي غير مطابقت واري ملندڙن سان (2 پروسيس تي هلندڙ سوول کي ڳڻڻ نه). نوٽ ڪريو ته PECL کنیکٹر لاءِ، تازه ڪاري ۽ اپرٽ آپريشنز خالي آھن. اهو حقيقت جي ڪري آهي ته اهي عمل هڪ غلطي سان ناڪام ٿيا آهن - مون کي خبر ناهي ته اها غلطي هئي ext-parallel، ext-tarantool، يا ٻئي.

هاڻي اچو ته SQL ڪارڪردگي جو مقابلو ڪريو:

هم وقت سازي سان هلندڙ ڪنيڪٽرز لاءِ گراف سان هڪجهڙائي کي ڏسو؟

گڏو گڏ

۽ آخرڪار، اچو ته سڀني نتيجن کي هڪ گراف ۾ اختصار ڪريون مجموعي تصوير ڏسڻ لاءِ آزمائشي واڌارن لاءِ. اچو ته چارٽ ۾ صرف ھڪڙو نئون ٽيسٽ شامل ڪريون، جيڪو اسان اڃا تائين نه ڪيو آھي - اچو ته Async coroutines کي متوازي ۾ Parallel* استعمال ڪندي هلون. مٿين توسيع کي ضم ڪرڻ جو خيال اڳ ۾ ئي آهي بحث ڪيو ويو ليکڪ، پر ڪو به اتفاق نه ٿيو، توهان کي اهو ڪرڻو پوندو.

* متوازي سان سوول ڪوروٽين کي لانچ ڪرڻ ممڪن نه هو؛ اهو لڳي ٿو ته اهي واڌايون غير مطابقت رکندڙ آهن.

تنهن ڪري، آخري نتيجا:

سوچيم ته هڪ ٿڪل جي

منهنجي خيال ۾، نتيجا ڪافي قابل ٿي ويا، ۽ ڪجهه سببن لاء مون کي پڪ آهي ته اها حد نه آهي! ڇا توهان کي اهو فيصلو ڪرڻ جي ضرورت آهي هڪ حقيقي منصوبي ۾ صرف پنهنجي لاءِ، مان صرف ايترو چوندس ته منهنجي لاءِ اهو هڪ دلچسپ تجربو هو جيڪو توهان کي اندازو لڳائڻ جي اجازت ڏئي ٿو ته توهان گهٽ ۾ گهٽ ڪوشش سان هم وقت ساز TCP ڪنيڪٽر مان ڪيترو ”نچوڙي“ سگهو ٿا. جيڪڏهن توهان وٽ معيار کي بهتر ڪرڻ جا خيال آهن، مان توهان جي ڇڪڻ جي درخواست تي غور ڪندي خوش ٿيندس. لانچ جي هدايتن ۽ نتيجن سان گڏ سڀئي ڪوڊ الڳ الڳ ۾ شايع ٿيل آهن ذخيرو.

جو ذريعو: www.habr.com