🔺 📛 🛡️ क्यों जंग टेकपावर फ्रेमवर्क बेंचमार्क छोड़ देता है ♎️ 📌 ❣️

वास्तव में, मैंने यह देखने का इरादा नहीं किया कि रस्ट की हिम्मत किस रंग की थी। मैंने गो पर एक शौक परियोजना को उठाया, फास्टहट की स्थिति देखने के लिए गिटहब गया: क्या यह विकसित हो रहा है? अच्छा, कम से कम समर्थन किया? उठ गया। चला गया, देखा गया कि टेकहम्पावर बेंचमार्क में फास्टहट कहाँ बैठता है। मैं देखता हूं: और वहां उपवास मुश्किल से आधे से पता चलता है कि नेता क्या सफल होता है - कुछ रस्ट पर कुछ एक्टिक्स के लिए। क्या दर्द है?

यहां मैं अपनी बाहों को मोड़ूंगा, फर्श पर (तीन बार) मेरे सिर को टकराऊंगा और चिल्लाऊंगा: "हेलेलुजाह, वास्तव में रस्ट एक सच्चा देवता है, मैं पहले कितना अंधा था!"। लेकिन या तो हैंडल काम नहीं करते थे, या माथे को पछतावा होता था ... इसके बजाय, मुझे गोस्ट में लिखे गए परीक्षणों और रस्ट में एक्टिक्स-वेब परीक्षणों के कोड में मिला। इसे सुलझाने के लिए।

कुछ घंटों के बाद मुझे पता चला:

क्यों सभी TechEmpower परीक्षणों में एक्टिक्स-वेब रस्ट फ्रेमवर्क पहले स्थान पर है,
कैसे जावा स्क्रिप्ट शुरू करता है।

अब मैं आपको सब कुछ बता दूंगा।

TechEmpower फ्रेमवर्क बेंचमार्क क्या है?

यदि कोई वेब फ्रेमवर्क यह प्रदर्शित करता है कि क्या वह कभी-कभी दोस्तों के पास जाने के बारे में सोचता है, "मैं तेज़ हूँ," तो यह निश्चित रूप से TechEmpower फ्रेमवर्क बेंचमार्क में आ जाएगा। प्रदर्शन को मापने के लिए जाने के लिए एक लोकप्रिय स्थान।

साइट में एक अजीब डिजाइन है: विभिन्न प्रकार के परीक्षणों के लिए फिल्टर, राउंड, स्थिति और परिणाम के टैब पृष्ठ पर एक उदार हाथ से बिखरे हुए हैं। इतना उदार और व्यापक कि आप उन्हें नोटिस नहीं करते। लेकिन यह टैब पर क्लिक करने के लायक है, उनके पीछे की जानकारी उपयोगी है।

सबसे आसान तरीका है कि आप सादा परीक्षा परिणाम प्राप्त करें, "हैलो वर्ल्ड!" वेब सर्वर के लिए। फ्रेमवर्क के लेखक आमतौर पर इसके लिए एक लिंक देते हैं: हम पहले सौ में रहते हैं। मामला सही और उपयोगी है। सामान्य तौर पर, प्लेटेक्स्ट देना कई लोगों के लिए अच्छा होता है, और नेता एक तंग समूह में जाते हैं।

पास में, उन बहुत टैब में, अन्य प्रकार (परिदृश्य) के परीक्षणों के परिणाम हैं। उनमें से सात हैं, अधिक विवरण यहां पाया जा सकता है । ये परिदृश्य न केवल परीक्षण करते हैं कि कैसे फ्रेमवर्क / प्लेटफ़ॉर्म एक साधारण http अनुरोध को संसाधित करता है, बल्कि एक डेटाबेस क्लाइंट, टेम्पलेट इंजन, या जेन्साइज़र के साथ संयोजन होता है।

