د Async، Swoole او Parallel په کارولو سره د Tarantool لپاره د PHP نښلونکو ګړندی کول

په PHP اکوسیستم کې اوس مهال د ټرانټول سرور سره کار کولو لپاره دوه نښلونکي شتون لري - دا د PECL رسمي توسیع دی tarantool/tarantool-phpپه C کې لیکل شوی، او tarantool-php/client، په PHP کې لیکل شوی. زه د وروستي لیکوال یم.

پدې مقاله کې ، زه غواړم د دواړو کتابتونونو د فعالیت ازموینې پایلې شریکې کړم او وښیم چې څنګه په کوډ کې د لږترلږه بدلونونو سره ، تاسو کولی شئ د 3-5 فعالیت زیاتوالی ترلاسه کړئ (په مصنوعي ازموینو کې!).

موږ به څه ازموینه وکړو؟

موږ به پورته ذکر شوي ازموینه وکړو همغږي نښلونکي په غیر متوازی ډول، موازي او غیر متوازی ډول چلوي. 🙂 موږ هم نه غواړو پخپله د نښلونکو کوډ ته لاس ورکړو. اوس مهال د هغه څه ترلاسه کولو لپاره ډیری توسیعونه شتون لري چې تاسو یې غواړئ:

• سوول - د PHP لپاره د لوړ فعالیت غیر متناسب چوکاټ. د ورته انټرنیټ لویانو لخوا کارول کیږي لکه علی بابا او بیدو. د 4.1.0 نسخه راهیسې د جادو میتود څرګند شوی SwooleRuntime ::enableCoroutine()، کوم چې تاسو ته اجازه درکوي "د پی ایچ پی شبکې کتابتونونه د کوډ د یوې کرښې سره غیر متناسب ته واړوئ."
• Async تر دې وروستیو پورې په PHP کې د غیر متناسب کار لپاره خورا ژمن توسیع و. ولې تر دې وروستیو پورې؟ له بده مرغه، زما لپاره د نامعلوم دلیل لپاره، لیکوال ذخیره حذف کړه او د پروژې راتلونکی برخلیک ناڅرګند دی. زه باید دا وکاروم یو له ټوټو څخه د سوول په څیر، دا تمدید تاسو ته اجازه درکوي په اسانۍ سره خپل پتلون د مغز د فلک سره وګرځوئ ترڅو د TCP او TLS جریانونو معیاري پلي کولو سره د دوی غیر متناسب نسخو سره ځای په ځای کولو سره اسینکروني فعال کړئ. دا د اختیار له لارې ترسره کیږي "async.tcp = 1".
• موازي - د phpdbg، apcu، pthreads، pcov، uopz په څیر د داسې کتابتونونو لیکوال، د پیژندل شوي جو واټکینز څخه یو څه نوی توسیع. تمدید په PHP کې د ملټي ریډینګ لپاره API چمتو کوي او د pthreads لپاره د بدیل په توګه موقعیت لري. د کتابتون یو مهم محدودیت دا دی چې دا یوازې د PHP د ZTS (Zend Thread Safe) نسخه سره کار کوي.

موږ به څنګه ازموینه وکړو؟

راځئ چې د لیکلو مخکې لاګنګ غیر فعال شوي سره د ترنټول مثال پیل کړو (wal_mode = هیڅ نه) او د شبکې بفر زیات شوی (readahead = 1*1024*1024). لومړی اختیار به د ډیسک سره کار له مینځه ویسي ، دوهم به دا امکان رامینځته کړي چې د عملیاتي سیسټم بفر څخه ډیرې غوښتنې لوستل شي او پدې توګه د سیسټم تلیفونونو شمیر کم کړي.

د بنچمارکونو لپاره چې د ډیټا سره کار کوي (داخلول ، حذف کول ، لوستل ، او داسې نور) ، د بنچمارک پیل کولو دمخه ، د میمټکس ځای به (بیا) رامینځته شي ، په کوم کې چې لومړني شاخص ارزښتونه د ترتیب شوي عددي ارزښتونو جنریټر لخوا رامینځته کیږي (سلسله).
فضا 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) کې جوړې شوې، عملیاتي سیسټم - فیډورا 30 (د کرنل نسخه 5.3.8-200.fc30.x86_64). ترنتول د پیرامیټر سره په ډاکر کې پیل شوی و "--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 سره کار نه کوي. په پی ایچ پی 7.3 کې د توسیع تالیف او چلولو لپاره، ما باید کار واخیست پیچ.

پایلې

همغږي حالت

د ترانتول پروتوکول د بائنری بڼه کاروي پیغام پیک د پیغامونو لړۍ کول. د PECL نښلونکي کې، سریال کول د کتابتون په ژورو کې پټ شوي او د کارن لینډ کوډ څخه د کوډ کولو پروسه اغیزه کوي ممکن نه ښکاري. یو خالص پی ایچ پی نښلونکی، په برعکس، د معیاري کوډر پراخولو یا ستاسو د خپل پلي کولو په کارولو سره د کوډ کولو پروسې دودیز کولو وړتیا چمتو کوي. د بکس څخه بهر دوه کوډ کونکي شتون لري، یو یې پر بنسټ والړ دی msgpack/msgpack-php (د رسمي پیغام پیک PECL توسیع)، بل روان دی rybakit/msgpack (په خالص پی ایچ پی کې).

