Django परियोजनाओं के परीक्षण में तेजी

Django अनुप्रयोगों के परीक्षण के प्रश्न को Habré सहित विभिन्न लेखों में बहुत अधिक ध्यान दिया गया है। उनमें से लगभग हर एक में, कम से कम कुछ वाक्य परीक्षणों के मार्ग को गति देने के लिए तरीकों और हैक्स के लिए समर्पित होते हैं, और इसलिए यहां मौलिक रूप से कुछ नया कहना आसान नहीं है।

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

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

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

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

असुरक्षित लेनदेन सेटिंग्स

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

MySQL के लिए, विशेष रूप से, वे निम्नलिखित प्रदान करते हैं:

[mysqld]
default-table-type=innodb
transaction-isolation=READ-COMMITTED
innodb_flush_log_at_trx_commit = 0
skip-sync-frm=OFF


PostgreSQL उसी उद्देश्य के लिए fsync = off विकल्प को postgresql.conf में जोड़ने की सलाह देता है।

रैमडिस्क का उपयोग करना

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

परीक्षण के लिए SQLite

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

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

प्रारंभिक SQLite टेस्ट बेस निर्माण

जैसा कि आप जानते हैं, जब परीक्षण चल रहा है, तो Django क्रियाओं का निम्नलिखित अनुक्रम करता है:

1. उपयोगकर्ता की अनुमति के साथ परीक्षण डेटाबेस को साफ करता है, अगर इसमें कुछ है
2. परीक्षण डेटाबेस में सभी टेबल और इंडेक्स बनाता है
3. जुड़नार का एक सेट लोड करता है जिसे initial_data कहा जाता है
4. एक-एक करके परीक्षण करता है
5. परीक्षण के दौरान बनाई गई हर चीज को हटा देता है

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

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

एक छोटी खोज से पता चला कि इस मामले का हल मौजूद है। यह पता चला है कि SQLite में "हॉट" बैकअप (वयस्कों की तरह) के लिए एक इंटरफ़ेस है, और यदि हम इस तरह की कॉपी को पहले से तैयार डेटाबेस से डेटाबेस में नाम के साथ चलाते हैं: स्मृति:, हमें ठीक वही मिलेगा जो हमें चाहिए: एक आरंभिक डेटाबेस स्मृति में डेटा।

कार्यान्वयन में पहली कठिनाई यह है कि मानक पायथन मॉड्यूल sqlite3 समर्थन नहीं करता है, और शायद इस एपीआई का समर्थन कभी नहीं करेगा, इसलिए, पायथन का उपयोग करके ऐसी प्रतिलिपि बनाने के लिए, वे APSW (एक और पायथन SQLite आवरण) नामक एक तृतीय-पक्ष मॉड्यूल का उपयोग करने का सुझाव देते हैं।

दूसरी कठिनाई यह है कि प्रत्येक नया डेटाबेस कनेक्शन: मेमोरी: डेटाबेस की अपनी प्रति (स्पष्ट रूप से खाली) बनाता है, और इसलिए हमें किसी तरह ओआरएसएम द्वारा उपयोग किए गए कर्सर को एपीएसडब्ल्यू द्वारा आरम्भिक कनेक्शन का उपयोग करने के लिए सिखाना होगा। सौभाग्य से, इस मामले के लिए एक हैक प्रदान किया जाता है: एक फ़ाइल नाम के साथ एक पंक्ति के बजाय, sqlite3 का उपयोग करके कनेक्शन बनाते समय, आप apsw.Connection ऑब्जेक्ट पास कर सकते हैं, जो सभी अनुरोधों को स्वयं प्रॉक्सी करेगा।

तो समाधान बहुत सरल लगता है:

1. दो ASPW कनेक्शन ऑब्जेक्ट बनाएं, जिनमें से एक पहले से तैयार डेटाबेस को संदर्भित करता है, और दूसरा डेटाबेस में मेमोरी में।
2. फ़ाइल को मेमोरी से डेटा कॉपी करें।
3. "डिफ़ॉल्ट" नाम के साथ उपनाम के लिए एनएएमई पैरामीटर के लिए हम मेमोरी का जिक्र करते हुए एएसपीडब्ल्यू कनेक्शन पास करते हैं।
4. कर्सर को प्रारंभ करें, और परीक्षण चलाएं।

एक डेटाबेस बनाना बहुत आसान है: केवल DATABASES सेटिंग्स में "Quickstart" नाम का उपनाम जोड़ें और फिर चलाएं ./manage.py syncdb --database quickstart ।

सभी कोड जो इन क्रियाओं को कर सकते हैं, वे 20 से अधिक लाइनों को लेते हैं और नीचे दिए गए हैं। यह काम करने के लिए, पर्याप्त है

1. APSW स्थापित करें
2. कोड को एक अलग फाइल में कॉपी करें और प्रोजेक्ट में रखें
3. quickstart नाम के डेटाबेस के लिए settings.DABABASES में एक उपनाम जोड़ें
4. डेटाबेस को चलाकर बनाएँ ./manage.py syncdb --database quickstart
5. चर TEST_RUNNER सेट करें ताकि यह सिर्फ सहेजे गए ऑब्जेक्ट के वर्ग को संदर्भित करे
6. कुछ सरल परीक्षण चलाने की कोशिश करें।

Copy Source | Copy HTML

1. आयात एप्स
2. django से। परीक्षण .Simple आयात DjangoTestSuiteRunner
3. django.db आयात कनेक्शन से
5. वर्ग TestSuiteRunner (DjangoTestSuiteRunner):
7. def setup_dat डेटाबेस (स्वयं, ** kwargs):
8. quickstart_connection = कनेक्शन [ 'quickstart' ]
9. quickstart_dbname = quickstart_connection.settings_dict [ 'NAME' ]
11. memory_connection = apsw.Connection ( ': मेमोरी:' )
12. quickstart_connection = apsw.Connection (quickstart_dbname)
13. बैकअप के रूप में memory_connection.backup ( 'मुख्य' , quickstart_connection, 'main' ) के साथ :
14. जबकि बैकअप नहीं।
15. backup.step ( 100 )
17. कनेक्शन = कनेक्शन [ 'डिफ़ॉल्ट' ]
18. connection.settings_dict [ 'NAME' ] = memory_connection
19. कर्सर = कनेक्शन। कर्सर ()
21. def teardown_dat डेटाबेस (स्वयं, old_config, ** kwargs):
22. पास

नतीजतन, एक एकल परीक्षण का निष्पादन समय 18 से 2 सेकंड तक गिर गया: यह जितनी बार चाहें परीक्षण चलाने के लिए काफी आरामदायक है।

समान कोड, लेकिन टिप्पणियों और एक साहसिक चेतावनी के साथ "आपके परीक्षण आपके डेटा खा सकते हैं!" (केवल परीक्षण वातावरण में उपयोग करें) gist.github.com/1044215 पर उपलब्ध है।

मुझे उम्मीद है कि ये सरल सिफारिशें आपको कोड को तेजी से, अधिक कुशलतापूर्वक और अधिक मज़बूती से लिखने की अनुमति देंगी।

सूत्रों का उपयोग किया

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

- Django यूनिट टेस्ट को तेज करना MySQL के साथ चलता है
- इनोडब प्रदर्शन अनुकूलन मूल बातें
- SQLite ऑनलाइन बैकअप एपीआई का उपयोग करना
- पायथन में SQLite के बैकअप का उपयोग कैसे करें