टंकण के लिए Async, Swoole और समानांतर का उपयोग कर PHP कनेक्टर्स को तेज करना

PHP इकोसिस्टम में, टारेंटूल सर्वर के लिए वर्तमान में दो कनेक्टर हैं: आधिकारिक PECL एक्सटेंशन टारेंटूल / टारेंटूल-php, जो C में लिखा गया है, और tarantool-php / क्लाइंट PHP में लिखा गया है। मैं बाद वाले का लेखक हूं।

इस लेख में मैं इन दोनों पुस्तकालयों के प्रदर्शन परीक्षण के परिणामों को साझा करना चाहता हूं और यह बताता हूं कि आप कोड में न्यूनतम बदलाव के साथ 3x-5x प्रदर्शन सुधार ( सिंथेटिक परीक्षणों पर! ) कैसे प्राप्त कर सकते हैं।

हम क्या परीक्षण करने जा रहे हैं?

हम समान रूप से, समानांतर में और अतुल्यकालिक रूप से लॉन्च किए गए उपर्युक्त सिंक्रोनस कनेक्टर्स का परीक्षण करेंगे। इसके अलावा, हम कनेक्टर्स सोर्स कोड के लिए कोई बदलाव नहीं चाहते हैं। फिलहाल कई एक्सटेंशन उपलब्ध हैं जो काम कर सकते हैं:

• Swoole , PHP के लिए एक उच्च-प्रदर्शन अतुल्यकालिक ढांचा। इंटरनेट दिग्गजों जैसे अलीबाबा और Baidu द्वारा उपयोग किया जाता है। संस्करण ०.१.० के बाद से, अद्भुत रनटाइम हुक स्वोएल \ रंटाइम :: enableCoroutine () दिखाई दिया है, जिससे "सिंक्रोनाइज़्ड PHP नेटवर्क लाइब्रेरीज़ को कोड की सिंगल लाइन का उपयोग करके सह-रूटीन लाइब्रेरी में बदलने की अनुमति मिलती है"।
• Async, हाल ही तक PHP में अतुल्यकालिक काम के लिए एक बहुत ही आशाजनक विस्तार। हाल तक क्यों? दुर्भाग्य से, जिन कारणों से मुझे नहीं पता है, लेखक ने भंडार को हटा दिया और परियोजना का भविष्य संदिग्ध है। मैं एक कांटे का उपयोग करूंगा। स्वोइल की तरह, यह एक्सटेंशन PHP के डिफ़ॉल्ट स्ट्रीम कार्यान्वयन को अपने async समकक्ष के साथ बदलकर एसिंक्रोनस मोड को सक्रिय करना आसान बनाता है। यह विकल्प " async.tcp = 1 " के माध्यम से किया जाता है।
• समानांतर , जाने-माने जो वाटकिंस से एक बहुत ही नया विस्तार, phpdbg, apcu, pthreads, pcov, uopz जैसे पुस्तकालयों के लेखक। विस्तार PHP के लिए एक बहु-सूत्रण एपीआई प्रदान करता है और इसे pthreads के प्रतिस्थापन के रूप में तैनात किया गया है। पुस्तकालय की एक महत्वपूर्ण सीमा यह है कि यह केवल PHP के ZTS (Zend Thread Safe) संस्करण के साथ काम करता है।

हम परीक्षण कैसे कर रहे हैं?

हम राइट- फॉर लॉगिंग डिसेबल ( वाल_मोड = कोई नहीं ) और एक विस्तारित नेटवर्क बफर ( रीडहेड = 1 * 1024 * 1024 ) के साथ एक टारेंटूल इंस्टेंस चलाएंगे। पहला विकल्प डिस्क ड्राइव में IO संचालन को रोक देगा, दूसरा ऑपरेटिंग सिस्टम बफर से अधिक अनुरोध पढ़ने की अनुमति देगा और इस प्रकार सिस्टम कॉल की संख्या को कम कर देगा।

बेंचमार्क के लिए जो डेटा (प्रविष्टि, विलोपन, रीडिंग, आदि) के साथ काम करते हैं, एक बेंचमार्क शुरू होने से पहले एक मेम्टैक्स स्पेस (पुनः-) बनाया जाएगा, और इस स्पेस के लिए शुरुआती इंडेक्स वैल्यू सीक्वेंस जनरेटर द्वारा बनाई जाएगी।

अंतरिक्ष का डीडीएल इस प्रकार है:

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, 'tuple_' .. id} 

