स्ट्रीमलाइन प्रोसेसिंग

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

प्रागितिहास

मैं वर्तमान में Django में एक बड़ी पर्याप्त परियोजना विकसित कर रहा हूं। यह परियोजना बड़ी है, मैं वास्तव में इसे अकेले विकसित कर रहा हूं, इसलिए अनुकूलन का प्रश्न तभी उठता है जब यह पूरी तरह से गर्म हो। परियोजना की सामान्य तकनीकी जानकारी:
परियोजना का आकार: लगभग 70k लाइनें
Django: 1.4.3
पर्यावरण: apache2 + mod_wsgi + virtualenv, python2.6, mysql, समर्पित सर्वर। सर्वर पर प्रोजेक्ट केवल एक ही नहीं है।

समस्या का मूल्यांकन

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

परिणाम - मुख्य प्रदर्शनों में से एक का औसत रनटाइम 1200 सेमी था, जो बेहद दुखद है।

डेटाबेस अनुकूलन

पहली बात जो दिमाग में आती है वह है डेटाबेस के साथ अप्रभावी काम। काफी बड़ी मात्रा में काम किया गया, जिसने डेटाबेस प्रश्नों की संख्या, उनकी जटिलता (और निष्पादन समय) को आधा कर दिया। यह माना जाता था कि यह स्थिति को सही करेगा, लेकिन परिणाम बिल्कुल प्रभावशाली नहीं था। निष्पादन का समय "केवल" 100ms तक गिर गया और 1100ms हो गया, जिससे मौसम नहीं बना। डेटाबेस अनुकूलन मार्जिन अभी भी बना हुआ है, और कई अन्य तरीके भी हैं, लेकिन यह स्पष्ट हो गया कि समस्या स्पष्ट रूप से डेटाबेस के साथ नहीं थी। प्रस्तुति फ़ंक्शन की एक अधिक विस्तृत रूपरेखा से पता चला कि लगभग 80-90% समय, एक पंक्ति निष्पादित होती है जिसे आप ध्यान देने योग्य नहीं करते हैं:

return direct_to_template(request, template_name, locals()) 

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

नवीनतम संस्करण में hamlpy को अपग्रेड करते हुए लगभग 50ms अधिक जीते। टेम्प्लेट रेंडर करने में अभी भी औसतन 900ms लगते हैं।

इस मुद्दे के एक अधिक विस्तृत अध्ययन ने हमें इस तथ्य के बारे में जानने की अनुमति दी कि django टेम्पलेट्स को कैश कर सकता है, और इसे अलग से कॉन्फ़िगर किया जाना चाहिए:

 TEMPLATE_LOADERS = ( ('django.template.loaders.cached.Loader', ( 'hamlpy.template.loaders.HamlPyFilesystemLoader', 'hamlpy.template.loaders.HamlPyAppDirectoriesLoader', 'django.template.loaders.filesystem.Loader', 'django.template.loaders.app_directories.Loader', )), ) 

टेम्प्लेट का प्रसंस्करण समय स्पष्ट रूप से 500-600ms तक गिर गया, लेकिन फिर भी महत्वपूर्ण बना रहा। उसी समय, एक अप्रिय प्रभाव दिखाई दिया - टेम्पलेट्स में परिवर्तन, जो तार्किक है, मक्खी पर चिपटना बंद कर दिया। इसलिए DEBUG के तहत कैशिंग को मना करना बेहतर है।

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


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

कैशिंग में लौटते हुए, उसका वितरण चार्ट इस तरह दिखता है:


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

WSGIDaemonProcess mysite threads=5 maximum-requests=5


यह अपाचे को चलाने से mod_wsgi तक धागे के जीवन चक्र का अनुवाद करता है और धागे के जीवनकाल को 5 अनुरोधों पर सेट करता है। हम निम्नलिखित चार्ट प्राप्त करते हैं:


जैसा कि आप देख सकते हैं, दाईं ओर की चोटी छोटी हो गई है। धाराएँ अक्सर कम होने लगीं, कैशिंग दक्षता बढ़ गई, औसत निष्पादन समय गिर गया। रास्ता स्पष्ट रूप से सही है, लेकिन अच्छी तरह से काम कर रहे कैशिंग के ग्राफ को स्पष्ट रूप से ऐसा नहीं दिखना चाहिए। हम जीवनकाल बढ़ाकर 10 अनुरोध करते हैं:


पहले से ही बुरा नहीं है। निष्पादन का समय 230ms के स्वीकार्य मूल्य तक उल्लेखनीय रूप से गिर गया है। सबसे अच्छा दुश्मन का है, और धारा का जीवन काल बकवास नहीं है। शीर्ष के माध्यम से स्मृति की खपत का अध्ययन करने से कोई ठोस समस्या नहीं होती है, इसलिए हम जीवनकाल को 15 तक बढ़ाते हैं:


ऐसा शेड्यूल प्रशंसनीय लगता है - गैर-कैशेड अनुरोध सांख्यिकीय रूप से महत्वपूर्ण हो गए हैं, जिसका अर्थ है कि थ्रेड्स के जीवन में और वृद्धि एक मूर्त परिणाम नहीं देगी। कुल प्राप्त निष्पादन समय 190ms है। प्रदर्शन का समय स्वयं 900 से 290 किलोमीटर तक गिर गया है, जो पहले से ही काफी बेहतर है।

निष्कर्ष

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