भौतिक हार्डवेयर पर, वर्चुअल वातावरण में परीक्षण डेटा हैं। रेखांकन के अलावा, सारणीबद्ध डेटा होते हैं। सामान्य तौर पर, बहुत सारी दिलचस्प चीजें, यह "आपके" प्लेटफ़ॉर्म की स्थिति को नहीं, बल्कि इसके माध्यम से खुदाई करने योग्य है।

परीक्षण के परिणामों से गुजरने के बाद पहली बात जो मेरे दिमाग में आई: "क्यों सब कुछ SO SO सादा से अलग है?"। प्लेनटेक्स्ट में, नेता एक तंग समूह में जाते हैं, लेकिन जब डेटाबेस के साथ काम करने की बात आती है, तो एक्टिक्स-वेब एक महत्वपूर्ण मार्जिन से आगे बढ़ता है। इसी समय, यह एक स्थिर अनुरोध प्रसंस्करण समय दिखाता है। शैतान।

एक और विसंगति: एक अविश्वसनीय रूप से शक्तिशाली जावास्क्रिप्ट समाधान। इसे एक्स 4 एक्स कहा जाता है। यह पता चला कि उसका कोड जावा में पूरी तरह से लिखे जाने की तुलना में थोड़ा कम था। जावा रनटाइम, JDBC द्वारा उपयोग किया जाता है। जावास्क्रिप्ट कोड को बाईटकोड और ग्लूज़ जावा पुस्तकालयों में अनुवादित किया गया है। वे सचमुच इसे ले गए - और स्क्रिप्ट को जावा से जोड़ दिया। पीला चेहरे की चाल की कोई सीमा नहीं है।

कोड को कैसे देखें और अंदर क्या है

सभी परीक्षणों के लिए कोड GitHub पर है। सब कुछ एक एकल भंडार में है, जो बहुत सुविधाजनक है। आप क्लोन कर सकते हैं और देख सकते हैं, आप सीधे GitHub पर देख सकते हैं। परीक्षण में धारावाहिक, टेम्पलेट इंजन और डेटाबेस क्लाइंट के साथ फ्रेमवर्क के 300 से अधिक विभिन्न संयोजन शामिल हैं। विभिन्न प्रोग्रामिंग भाषाओं में, विकास के लिए एक अलग दृष्टिकोण के साथ। एक भाषा में कार्यान्वयन पास हैं, अन्य भाषाओं में कार्यान्वयन के साथ इसकी तुलना की जा सकती है। कोड समुदाय द्वारा बनाए रखा जाता है, यह किसी एक व्यक्ति या टीम का काम नहीं है।

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

रस्ट से पहले, मेरे पास एक बहुत अस्पष्ट विचार था। सी, सी ++, डी और विशेष रूप से गो के बारे में कोई भी लेख निश्चित रूप से टिप्पणीकारों के एक जोड़े के बारे में विस्तार से और पीड़ा के साथ बता रहा है कि घमंड, बकवास और मूर्खता कुछ और में लिखी गई है, जबकि ~~Gascogne~~ जंग। कभी-कभी उन्हें इतना दूर ले जाया जाता है कि वे एक अप्रस्तुत व्यक्ति की तुलना में कोड उदाहरण देते हैं ~~या कुछ स्वीकार कर रहे हैं~~ स्तूप में संचालित: "क्यों, क्यों, क्यों इन सभी प्रतीकों!"

इसलिए, कोड खोलना डरावना था।

मैंने देखा। यह पता चला कि रस्ट के कार्यक्रमों को पढ़ा जा सकता है। इसके अलावा, कोड को इतनी अच्छी तरह से पढ़ा जाता है कि मैंने रस्ट को भी स्थापित किया, परीक्षण और टिंकर को थोड़ा सा संकलित करने की कोशिश की।