यादृच्छिक कुंजी मान का उपयोग करके टुपल्स को एक्सेस किया जाता है।

बेंचमार्क उस सर्वर के लिए एक एकल अनुरोध है जिसे 10,000 बार (क्रांतियों) निष्पादित किया जाता है, जो बदले में पुनरावृत्तियों में निष्पादित होता है। पुनरावृत्तियों को तब तक दोहराया जाता है जब तक कि 5 पुनरावृत्तियों के बीच विचलन 3% त्रुटि मार्जिन * के भीतर न हो। उसके बाद, औसत परिणाम लिया जाता है। पुनरावृत्तियों के बीच, सीपीयू को थ्रॉटलिंग से रोकने के लिए 1 सेकंड का ठहराव है। Lua कचरा कलेक्टर प्रत्येक पुनरावृत्ति से पहले अक्षम हो जाता है और पुनरावृत्ति समाप्त होने के बाद शुरू करने के लिए मजबूर किया जाता है। PHP प्रक्रिया को केवल बेंचमार्क के लिए आवश्यक एक्सटेंशन के साथ लॉन्च किया जाता है, जिसमें आउटपुट बफ़रिंग सक्षम और कचरा कलेक्टर अक्षम होता है।

* क्रांतियों, पुनरावृत्तियों और त्रुटि सीमा की संख्या को बेंचमार्क सेटिंग्स में बदला जा सकता है।

पर्यावरण का परीक्षण करें

नीचे पोस्ट किए गए परिणाम MacBookPro (मध्य 2015) पर Fedora 30 (कर्नेल संस्करण 5.3.8-200.fc30.x86_64) के साथ बनाए गए थे। टारनटूल को " --network होस्ट " सेटिंग के साथ डॉक में लॉन्च किया गया था।

पैकेज संस्करण:

टारनटूल: 2.3.0-115-g5ba5ed37e
डॉकर: 03/19/3, a872fc2f86 का निर्माण करें
PHP: 7.3.11 (cli) (निर्मित: 22 अक्टूबर 2019 08:11:04)
टैरनटूल / ग्राहक: 0.6.0
rybakit / msgpack: 0.6.1
पूर्व-टारेंटूल: 0.3.2 (पैच) *
ext-msgpack: 2.0.3
ext-async: 0.3.0-8c1da46
ext-swoole: 4.4.12
ext-समानांतर: 1.1.3

* दुर्भाग्य से, आधिकारिक कनेक्टर PHP> 7.2 के साथ काम नहीं करता है। PHP 7.3 पर एक्सटेंशन को संकलित करने और चलाने के लिए, मुझे एक पैच का उपयोग करना पड़ा।

परिणाम

सिंक (डिफ़ॉल्ट)

टैरेंटूल प्रोटोकॉल संदेशों को क्रमबद्ध करने के लिए मैसेजपैक बाइनरी प्रारूप का उपयोग करता है। PECL कनेक्टर में, क्रमांकन लाइब्रेरी के अंदर गहराई से छिपा हुआ है, इसलिए उपयोगकर्ता कोड से एन्कोडिंग प्रक्रिया को प्रभावित करना असंभव प्रतीत होता है । इसके विपरीत, शुद्ध PHP कनेक्टर एन्कोडिंग प्रक्रिया को अनुकूलित करने की क्षमता प्रदान करता है, या तो मानक एन्कोडर में से एक का विस्तार करके, या अपने स्वयं के कार्यान्वयन का उपयोग करके। दो एनकोडर बॉक्स से बाहर उपलब्ध हैं: एक msgpack / msgpack-php (आधिकारिक MessagePack PECL एक्सटेंशन) पर आधारित है और दूसरा एक rybakit / msgpack (शुद्ध PHP) पर आधारित है।

इससे पहले कि हम कनेक्टर्स की तुलना करने के लिए आगे बढ़ें, आइए PHP कनेक्टर के लिए MessagePack एन्कोडर के प्रदर्शन को मापें, ताकि हम अपने परीक्षणों में आगे के सर्वश्रेष्ठ प्रदर्शनकर्ता का उपयोग करें:


