PHP 5.5 और यूनिट टेस्ट में माइग्रेट करना

PHP में PHP 4.4 से PHP 5.3 में संक्रमण के बाद 4 साल बीत चुके हैं, यह PHP को अपडेट करने का समय है, इस बार तुरंत PHP 5.5 के संस्करण में। नई सुविधाओं के अलावा, पीएचपी के नए संस्करण ने एक बार फिर हमें उत्पादकता में उल्लेखनीय वृद्धि दी है, इसलिए हमारे पास अपग्रेड के कई कारण थे। इस लेख में, हम इस बारे में बात करेंगे कि हमने PHP 5.5 पर कैसे स्विच किया, जो हमने एकत्र किए थे, और हमने PHPUnit के आधार पर यूनिट टेस्ट चलाने के लिए एक बार फिर से अपना सिस्टम क्यों दोबारा बनाया।









चित्रा 1. सामान्य वास्तुकला

PHP 5.3 से PHP 5.5 पर स्विच करते समय "रेक"

पिछली बार हमने PHP के चौथे संस्करण से पांचवें स्थान पर स्विच किया था, और PHP 5.3 के हमारे संस्करण में पैच शामिल थे ताकि "पुराने" PHP सिंटैक्स ने काम किया, उदाहरण के लिए, $a = &new ClassName();



, और ताकि हमारा कोड आधार PHP4 और PHP5 पर एक ही समय में काम कर सके। इस बार हमारे पास इस तरह के प्रतिबंध नहीं थे, इसलिए संक्रमण के दौरान हमने बस सभी अप्रचलित निर्माणों को अधिक प्रासंगिक लोगों के साथ पाया और प्रतिस्थापित किया, और यह कोड पुनर्लेखन का अंत था।



मुख्य समस्याओं का सामना करना पड़ा है:

• भाषा की हटाए गए सुविधाओं का हिस्सा हटा दिया गया है;
• mysql एक्सटेंशन पदावनत हो गया है ;
• रनकिट एक्सटेंशन का कम प्रदर्शन, जिसका उपयोग हम यूनिट टेस्ट लिखते समय करते हैं।

PHP 5.5 पर स्विच करने के बाद, हमारे यूनिट परीक्षणों में अधिक समय (कई बार) लगने लगा, इसलिए हमने इस समस्या को हल करने के लिए एक बार फिर से अपने "लॉन्चर" को परिष्कृत करने का निर्णय लिया।

रनकिट और PHP 5.4+

Xhprof एक्सटेंशन का उपयोग करते हुए, हमें जल्दी से पता चला कि हमारे परीक्षण "धीमा" हो रहे थे क्योंकि रनकिट एक्सटेंशन के प्रदर्शन में महत्वपूर्ण गिरावट थी, इसलिए हमने एक कारण की तलाश शुरू कर दी। नतीजतन, यह पता चला कि समस्या, जाहिरा तौर पर, PHP 5.4 के लिए एक "रहस्यमय" रनटाइम कैश के अलावा थी , जिसे "रनकिट _ * _ रिडिफाइन" फ़ंक्शन को कॉल करने के बाद हर बार रीसेट करना होगा।



प्रत्येक कॉल के लिए रनकिट एक्सटेंशन सभी पंजीकृत वर्गों, विधियों और फ़ंक्शन के माध्यम से जाता है और इस कैश को फ्लश करता है। हमने भोलेपन से इसे निष्क्रिय करने की कोशिश की, लेकिन उसके बाद PHP दुर्घटनाग्रस्त हो गई, इसलिए हमें एक और समाधान तलाशना पड़ा।

"माइक्रोसाइट्स" की अवधारणा (माइक्रोसाइट)

PHP 5.5 में संक्रमण होने से पहले, हमारे पास पहले से ही ऐड-ऑन फ़ेपुनिट के रूप में एक यूनिट टेस्ट लांचर था, जिसने यूनिट परीक्षणों के एक बड़े सूट को कई छोटे हिस्सों में विभाजित किया था: उस समय हमने 11 थ्रेड्स में परीक्षणों के लॉन्च का उपयोग किया था (इल्या कुडिनोव ने पहले से ही इस बारे में बात की थी। सम्मेलन, जिसमें द लव लवका सम्मेलन: www.youtube.com/watch?v=gAisPsfbLkg ) शामिल हैं।