यहां मैंने लगभग इस व्यवसाय को छोड़ दिया, क्योंकि संकलन लंबे समय तक रहता है। बहुत लंबा समय। अगर मैं डी'आर्टगन, या यहाँ तक कि सिर्फ एक कलगीदार होता, तो मैं गस्कनी के लिए रवाना हो जाता, और एक हज़ार शैतान निस्तेज हो जाते। लेकिन मैंने कर दिखाया। मैंने फिर से चाय पी। ऐसा लगता है कि एक कप भी नहीं: मेरे लैपटॉप पर, पहले संकलन में लगभग 20 मिनट लगे। फिर, हालांकि, सब कुछ अधिक मजेदार हो जाता है। शायद अगले बड़े अपडेट तक।

लेकिन क्या यह स्वयं जंग नहीं है?

नहीं। प्रोग्रामिंग भाषा नहीं।

बेशक, रस्ट एक अद्भुत भाषा है। शक्तिशाली, लचीला, आदत और क्रिया से बाहर। लेकिन भाषा स्वयं तेज कोड नहीं लिखेगी। भाषा उपकरण है, प्रोग्रामर द्वारा किए गए निर्णयों में से एक।

जैसा कि मैंने कहा - प्लेनटेक्स्ट देना बहुत जल्दी प्राप्त होता है। एक सरल अनुरोध को संसाधित करते समय एक्टिक्स-वेब, फास्टटैप और एक दर्जन अन्य फ्रेमवर्क का प्रदर्शन काफी तुलनीय है, अर्थात्, अन्य भाषाओं में रस्ट के साथ प्रतिस्पर्धा करने की तकनीकी क्षमता है।

एक्टिक्स-वेब ही, निश्चित रूप से, "दोष" है: एक तेज, व्यावहारिक, उत्कृष्ट उत्पाद। सीरियलाइजेशन सुविधाजनक है, टेम्पलेट इंजन अच्छा है - यह भी बहुत मदद करता है।

सबसे विशेष रूप से, डेटाबेस के साथ काम करने वाले परीक्षणों के परिणाम भिन्न होते हैं।

कोड में थोड़ा खुदाई करने के बाद, मैंने तीन मुख्य अंतरों पर प्रकाश डाला (जो मुझे ऐसा लगता है) ने सिंथेटिक परीक्षणों में प्रतियोगियों से अलग होने के लिए एक्टिक्स परीक्षणों में मदद की:

पाइपलाइज्ड पाइपलाइक टोको-पोस्टग्रेज ऑपरेशन मोड;
गो में लिखे गए परीक्षण के साथ एक कनेक्शन पूल के बजाय एक रस्ट टेस्ट के साथ एकल कनेक्शन का उपयोग करना;
कई UPDATE कमांड भेजने के बजाय एक साधारण क्वेरी के माध्यम से भेजे गए एकल कमांड के साथ एक्टिक्स बेंचमार्क अपडेट करना।

कन्वेयर मोड किस तरह का है?

यहाँ tokio-postgres प्रलेखन (PostgreSQL क्लाइंट लाइब्रेरी के बेंचमार्क में प्रयुक्त) से एक स्निपेट बताया गया है कि इसके डेवलपर्स का क्या अर्थ है:

Sequential Pipelined | Client | PostgreSQL | | Client | PostgreSQL | |----------------|-----------------| |----------------|-----------------| | send query 1 | | | send query 1 | | | | process query 1 | | send query 2 | process query 1 | | receive rows 1 | | | send query 3 | process query 2 | | send query 2 | | | receive rows 1 | process query 3 | | | process query 2 | | receive rows 2 | | | receive rows 2 | | | receive rows 3 | | | send query 3 | | | | process query 3 | | receive rows 3 | |

Pipelined (pipelined) मोड में क्लाइंट PostgreSQL प्रतिक्रिया की प्रतीक्षा नहीं करता है, लेकिन अगली क्वेरी भेजता है जबकि PostgreSQL पिछले एक को संसाधित कर रहा है। यह देखा जा सकता है कि इस तरह से आप डेटाबेस क्वेरी के समान अनुक्रम को काफी तेजी से संसाधित कर सकते हैं।