हालाँकि, PHP संस्करण (शुद्ध) PECL एक्सटेंशन जितना तेज़ नहीं है, फिर भी मैं वास्तविक परियोजनाओं में rybakit / msgpack का उपयोग करने की सलाह दूंगा , क्योंकि आधिकारिक PECL एक्सटेंशन केवल आंशिक रूप से MessagePack विनिर्देश को लागू करता है (उदाहरण के लिए कस्टम डेटा प्रकारों के लिए कोई समर्थन नहीं है,) और इसके बिना आप दशमलव का उपयोग नहीं कर सकते - टारेंटूल 2.3 में पेश किया गया एक नया डेटा प्रकार) और इसमें कई अन्य मुद्दे (PHP 7.4 के साथ संगतता मुद्दे सहित) हैं। और परियोजना सामान्य रूप से परित्यक्त दिखती है।

तो, चलो तुल्यकालिक मोड में कनेक्टर्स के प्रदर्शन को मापते हैं:


जैसा कि आप ग्राफ से देख सकते हैं, PECL कनेक्टर (टारेंटूल) PHP कनेक्टर (क्लाइंट) से बेहतर प्रदर्शन करता है। यह आश्चर्य की बात नहीं है, यह देखते हुए कि बाद में, धीमी भाषा में लागू होने के अलावा, वास्तव में अधिक काम करता है: हर अनुरोध के साथ एक नया अनुरोध और प्रतिक्रिया ऑब्जेक्ट बनाया जाता है (चयन के मामले में भी मानदंड है , और अपडेट / अपग्रेड का संचालन होता है ), कनेक्शन , पैकर और हैंडलर भी कुछ ओवरहेड जोड़ते हैं। यह कहना अनावश्यक है कि उच्च लचीलापन लागत के साथ आता है। हालाँकि, PHP दुभाषिया सामान्य रूप से अच्छा प्रदर्शन दिखाता है। हालांकि एक अंतर है, यह महत्वहीन है और PHP 7.4 में प्री-लोडिंग का उपयोग करने के साथ कम हो सकता है, PHP 8 में JIT का उल्लेख नहीं करने के लिए।

अभी चल रहा है। टारेंटूल 2.0 ने एसक्यूएल सपोर्ट पेश किया। आइए SQL प्रोटोकॉल का उपयोग करके ऑपरेशन का चयन करें, सम्मिलित करें, अपडेट करें और हटाएं और noSQL (बाइनरी) समकक्षों के साथ परिणामों की तुलना करने की कोशिश करें:


SQL परिणाम उस प्रभावशाली नहीं हैं (मुझे याद दिलाएं कि हम अभी भी तुल्यकालिक मोड का परीक्षण कर रहे हैं)। हालाँकि, मैं समय से पहले इसके बारे में परेशान नहीं होता: एसक्यूएल समर्थन अभी भी सक्रिय विकास के तहत है (उदाहरण के लिए, तैयार बयानों के लिए समर्थन बहुत समय पहले नहीं जोड़ा गया है) और, मुद्दों की सूची के अनुसार, एसक्यूएल इंजन करेगा भविष्य में कई अनुकूलन प्राप्त करें।

async

ठीक है, अब देखते हैं कि ऊपर दिए गए परिणामों को बेहतर बनाने में Async एक्सटेंशन कैसे हमारी मदद कर सकता है। एसिंक्रोनस प्रोग्रामिंग के लिए, एक्सटेंशन एक कोरआउट-आधारित एपीआई प्रदान करता है, जिसे हम यहां उपयोग करने जा रहे हैं। सबसे पहले, जैसा कि हम परीक्षण के माध्यम से पता लगाते हैं, हमारे पर्यावरण के लिए कोरटाइन की इष्टतम संख्या 25 है:


फिर हमने 25 कॉरआउट्स में 10,000 ऑपरेशन फैलाए और परिणाम की जाँच की:


PHP कनेक्टर के लिए प्रति सेकंड संचालन की संख्या 3 गुना से अधिक हो गई है! अफसोस की बात है कि PECL कनेक्टर एक्स-एसिंक्स के साथ लॉन्च करने में विफल रहा।

और SQL के बारे में क्या?


जैसा कि आप देख सकते हैं, अतुल्यकालिक मोड में बाइनरी प्रोटोकॉल और एसक्यूएल के बीच का अंतर त्रुटि के मार्जिन के भीतर आता है।

Swoole

फिर, आइए, इस बार स्वोइल के लिए, कॉरआउट्स की अधिकतम संख्या निर्धारित करें:


आइए 25 लेते हैं। अब, Async एक्सटेंशन के साथ एक ही चाल को दोहराते हुए: 25 कोरआउट के बीच 10,000 ऑपरेशन वितरित करें। इसके अलावा, चलो एक और परीक्षण जोड़ते हैं, जहां हम पूरी चीज को दो प्रक्रियाओं में विभाजित करते हैं (यानी प्रत्येक प्रक्रिया 25 कोरटाइन्स में 5,000 ऑपरेशन करेगी)। Swoole \ Process की मदद से प्रक्रियाएं बनाई जाएंगी ।

परिणाम:


स्वोइल एक प्रक्रिया में चलने पर Async की तुलना में थोड़ा कम प्रदर्शन दिखाता है, लेकिन 2 प्रक्रियाओं के साथ तस्वीर में काफी बदलाव होता है (2 को दुर्घटना से नहीं चुना जाता है, मेरी मशीन पर इस सटीक संख्या में प्रक्रियाओं ने सबसे अच्छा परिणाम दिखाया)।

वैसे, Async एक्सटेंशन में प्रक्रियाओं के साथ काम करने के लिए एक एपीआई भी है, लेकिन मैंने एक ही प्रक्रिया में या कई प्रक्रियाओं में बेंचमार्क लॉन्च करने के बीच कोई अंतर नहीं देखा (यह संभव है कि हालांकि मैंने कुछ गलतियां की हैं)।

एसक्यूएल बनाम बाइनरी प्रोटोकॉल:


Async के साथ, बाइनरी और SQL ऑपरेशन के बीच का अंतर एसिंक्रोनस मोड में समतल हो जाता है।

समानांतर

चूंकि समानांतर विस्तार थ्रेड्स के बारे में है, कोरटाइन नहीं, हम समानांतर थ्रेड्स की इष्टतम संख्या को मापने के लिए हैं:


यह मेरी मशीन पर 16 है। अब 16 समानांतर थ्रेड्स पर कनेक्टर्स बेंचमार्क करते हैं:


जैसा कि आप देख सकते हैं, परिणाम अतुल्यकालिक एक्सटेंशन (2 प्रक्रियाओं के साथ स्वोल को छोड़कर) के साथ भी बेहतर है। ध्यान दें कि PECL कनेक्टर के लिए, अपडेट और अपग्रेड ऑपरेशन का कोई बार नहीं है। इसका कारण यह है कि उन ऑपरेशन एक त्रुटि के साथ दुर्घटनाग्रस्त हो गए, और मुझे यकीन नहीं है कि क्या दोष देना है: ext-समानांतर, या ext-tarantool, या दोनों।

अब तुलना में SQL प्रदर्शन जोड़ें:


क्या आपने कनेक्टर के लिए ग्राफ में समान रूप से लॉन्च किए गए समानों पर ध्यान दिया है?

सभी एक में

अंत में, परीक्षण के तहत एक्सटेंशन के लिए पूरी तस्वीर देखने के लिए एक ग्राफ में सभी परिणामों को मिलाएं। हम ग्राफ में केवल एक नया परीक्षण जोड़ने जा रहे हैं, जो हमने अभी तक नहीं किया है: समानांतर * का उपयोग करके समानांतर में Async coroutines लॉन्च करें। उपरोक्त एक्सटेंशन को एकीकृत करने के विचार पर पहले ही लेखकों द्वारा चर्चा की जा चुकी है लेकिन कोई सहमति नहीं बन पाई है, इसलिए हमें इसे स्वयं करना होगा।

* मैं समानांतर के साथ स्वोइल कोरटाइन्स लॉन्च करने में विफल रहा; ऐसा लगता है कि ये एक्सटेंशन असंगत हैं।

अब, अंतिम परिणाम:

निष्कर्ष

मेरे दिमाग में, परिणाम काफी सभ्य हैं, लेकिन कुछ ऐसा है जो मुझे विश्वास दिलाता है कि हम अभी तक वहां नहीं हैं! यदि आपके पास बेंचमार्क में सुधार करने के बारे में कोई विचार है, तो मुझे आपके पुल अनुरोध की समीक्षा करने में खुशी होगी। लॉन्च निर्देशों और परिणामों के साथ सभी कोड एक समर्पित भंडार में प्रकाशित होते हैं।

आपको यह तय करने के लिए छोड़ना कि क्या आपको वास्तविक परियोजना में इसकी आवश्यकता होगी, मैं सिर्फ इतना कहूंगा कि यह एक रोमांचक प्रयोग था जिसने मुझे अनुमान लगाने की अनुमति दी कि न्यूनतम प्रयास के साथ एक तुल्यकालिक टीसीपी-कनेक्टर से कितना बाहर किया जा सकता है।