Async, Swoole र Parallel को प्रयोग गरेर Tarantool को लागी PHP कनेक्टरहरु लाई गति दिदै

PHP इकोसिस्टममा हाल Tarantool सर्भरसँग काम गर्नका लागि दुई कनेक्टरहरू छन् - यो आधिकारिक PECL विस्तार हो। tarantool/tarantool-php, C मा लेखिएको, र tarantool-php/client, PHP मा लेखिएको। म पछिल्लोको लेखक हुँ।

यस लेखमा, म दुबै पुस्तकालयहरूको प्रदर्शन परीक्षणको नतिजाहरू साझा गर्न चाहन्छु र देखाउन चाहन्छु कि कसरी, कोडमा न्यूनतम परिवर्तनहरूसँग, तपाइँले 3-5 प्रदर्शन वृद्धि हासिल गर्न सक्नुहुन्छ (सिंथेटिक परीक्षणहरूमा!).

हामी के परीक्षण गर्नेछौं?

हामी माथि उल्लेखित परीक्षण गर्नेछौं सिंक्रोनस एसिन्क्रोनस, समानान्तर र एसिन्क्रोनस-समानान्तर रूपमा चल्ने कनेक्टरहरू। 🙂 हामी पनि जडानकर्ताहरूको कोड आफैं छुन चाहँदैनौं। तपाईले चाहानु भएको कुरा प्राप्त गर्न हाल धेरै विस्तारहरू उपलब्ध छन्:

• स्वोल - PHP को लागि उच्च प्रदर्शन एसिन्क्रोनस फ्रेमवर्क। Alibaba र Baidu जस्ता इन्टरनेट दिग्गजहरू द्वारा प्रयोग गरिन्छ। संस्करण 4.1.0 देखि एक जादुई विधि देखा पर्यो SwooleRuntime ::enableCoroutine(), जसले तपाईंलाई "सिंक्रोनस PHP नेटवर्क लाइब्रेरीहरूलाई कोडको एक लाइनको साथ एसिन्क्रोनसमा रूपान्तरण गर्न" अनुमति दिन्छ।
• Async हाल सम्म PHP मा एसिन्क्रोनस कार्य को लागी एक धेरै आशाजनक विस्तार थियो। हालसम्म किन ? दुर्भाग्यवश, मलाई अज्ञात कारणको लागि, लेखकले भण्डार हटायो र परियोजनाको भविष्यको भाग्य अस्पष्ट छ। मैले यसलाई प्रयोग गर्नुपर्नेछ एक काँटाबाट। Swoole जस्तै, यो एक्सटेन्सनले TCP र TLS स्ट्रिमहरूको मानक कार्यान्वयनलाई तिनीहरूको एसिन्क्रोनस संस्करणहरूसँग प्रतिस्थापन गरेर एसिन्क्रोनी सक्षम गर्नको लागि नाडीको फ्लिकको साथ सजिलैसँग आफ्नो प्यान्ट खोल्न अनुमति दिन्छ। यो विकल्प मार्फत गरिन्छ "async.tcp = 1"।
• समानांतर - phpdbg, apcu, pthreads, pcov, uopz जस्ता पुस्तकालयहरूको लेखक जो प्रसिद्ध जो वाटकिन्सबाट एकदम नयाँ विस्तार। एक्सटेन्सनले PHP मा मल्टिथ्रेडिङको लागि API प्रदान गर्दछ र pthreads को प्रतिस्थापनको रूपमा राखिएको छ। पुस्तकालयको महत्त्वपूर्ण सीमा भनेको यो हो कि यसले PHP को ZTS (Zend Thread Safe) संस्करणमा मात्र काम गर्छ।

हामी कसरी परीक्षण गर्नेछौं?