यदि पाइपलाइन मोड में कनेक्शन डुप्लेक्स है (भेजने के साथ समानांतर में परिणाम प्राप्त करने की संभावना प्रदान करता है), तो यह समय थोड़ा कम हो सकता है। ऐसा लगता है कि टोकियो-पोस्टग्रेज का एक प्रयोगात्मक संस्करण पहले से ही है जहां एक द्वैध कनेक्शन खोला गया है।

चूंकि PostgreSQL क्लाइंट निष्पादन के लिए भेजे गए प्रत्येक SQL क्वेरी में कई संदेश (Parse, Bind, Execute, और Sync) भेजता है, और उन्हें एक प्रतिक्रिया मिलती है, एकल प्रश्न संसाधित करते समय भी पाइपलाइन मोड अधिक प्रभावी होगा।

और यह गो में क्यों नहीं है?

क्योंकि गो आमतौर पर डेटाबेस कनेक्शन पूल का उपयोग करता है। कनेक्शन का उपयोग समानांतर में करने का इरादा नहीं है।

यदि आप एक ही कनेक्शन के बजाय एक पूल के माध्यम से एक ही SQL क्वेरी चलाते हैं, तो सैद्धांतिक रूप से आप एक साधारण सीरियल क्लाइंट के साथ भी कम निष्पादन का समय प्राप्त कर सकते हैं, जब एकल कनेक्शन के माध्यम से काम किया जा सकता है, तो इसे तीन बार पाइपलाइज्ड करें:

 | Connection | Connection 2 | Connection 3 | PostgreSQL | |----------------|----------------|----------------|-----------------| | send query 1 | | | | | | send query 2 | | process query 1 | | receive rows 1 | | send query 3 | process query 2 | | | receive rows 2 | | process query 3 | | | receive rows 3 | |

ऐसा लगता है कि चर्मपत्र (कन्वेयर मोड) मोमबत्ती के लायक नहीं है।

केवल उच्च लोड के तहत PostgreSQL सर्वर से कनेक्शन की संख्या एक समस्या हो सकती है।

और इसके साथ कनेक्शन की संख्या का क्या संबंध है?

यहाँ पर बताया गया है कि कैसे PostgreSQL सर्वर कनेक्शन की संख्या में वृद्धि का जवाब देता है।

स्तंभों का बायाँ समूह खुले कनेक्शनों की संख्या के आधार पर PostgreSQL प्रदर्शन के उदय और गिरावट को दर्शाता है:

( पेरकोना पद से अनुकूलित )

यह देखा जा सकता है कि खुले कनेक्शन की संख्या में वृद्धि के साथ, PostgreSQL सर्वर का प्रदर्शन तेजी से गिर रहा है।

इसके अलावा, प्रत्यक्ष कनेक्शन खोलना "मुक्त" नहीं है। क्लाइंट खोलने के तुरंत बाद सेवा की जानकारी भेजता है, अनुरोधों को कैसे संसाधित किया जाएगा, इस पर PostgreSQL सर्वर के साथ "सहमत" है।

इसलिए, व्यवहार में, आपको पोस्टग्रेक्सेल को सक्रिय कनेक्शनों की संख्या को सीमित करना होगा, अक्सर इसके अलावा उन्हें pgbouncer या कुछ अन्य ओडिसी से गुजरना होगा।

तो एक्टिक्स-वेब क्यों तेज था?

सबसे पहले, एक्टिक्स-वेब अपने आप में बहुत तेज़ है। यह वह है जो "छत" सेट करता है, और वह दूसरों की तुलना में थोड़ा अधिक है। अन्य पुस्तकालयों का उपयोग किया जाता है (सर्ड, यार्ड) भी बहुत, बहुत उत्पादक हैं। लेकिन यह मुझे लगता है कि PostgreSQL के साथ काम करने वाले परीक्षणों में यह बंद आना संभव था क्योंकि एक्टिक्स-वेब सर्वर प्रोसेसर कोर पर एक धागा शुरू करता है। प्रत्येक थ्रेड PostgreSQL के लिए सिर्फ एक कनेक्शन खोलता है।

