🙅🏿 ◽️ 👨🏼‍🍳 सीमाएं जिनका उल्लंघन किया जाना चाहिए या हमने तीन बार कार्यात्मक परीक्षणों को कैसे तेज किया 🛢️ 😎 🤰

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

संक्षेप में आवेदन के बारे में

मेरी टीम एक सार्वजनिक एपीआई विकसित कर रही है जो 2GIS उपयोगकर्ताओं को डेटा प्रदान करती है। जब आप 2gis.ru पर जाते हैं और "सुपरमार्केट" की तलाश करते हैं, तो आपको संगठनों की एक सूची मिलती है - यह हमारे एपीआई का डेटा है। हमारे 2000+ आरपीएस पर, लगभग हर समस्या महत्वपूर्ण हो जाती है यदि किसी प्रकार की कार्यक्षमता टूट जाती है।

आवेदन स्काला में लिखा गया है, परीक्षण PHP में लिखे गए हैं, डेटाबेस PostgreSQL-9.4 है। हमारे पास लगभग 25,000 कार्यात्मक परीक्षण हैं, उन्हें सामान्य प्रतिगमन के लिए एक समर्पित आभासी मशीन पर पूरा करने के लिए 30 मिनट लगते हैं। परीक्षणों की अवधि ने हमें बहुत परेशान नहीं किया - हमें इस तथ्य के लिए उपयोग किया गया था कि परीक्षण पुराने ढाँचे पर 60 मिनट ले सकते हैं।

हमने तथाकथित "त्वरित" परीक्षणों को कैसे तेज किया

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

हमने परीक्षणों की गति का विश्लेषण किया और उन्हें तेज करने का कार्य प्रासंगिक हो गया। तो एक अध्ययन शुरू किया जिसका नाम है "टेस्ट धीरे-धीरे काम करें - इसे ठीक करें।"

नीचे परीक्षणों में पाई गई तीन बड़ी समस्याएं हैं।

समस्या 1: दुरुपयोग किया हुआ jsQuery

हमारे पास मौजूद सभी डेटा PostgreSQL डेटाबेस में संग्रहीत है। ज़्यादातर json के रूप में, इसलिए हम सक्रिय रूप से jsQuery का उपयोग करते हैं।

यहां एक क्वेरी का एक उदाहरण है जो हमने आवश्यक डेटा प्राप्त करने के लिए डेटाबेस में बनाया था:

SELECT * FROM firm WHERE json_data @@ 'rubrics.@# > 0' AND json_data @@ 'address_name = *' AND json_data @@ 'contact_groups.#.contacts.#.type = “website”' ORDER BY RANDOM() LIMIT 1

यह नोटिस करना आसान है कि उदाहरण पंक्ति में कई बार json_data का उपयोग करता है, हालांकि यह लिखना सही होगा:

 SELECT * FROM firm WHERE json_data @@ 'rubrics.@# > 0 AND address_name = * AND contact_groups.#.contacts.#.type = “website”' ORDER BY RANDOM() LIMIT 1

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

 $qb = $this>createQueryBulder() ->selectAllBranchFields() ->fromBranchPartition() ->hasRubric() ->hasAddressName() ->hasWebsite() ->orderByRandom() ->setMaxResults(1);

हमारी गलतियों को न दोहराएं : यदि एक JSONB फ़ील्ड में कई शर्तें हैं, तो उन सभी का वर्णन एकल ऑपरेटर '@@' के ढांचे के भीतर करें। हमने रिड्यूड करने के बाद, हमने प्रत्येक अनुरोध के निष्पादन समय को दो बार तेज किया। पहले, वर्णित अनुरोध में 7500ms लगे, लेकिन अब इसमें 3500ms लगते हैं।

समस्या 2: एक्स्ट्रा टेस्ट डेटा

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

हमने प्रतिच्छेदन समस्याओं से बचने के लिए प्रत्येक प्रतिगमन रन के लिए आवश्यक सेटिंग्स के साथ कई चाबियाँ बनाने का फैसला किया। और चूंकि एक नई कुंजी बनाने से पूरे एप्लिकेशन की कार्यक्षमता प्रभावित नहीं होती है, इसलिए परीक्षणों में यह दृष्टिकोण कुछ भी प्रभावित नहीं करेगा। वे लगभग एक साल तक ऐसी स्थिति में रहे, जब तक कि उन्होंने उत्पादकता से निपटना शुरू नहीं किया।

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

जब तक हम लॉग चेक नहीं करते तब तक हम अज्ञान में रहते थे। यह पता चला कि हमने चाबियां बनाई थीं, लेकिन परीक्षण चलाने के बाद उन्हें नहीं हटाया। इस प्रकार, हमने उनमें से 500,000 जमा किए हैं।

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

समस्या 3: रैंडम सैंपलिंग

हम विभिन्न डेटा पर एप्लिकेशन का परीक्षण करना पसंद करते हैं। हमारे पास बहुत अधिक डेटा है, और समस्याएं समय-समय पर पाई जाती हैं। उदाहरण के लिए, एक ऐसा मामला था जब हमें विज्ञापन पर डेटा अपलोड नहीं किया गया था, लेकिन परीक्षणों ने इस समस्या को समय पर पकड़ लिया। इसीलिए हमारे परीक्षणों के हर अनुरोध में आप ORDER BY RANDOM () देख सकते हैं

जब हमने EXPLAIN के साथ, बिना यादृच्छिकता के साथ, प्रश्नों के परिणामों को देखा, तो हमने 20 गुना वृद्धि देखी। यदि हम ऊपर दिए गए उदाहरण के बारे में बात करते हैं, तो यादृच्छिकता के बिना यह 160ms के लिए काम करता है। हमने गंभीरता से सोचा कि क्या करना है, क्योंकि हम वास्तव में यादृच्छिक घर को पूरी तरह से छोड़ना नहीं चाहते हैं।

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

 SELECT * FROM (SELECT * FROM firm_1 WHERE json_data @@ 'rubrics.@# > 0 AND address_name = * AND contact_groups.#.contacts.#.type = "website"' LIMIT 100) random_hack ORDER BY RANDOM() LIMIT 1;

इस सरल तरीके से, हमने 20x त्वरण पर लगभग कुछ भी नहीं खोया। इस तरह के अनुरोध का निष्पादन समय 180 मी है।

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

एक बार फिर कार्रवाई की एक छोटी सूची:

यदि हम JSONB फ़ील्ड में डेटा का चयन करने के लिए कई शर्तें निर्दिष्ट करते हैं, तो उन्हें एक ही ऑपरेटर '@@' में सूचीबद्ध किया जाना चाहिए।
यदि हम परीक्षण डेटा बनाते हैं, तो इसे हटाना सुनिश्चित करें। यहां तक कि अगर ऐसा लगता है कि उनकी उपस्थिति आवेदन की कार्यक्षमता को प्रभावित नहीं करती है।
यदि आपको प्रत्येक रन के लिए यादृच्छिक डेटा की आवश्यकता है, तो हम नमूने की विशिष्टता और निष्पादन की गति के बीच एक समझौता पाते हैं।

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