हमने कई सरल बेंचमार्क किए और पता चला कि परीक्षण कई बार तेजी से गुजरते हैं यदि हम अपने सूट को 11 भागों में नहीं विभाजित करते हैं, जैसा कि यह पहले था, लेकिन 128 या अधिक (प्रोसेसर कोर की एक निश्चित संख्या के साथ)। प्रत्येक सुइट में, केवल लगभग 10-15 फाइलें प्राप्त हुई थीं, इसलिए हमने इस अवधारणा को "माइक्रोसेट्स" कहा। हमें लगभग 150 ऐसे माइक्रोसेट्स मिले, और उनमें से प्रत्येक को कुछ स्क्रिप्ट के लिए "कार्य" के रूप में अच्छी तरह से अनुकूल था (कार्य में संगत सूट के लिए फ़ाइलों की एक सूची शामिल है, और यह बदले में, उपयुक्त मापदंडों के साथ फ़ापुनिट शुरू करता है )।

बादल में टेस्ट

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

सामान्य वास्तुकला

हम कई अलग-अलग स्रोतों से परीक्षण चलाते हैं:

1. AIDA का उपयोग करके स्वचालित परीक्षण चलता है:
   
   - कार्य की शाखा (गिट शाखा) पर;
   
   - "बिल्ड" के अनुसार - कोड जो उत्पादन के लिए छोड़ देगा;
   
   - मास्टर शाखा पर;
2. "मैनुअल" परीक्षण देव सर्वर से डेवलपर्स या परीक्षकों द्वारा शुरू किया गया है।

इन सभी प्रकार के परीक्षण रन इस तथ्य से एकजुट होते हैं कि आपको पहले किसी स्रोत से शाखा को "खींचने" (लाने) की आवश्यकता है, और फिर इस शाखा पर परीक्षण रन चलाएं।

इस तथ्य ने हमारे नए "क्लाउड" परीक्षण लांचर (लेख की शुरुआत में चित्र 1) की वास्तुकला निर्धारित की:



सबसे पहले, मास्टर प्रक्रिया के लिए एक एकल कार्य बनाया जाता है, जो:

• डेटाबेस में एक उपलब्ध निर्देशिका का चयन करता है (छवि 2);
• सही स्थान (साझा भंडार या देव सर्वर) से गिट शाखा को डाउनलोड करता है;
• (वैकल्पिक) मास्टर को मर्ज करता है;
• (वैकल्पिक) सभी स्थानीय परिवर्तनों के साथ एक नई प्रतिबद्ध बनाता है।

चित्र 2. MySQL में उपलब्ध निर्देशिकाएँ



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



पहला कार्य, जो नए सर्वर पर जाता है, परीक्षण चलाने के लिए चयनित निर्देशिका को तैयार करता है, सर्वर से आवश्यक प्रतिबद्ध लेता है जिस पर मास्टर प्रक्रिया चल रही है। यह सुनिश्चित करने के लिए कि संबंधित सर्वर पर आए अन्य सभी कार्य उसी समय नहीं करते हैं जैसे कि पहला कार्य, फ़ाइल लॉक का उपयोग किया जाता है (चित्र 3)।



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









अंजीर। 3. एक निर्देशिका तैयार करते समय ताले



कुछ परीक्षण दूसरों की तुलना में बहुत लंबे समय तक चल सकते हैं, और हमारे पास प्रत्येक परीक्षण के लिए लिए गए समय के आंकड़े हैं, इसलिए हम इस जानकारी का उपयोग पहले स्थान पर "लंबे" परीक्षण चलाने के लिए करते हैं। इस तरह की रणनीति परीक्षण निष्पादन के दौरान सर्वर के अधिक समान लोडिंग को प्राप्त करना संभव बनाती है, साथ ही निष्पादन के लिए कुल समय को कम करती है (चित्र 4)।









चित्रा 4. परीक्षण निष्पादन समय के लिए लेखांकन



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









अंजीर 5. शर्म की बोर्ड: परीक्षणों की एक सूची जो एक मिनट से अधिक समय तक चलती है



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

परिणाम

PHP 5.5 पर स्विच करने के बाद, हम नई भाषा सुविधाओं का उपयोग करने में सक्षम थे, हमारे सर्वर पर सीपीयू की खपत को काफी कम कर दिया (औसतन 25%), और हमारी इकाई परीक्षणों को भी क्लाउड में स्थानांतरित कर दिया। उत्तरार्द्ध ने हमें कुल परीक्षण समय 5-6 मिनट (PHP 5.5 - दस मिनट में) से एक मिनट तक कम करने की अनुमति दी, एक ही समय में एक साझा देव सर्वर से लोड को क्लाउड में स्थानांतरित किया।



Yuri youROCK Nasretdinov , Badoo डेवलपर