د نښلونکو پرتله کولو دمخه، موږ به د پی ایچ پی نښلونکي لپاره د میسج پیک کوډ کونکو فعالیت اندازه کړو او په نورو ازموینو کې به موږ هغه وکاروو چې غوره پایله ښیې:

که څه هم د PHP نسخه (خالص) په سرعت کې د PECL توسیع څخه ټیټه ده، په ریښتینې پروژو کې زه به بیا هم د دې کارولو وړاندیز وکړم rybakit/msgpack، ځکه چې په رسمي میسج پیک توسیع کې د فارمیټ توضیحات یوازې په جزوي ډول پلي کیږي (د مثال په توګه ، د دودیز ډیټا ډولونو لپاره هیڅ ملاتړ شتون نلري ، پرته لدې چې تاسو نشئ کولی ډیسیمال وکاروئ - د ډیټا نوی ډول چې په Tarantool 2.3 کې معرفي شوی) او یو لري. د نورو شمیر ستونزې (د پی ایچ پی 7.4 سره د مطابقت مسلو په شمول). ښه، په عموم کې، پروژه پریښودل کیږي.

نو، راځئ چې په همغږي حالت کې د نښلونکو فعالیت اندازه کړو:

لکه څنګه چې د ګراف څخه لیدل کیدی شي، د PECL نښلونکی (Tarantool) د 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 عملیات ترسره کړي). پروسې به په کارولو سره رامینځته شي SwooleProcess.

پایلې:

سوول د Async په پرتله یو څه ټیټه پایله ښیې کله چې په یوه پروسه کې پرمخ وړل کیږي ، مګر د 2 پروسو سره عکس په ډراماتیک ډول بدلیږي (2 شمیره د چانس لخوا نه وه غوره شوې؛ زما په ماشین کې ، دا 2 پروسې وې چې غوره پایله یې ښودلې).

د لارې په توګه، د Async توسیع د پروسو سره کار کولو لپاره API هم لري، مګر هلته ما په یو یا ډیرو پروسو کې د بنچمارک چلولو څخه کوم توپیر ندی لیدلی (دا ممکنه ده چې ما چیرته ګډوډ کړی وي).

SQL vs بائنری پروتوکول:

لکه څنګه چې د Async سره، د بائنری او SQL عملیاتو ترمنځ توپیر په اسینکرونس حالت کې له منځه وړل کیږي.

موازي

څرنګه چې موازي توسیع د کوروټینونو په اړه نه دی، مګر د تارونو په اړه، راځئ چې د موازي تارونو غوره شمیر اندازه کړو:

دا زما په ماشین کې د 16 سره مساوي دی. راځئ چې په 16 موازي تارونو کې د نښلونکي بنچمارک چلوو:

لکه څنګه چې تاسو لیدلی شئ، پایله د غیر متناسب تمدیدونو په پرتله حتی غوره ده (په 2 پروسو کې د چلولو سوول حساب نه کول). په یاد ولرئ چې د PECL نښلونکي لپاره، د تازه کولو او پورته کولو عملیات خالي دي. دا د دې حقیقت له امله دی چې دا عملیات د یوې تېروتنې سره ناکام شوي - زه نه پوهیږم چې دا د ext-parallel، ext-tarantool، یا دواړو غلطي وه.

اوس راځئ چې د SQL فعالیت پرتله کړو:

د ګراف سره ورته والی په پام کې ونیسئ د نښلونکو لپاره چې په همغږي ډول پرمخ ځي؟

په ګډه

او په نهایت کې ، راځئ چې ټولې پایلې په یوه ګراف کې لنډیز کړو ترڅو د ازمول شوي توسیع لپاره عمومي عکس وګورئ. راځئ چې په چارټ کې یوازې یوه نوې ازموینه اضافه کړو، کوم چې موږ تر اوسه نه دی ترسره کړی - راځئ چې د موازي * په کارولو سره په موازي توګه Async کورټینونه پرمخ بوځو. د پورتنیو توسیعونو د یوځای کولو مفکوره لا دمخه ده بحث وشو لیکوالان، مګر هیڅ توافق ته ونه رسیدل، تاسو باید دا پخپله ترسره کړئ.

* دا ممکنه نه وه چې د موازي سره سوول کورټینونه پیل کړي؛ داسې بریښي چې دا توسیعونه مطابقت نلري.

نو، وروستۍ پایلې:

پر ځای د يو پایلې

زما په اند، پایلې د پام وړ وړ وې، او د ځینو دلیلونو لپاره زه ډاډه یم چې دا حد نه دی! که تاسو اړتیا لرئ دا یوازې د خپل ځان لپاره په ریښتیني پروژه کې پریکړه وکړئ ، زه به یوازې ووایم چې دا زما لپاره په زړه پوري تجربه وه چې تاسو ته اجازه درکوي ارزونه وکړئ چې تاسو د لږترلږه هڅې سره د همغږي TCP نښلونکي څخه څومره "چوچ" کولی شئ. که تاسو د بنچمارکونو د ښه کولو لپاره نظرونه لرئ، زه به خوشحاله شم چې ستاسو د پلولو غوښتنه په پام کې ونیسم. د لانچ لارښوونو او پایلو سره ټول کوډ په جلا توګه خپور شوی ذخیره.

سرچینه: www.habr.com