कम सक्रिय कनेक्शन, तेज़ पोस्टग्रेक्सेल काम करता है (ऊपर ग्राफ़ देखें)।

Pipelined मोड (tokio-postgres) में काम करने वाला क्लाइंट आपको उपयोगकर्ता प्रश्नों के समानांतर प्रसंस्करण के लिए PostgreSQL के साथ कुशलतापूर्वक एक कनेक्शन का उपयोग करने की अनुमति देता है। HTTP अनुरोध हैंडलर अपने SQL कमांड को एक कतार में डंप करते हैं और परिणाम प्राप्त करने के लिए दूसरे में लाइन अप करते हैं। परिणाम मज़ेदार होते हैं, देरी कम होती है, हर कोई खुश होता है। समग्र प्रदर्शन एक कनेक्शन पूल के साथ एक प्रणाली की तुलना में अधिक है।

तो आपको पूल को त्यागने की ज़रूरत है, एक पोस्टग्रेक्यूएल पाइपलाइन क्लाइंट लिखें, और खुशी और अविश्वसनीय गति तुरंत आ जाएगी?

हो सकता है कि। लेकिन एक बार में ही नहीं।

जब कन्वेयर मोड को बचाने की संभावना नहीं है और निश्चित रूप से नहीं बचाएगा

बेंचमार्क कोड में उपयोग की जाने वाली स्कीम PostgreSQL लेनदेन के साथ काम नहीं करेगी।

बेंचमार्क में, लेनदेन की आवश्यकता नहीं होती है और कोड को ध्यान में रखते हुए लिखा जाता है कि कोई लेनदेन नहीं होगा। व्यवहार में, वे होते हैं।

यदि बैकएंड कोड एक पोस्टग्रैसिक लेनदेन (उदाहरण के लिए, दो अलग-अलग तालिकाओं में परिवर्तन करने के लिए) खोलता है, तो इस कनेक्शन के माध्यम से भेजे गए सभी आदेश इस लेनदेन के अंदर निष्पादित किए जाएंगे।

चूंकि PostgreSQL के साथ कनेक्शन समानांतर में उपयोग किया जाता है, इसलिए सब कुछ मिश्रित हो जाता है। डेवलपर द्वारा डिज़ाइन किए गए लेनदेन को कमांड में निष्पादित किया जाना चाहिए जो समानांतर http अनुरोध हैंडलर द्वारा शुरू किए गए sql कमांड के साथ मिलाया जाता है। हम उनकी अखंडता के साथ यादृच्छिक डेटा हानि और समस्याएं प्राप्त करेंगे।

तो हैलो लेनदेन - एक कनेक्शन के अलविदा समानांतर उपयोग। आपको यह सुनिश्चित करना होगा कि कनेक्शन अन्य http अनुरोध हैंडलर द्वारा उपयोग नहीं किया गया है। आपको या तो लेनदेन बंद करने से पहले आने वाले http अनुरोधों को संसाधित करने से रोकना होगा, या लेनदेन के लिए एक पूल का उपयोग करना होगा, डेटाबेस सर्वर से कई कनेक्शन खोलना होगा। रस्ट के लिए कई पूल कार्यान्वयन हैं, और एक नहीं। इसके अलावा, वे डेटाबेस क्लाइंट कार्यान्वयन से अलग जंग में मौजूद हैं। आप स्वाद, रंग, गंध या यादृच्छिक के अनुसार चुन सकते हैं। जाओ उस तरह से काम नहीं करता है। जेनरिक की शक्ति, हाँ।

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

क्या बेंचमार्क कोड में कुछ और दिलचस्प है?

हां।

प्रदर्शन को मापने के लिए परिदृश्य का विस्तार से वर्णन किया गया है। साथ ही मापदंड जो परीक्षणों में भाग लेने वाले कोड को संतुष्ट करते हैं। उनमें से एक यह है कि डेटाबेस सर्वर के सभी प्रश्नों को क्रमिक रूप से निष्पादित किया जाना चाहिए।