लेख्ने-अगाडि लगिङ असक्षम पारिएकोसँग टारन्टुल उदाहरण सुरु गरौं (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%* को स्वीकार्य त्रुटि भित्र नभएसम्म पुनरावृत्तिहरू दोहोर्याइन्छ। यस पछि, औसत परिणाम लिइन्छ। प्रोसेसरलाई थ्रोटल गर्नबाट रोक्नको लागि पुनरावृत्तिहरू बीच १ सेकेन्ड पज छ। लुआको फोहोर सङ्कलन प्रत्येक पुनरावृत्ति अघि असक्षम हुन्छ र यो पूरा भएपछि सुरु गर्न बाध्य हुन्छ। PHP प्रक्रिया केवल बेन्चमार्कको लागि आवश्यक विस्तारहरू, आउटपुट बफरिङ सक्षम र फोहोर सङ्कलन असक्षम पारिएको साथ सुरू गरिएको छ।

* क्रान्तिहरूको संख्या, पुनरावृत्ति र त्रुटि थ्रेसहोल्ड बेन्चमार्क सेटिङहरूमा परिवर्तन गर्न सकिन्छ।

परिक्षण वातावरण

तल प्रकाशित परिणामहरू MacBookPro (2015), अपरेटिङ सिस्टम - Fedora 30 (kernel संस्करण 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
ext-parallel: 1.1.3

* दुर्भाग्यवश, आधिकारिक कनेक्टरले PHP संस्करण > 7.2 सँग काम गर्दैन। PHP 7.3 मा विस्तार कम्पाइल र चलाउन, मैले प्रयोग गर्नुपर्‍यो प्याच.

Результаты

सिंक्रोनस मोड

Tarantool प्रोटोकल बाइनरी ढाँचा प्रयोग गर्दछ MessagePack सन्देशहरू क्रमबद्ध गर्न। PECL कनेक्टरमा, क्रमबद्धता पुस्तकालयको गहिराइमा लुकेको छ र प्रयोगकर्ताल्याण्ड कोडबाट इन्कोडिङ प्रक्रियालाई असर गर्छ। सम्भव देखिदैन। एक शुद्ध PHP कनेक्टर, यसको विपरित, मानक एन्कोडर विस्तार गरेर वा आफ्नै कार्यान्वयन प्रयोग गरेर एन्कोडिङ प्रक्रिया अनुकूलन गर्ने क्षमता प्रदान गर्दछ। त्यहाँ बक्स बाहिर दुई एन्कोडरहरू उपलब्ध छन्, एउटामा आधारित छ msgpack/msgpack-php (आधिकारिक MessagePack PECL विस्तार), अर्को सक्रिय छ rybakit/msgpack (शुद्ध PHP मा)।

कनेक्टरहरू तुलना गर्नु अघि, हामी PHP कनेक्टरको लागि MessagePack एन्कोडरहरूको कार्यसम्पादन मापन गर्नेछौं र थप परीक्षणहरूमा हामी सबैभन्दा राम्रो नतिजा देखाउने एउटा प्रयोग गर्नेछौं:

यद्यपि PHP संस्करण (शुद्ध) गतिमा PECL विस्तार भन्दा कम छ, वास्तविक परियोजनाहरूमा म अझै पनि यसलाई प्रयोग गर्न सिफारिस गर्दछु। rybakit/msgpack, किनभने आधिकारिक MessagePack एक्सटेन्सनमा ढाँचा विशिष्टता आंशिक रूपमा मात्र लागू गरिएको छ (उदाहरणका लागि, अनुकूलन डेटा प्रकारहरूको लागि कुनै समर्थन छैन, जसको बिना तपाइँ दशमलव प्रयोग गर्न सक्षम हुनुहुने छैन - 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

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

10,000 कोरुटिनहरूमा १०,००० अपरेशनहरू "स्प्रेड गर्नुहोस्" र हेर्नुहोस् के हुन्छ:

प्रति सेकेन्ड सञ्चालनको संख्या 3 गुणा भन्दा बढेको छ tarantool-php/client!

दुखको कुरा, PECL कनेक्टर ext-async सँग सुरु भएन।

SQL को बारेमा के हो?

तपाईले देख्न सक्नुहुन्छ, एसिन्क्रोनस मोडमा बाइनरी प्रोटोकल र SQL बीचको भिन्नता त्रुटिको मार्जिन भित्र भयो।

स्वोल

फेरि हामी कोरुटिनहरूको इष्टतम संख्या फेला पार्छौं, यस पटक स्वूलको लागि:

25 मा रोकौं। Async एक्सटेन्सनको रूपमा उही ट्रिक दोहोर्याउनुहोस् - 10,000 कोरुटिनहरू बीच 25 सञ्चालनहरू वितरण गर्नुहोस्। यसको अतिरिक्त, हामी अर्को परीक्षण थप्नेछौं जसमा हामी सबै कामलाई 2 दुई प्रक्रियाहरूमा विभाजन गर्नेछौं (अर्थात, प्रत्येक प्रक्रियाले 5,000 कोराउटिनहरूमा 25 सञ्चालन गर्नेछ)। प्रयोग गरी प्रक्रियाहरू सिर्जना गरिनेछ SwooleProcess.

परिणामहरु:

Swole ले एउटा प्रक्रियामा चल्दा Async को तुलनामा थोरै कम नतिजा देखाउँदछ, तर 2 प्रक्रियाहरूसँग चित्र नाटकीय रूपमा परिवर्तन हुन्छ (नम्बर 2 संयोगले छनोट गरिएको थिएन; मेरो मेसिनमा, यो 2 प्रक्रियाहरू थिए जसले उत्कृष्ट परिणाम देखाउँदछ)।

वैसे, Async एक्सटेन्सनसँग प्रक्रियाहरूसँग काम गर्नको लागि एपीआई पनि छ, तर त्यहाँ मैले एक वा बढी प्रक्रियाहरूमा बेन्चमार्कहरू चलाउनबाट कुनै भिन्नता देखेको छैन (यो सम्भव छ कि मैले कतै गडबड गरेको छु)।

SQL बनाम बाइनरी प्रोटोकल:

Async को रूपमा, बाइनरी र SQL अपरेशनहरू बीचको भिन्नता एसिन्क्रोनस मोडमा हटाइएको छ।

समानांतर

किनकी समानान्तर विस्तार coroutines को बारे मा छैन, तर थ्रेड को बारे मा, हामी समानांतर थ्रेड को इष्टतम संख्या मापन गरौं:

यो मेरो मेसिनमा 16 छ। १६ समानान्तर थ्रेडहरूमा कनेक्टर बेन्चमार्कहरू चलाउनुहोस्:

तपाईले देख्न सक्नुहुने रूपमा, नतिजा एसिन्क्रोनस एक्सटेन्सनहरू भन्दा पनि राम्रो छ (2 प्रक्रियाहरूमा चलिरहेको स्वूललाई ​​गणना गर्दैन)। नोट गर्नुहोस् कि PECL कनेक्टरको लागि, अपडेट र अप्सर्ट अपरेसनहरू खाली छन्। यो तथ्यको कारण हो कि यी अपरेसनहरू त्रुटिको साथ असफल भए - मलाई थाहा छैन कि यो ext-parallel, ext-tarantool, वा दुबैको गल्ती थियो।

अब SQL प्रदर्शन तुलना गरौं:

सिंक्रोनस रूपमा चलिरहेको कनेक्टरहरूको लागि ग्राफसँग समानता याद गर्नुहोस्?

सँगै

र अन्तमा, परीक्षण गरिएका विस्तारहरूका लागि समग्र चित्र हेर्नको लागि एउटा ग्राफमा सबै नतिजाहरूलाई संक्षेप गरौं। चार्टमा एउटा नयाँ परीक्षण थपौं, जुन हामीले अहिलेसम्म गरेका छैनौं - Parallel* प्रयोग गरेर समानान्तरमा Async coroutines चलाउनुहोस्। माथिको विस्तारहरू एकीकृत गर्ने विचार पहिले नै छ छलफल भएको थियो लेखकहरू, तर कुनै सहमतिमा पुग्न सकेन, तपाईंले यो आफैं गर्नुपर्छ।

* यो समानान्तर संग Swoole coroutines सुरु गर्न सम्भव थिएन; यस्तो देखिन्छ कि यी विस्तारहरू असंगत छन्।

त्यसैले, अन्तिम परिणाम:

बरु एक निष्कर्षमा को

मेरो विचारमा, नतिजाहरू धेरै योग्य भए, र केही कारणका लागि म पक्का छु कि यो सीमा होइन! तपाईले यो वास्तविक परियोजनामा ​​आफ्नो लागि मात्र निर्णय गर्न आवश्यक छ कि छैन, म मात्र भन्छु कि यो मेरो लागि एक चाखलाग्दो प्रयोग थियो जसले तपाईलाई न्यूनतम प्रयासको साथ सिंक्रोनस TCP कनेक्टरबाट कति "निचोड" गर्न सक्नुहुन्छ भनेर मूल्याङ्कन गर्न अनुमति दिन्छ। यदि तपाईंसँग बेन्चमार्कहरू सुधार गर्ने विचारहरू छन् भने, म तपाईंको पुल अनुरोधलाई विचार गर्न पाउँदा खुसी हुनेछु। प्रक्षेपण निर्देशनहरू र परिणामहरू सहितको सबै कोड छुट्टै प्रकाशित गरिएको छ भण्डारहरू.

स्रोत: www.habr.com