निम्न (थोड़ा संक्षिप्त) कोड टुकड़ा ऐसा लगता है जैसे यह मानदंडों को पूरा नहीं करता है:

  let mut worlds = Vec::with_capacity(num); //  num    PostgreSQL for _ in 0..num { let w_id: i32 = self.rng.gen_range(1, 10_001); worlds.push( self.cl .query(&self.world, &[&w_id]) .into_future() .map(move |(row, _)| { // ... }), ); } //     stream::futures_unordered(worlds) .collect() .and_then(move |worlds| { // ... })

सब कुछ समानांतर प्रक्रियाओं के एक विशिष्ट लॉन्च की तरह दिखता है। लेकिन, चूंकि PostgreSQL के एक कनेक्शन का उपयोग किया जाता है, डेटाबेस सर्वर से प्रश्नों को क्रमिक रूप से भेजा जाता है। एक-एक करके। आवश्यकतानुसार। कोई अपराध नहीं।

ऐसा क्यों? ठीक है, सबसे पहले, कोड में (यह संपादकीय कार्यालय में दिया गया था, जिसने 18 वें दौर में काम किया था) async / इंतजार का अभी तक उपयोग नहीं किया गया है, यह बाद में रस्ट में दिखाई दिया। और वायदा num माध्यम से एसक्यूएल प्रश्नों को "समानांतर में" भेजना आसान है - जैसा कि ऊपर दिए गए कोड में है। यह आपको कुछ अतिरिक्त प्रदर्शन को बढ़ावा देने की अनुमति देता है: जबकि PostgreSQL पहली SQL क्वेरी को स्वीकार और संसाधित करता है, बाकी को इसे खिलाया जाता है। वेब सर्वर प्रत्येक के परिणाम के लिए इंतजार नहीं करता है, लेकिन अन्य कार्यों पर स्विच करता है और केवल HTTP-अनुरोध को संसाधित करने के लिए वापस लौटता है जब सभी SQL-क्वेरीज़ पूरी हो जाती हैं।

PostgreSQL के लिए, बोनस यह है कि एक ही संदर्भ (कनेक्शन) में एक ही प्रकार की क्वेरी एक पंक्ति में जाती है। क्वेरी योजना को फिर से बनाने की संभावना नहीं बढ़ जाती है।

यह पता चला है कि पाइपलाइन मोड के फायदे (देखें टोको-पोस्टग्रेज डॉक्यूमेंट से आरेख) एक भी HTTP अनुरोध को संसाधित करते समय भी पूरी तरह से शोषण किया जाता है।

और क्या?

बैच अपडेट के लिए सरल क्वेरी प्रोटोकॉल का उपयोग करना

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

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

एक्टिक्स-वेब बेंचमार्क में उपयोग किया जाने वाला एक दिलचस्प समाधान सरल क्वेरी प्रोटोकॉल के माध्यम से भेजे गए एकल कमांड के साथ कई टेबल प्रविष्टियों को अपडेट करना था।

बेंचमार्क के अनुसार, उपयोगकर्ता के अनुरोध को संसाधित करते समय, वेब सर्वर को तालिका में कई रिकॉर्ड अपडेट करने होंगे, यादृच्छिक संख्याएं लिखनी होंगी। जाहिर है, अनुक्रमिक प्रश्नों के साथ उत्तराधिकार में रिकॉर्ड अपडेट करना एक एकल क्वेरी की तुलना में एक साथ सभी रिकॉर्डों को अपडेट करने में अधिक समय लेता है।

परीक्षण कोड में उत्पन्न अनुरोध कुछ इस तरह दिखता है:

 UPDATE world SET randomnumber = temp.randomnumber FROM (VALUES (1, 2), (2, 3) ORDER BY 1) AS temp(id, randomnumber) WHERE temp.id = world.id

जहाँ (1, 2), (2, 3) लाइन आइडेंटिफ़ायर जोड़े / रैंडमबर्न फ़ील्ड के नए मूल्य हैं।

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

सरल क्वेरी चारों ओर अफवाह है। मैं एक सिफारिश से मिला: "केवल सरल क्वेरी प्रोटोकॉल पर काम करें, और सब कुछ तेज और अच्छा होगा।" मैं उसे बहुत संदेह के साथ देखता हूं। सरल क्वेरी आपको क्लाइंट पैरामीटर को क्वेरी पैरामीटर की प्रक्रिया को आगे बढ़ाते हुए PostgreSQL सर्वर पर भेजे गए संदेशों की संख्या को कम करने की अनुमति देती है। आप मापदंडों की एक चर संख्या के साथ गतिशील रूप से उत्पन्न प्रश्नों के लिए लाभ देख सकते हैं। एक ही प्रकार के SQL प्रश्नों (जो अधिक सामान्य हैं) के लिए, लाभ स्पष्ट नहीं है। अच्छी तरह से और क्वेरी मापदंडों का प्रसंस्करण कितना सुरक्षित होगा, सरल क्वेरी के मामले में यह क्लाइंट लाइब्रेरी के कार्यान्वयन को निर्धारित करता है।

जैसा कि मैंने ऊपर लिखा है, इस मामले में, SQL क्वेरी का शरीर गतिशील रूप से उत्पन्न होता है, डेटा संख्यात्मक होता है और सर्वर द्वारा ही उत्पन्न होता है। सरल क्वेरी के लिए एकदम सही संयोजन। लेकिन इस मामले में भी, यह अन्य विकल्पों के परीक्षण के लायक है। विकल्प PostgreSQL प्लेटफॉर्म और क्लाइंट पर निर्भर करते हैं: pgx (Go के लिए क्लाइंट) कमांड के एक पैकेज, JDBC को भेजने के लिए संभव बनाता है - विभिन्न मापदंडों के साथ एक पंक्ति में कई बार एक कमांड निष्पादित करने के लिए। दोनों समाधान एक ही गति से चल सकते हैं या तेज भी हो सकते हैं।

तो जंग क्यों प्रमुख है?

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

एक्टिक्स-वेब पर आधारित एक और अविश्वसनीय, लेकिन महत्वपूर्ण "गुप्त" सर्वर, जिसने हमें सभी TechEmpower बेंचमार्क में पहला स्थान प्राप्त करने की अनुमति दी - यह कैसे PostgreSQL के साथ काम करता है:

प्रति वेब सर्वर स्ट्रीम PostgreSQL के साथ केवल एक कनेक्शन खुलता है। यह कनेक्शन पाइपलाइन मोड का उपयोग करता है, जो इसे उपयोगकर्ता अनुरोधों के समानांतर प्रसंस्करण के लिए प्रभावी रूप से उपयोग करने की अनुमति देता है।
कम सक्रिय कनेक्शन, तेजी से पोस्टग्रेक्यूएस प्रतिक्रिया करता है। उपयोगकर्ता अनुरोधों को संसाधित करने की गति बढ़ जाती है। उसी समय, लोड के तहत, पूरी प्रणाली अधिक स्थिर काम करती है (आने वाले अनुरोधों को संसाधित करने में देरी कम होती है, वे अधिक धीमी गति से बढ़ते हैं)।

जहां गति महत्वपूर्ण है, यह विकल्प संभवतः मल्टीप्लेक्सर्स (जैसे कि पगबॉन्सर और ओडिसी) का उपयोग करने से तेज होगा। और निश्चित रूप से वह बेंचमार्क में तेज था।

यह बहुत दिलचस्प है कि कैसे async / प्रतीक्षारत है, जो रुस्त में दिखाई दिया, और एक्टिक्स-वेब के साथ हालिया नाटक वेब विकास में रस्ट की लोकप्रियता को प्रभावित करेगा। यह भी दिलचस्प है कि async / प्रतीक्षा पर संसाधित करने के बाद परीक्षा परिणाम कैसे बदलेंगे।

क्यों जंग टेकपावर फ्रेमवर्क बेंचमार्क छोड़ देता है