👩🏽‍🤝‍👩🏼 🤣 🕖 Django ORM, हरे रंग में भूरा और रेक 🌶️ 📃 👎🏻

तो कई अपनी सरलता के लिए Django का चयन करते हैं। Django कोड सरल और संक्षिप्त है, हम बैसाखी के बारे में कम और व्यावसायिक तर्क के बारे में अधिक सोचते हैं।

जीवेंट को इस तथ्य के कारण भी चुना जाता है कि यह सरल, बहुत स्मार्ट है और कॉलबैक नरक नहीं ले जाता है।

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

Django ORM और DB कनेक्शन पूल

Django तुल्यकालिक अनुप्रयोगों के लिए एक ढांचे के रूप में बनाया गया था। प्रत्येक प्रक्रिया को उपयोगकर्ता से एक अनुरोध प्राप्त होता है, इसे पूरी तरह से संसाधित करता है, परिणाम भेजता है, और उसके बाद ही यह किसी अन्य अनुरोध को संसाधित करना शुरू कर सकता है। ऑपरेशन का सिद्धांत सरल है, एक धमाकेदार शलजम की तरह। एक ब्लॉग या समाचार साइट बनाने के लिए महान वास्तुकला, लेकिन हम अधिक चाहते हैं।

एक सरल उदाहरण लें जो HTTP अनुरोधों के साथ एक व्यस्त गतिविधि का अनुकरण करता है। लिंक को छोटा करने के लिए इसे सेवा दें:

# testproject/__init__.py __import__('gevent.monkey').monkey.patch_all() # testproject/main/models.py from django.db import models class LinkModel(models.Model): url = models.URLField(max_length=256, db_index=True, unique=True) # testproject/main/views.py import urllib2, httplib from django.core.urlresolvers import reverse from django.http import HttpResponse, HttpResponseRedirect from .models import LinkModel def check_url(url): request = urllib2.Request(url) request.get_method = lambda: 'HEAD' try: response = urllib2.urlopen(request) except (urllib2.URLError, httplib.HTTPException): return False response.close() return True def remember(request): url = request.GET['url'] try: link = LinkModel.objects.get(url=url) except LinkModel.DoesNotExist: if not check_url(url): return HttpResponse('Oops :(') link = LinkModel.objects.create(url=url) return HttpResponse('http://localhost:8000' + reverse( go_to, args=(str(link.id).encode('base64').strip(), ))) def go_to(request, code): obj = LinkModel.objects.get(id=code.decode('base64')) return HttpResponseRedirect(obj.url)

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

हमने अपनी परियोजना को उव्सगी के माध्यम से लॉन्च किया (जो कि पायथन साइटों को तैनात करते समय वास्तव में मानक बन गया:

 uwsgi --http-socket 0.0.0.0:8000 --gevent 1000 -M -p 2 -w testproject.wsgi

हम एक ही समय में लिंक को छोटा करने और आनन्दित होने के लिए दस अनुरोधों का परीक्षण करने का प्रयास करते हैं: सभी अनुरोध न्यूनतम समय में त्रुटियों के बिना पूरा होते हैं।

हम अपनी नई सेवा शुरू करते हैं, बैठते हैं और इसके सफल विकास को देखते हैं। लोड 10 से 75 एक साथ अनुरोधों से बढ़ता है, और वह इस तरह के भार की परवाह नहीं करता है।

अचानक, निम्नलिखित सामग्री के साथ रातों में से कई हजार पत्र मेल में आते हैं:

 ट्रैस बैक:
    ...
    > लिंक = LinkModel.objects.get (url = url)
 ऑपरेशनलError: FATAL: शेष कनेक्शन स्लॉट गैर-प्रतिकृति सुपरयुसर कनेक्शन के लिए आरक्षित हैं

और यह अच्छा है यदि आप en_US.UTF-8 लोकेल को postgresql.conf पर सेट करते हैं, क्योंकि यदि आपने डिफ़ॉल्ट Ubuntu / Debian कॉन्फ़िगरेशन का उपयोग किया है, तो आपको एक संदेश जैसे एक हजार ईमेल प्राप्त होंगे:

 ऑपरेशनलError: ?????: ??????????  ?????  ???????????  ???????????????  ???  ???????????  ?????????????????  (?? ????????????)

एप्लिकेशन ने बहुत सारे डेटाबेस कनेक्शन बनाए (डिफ़ॉल्ट रूप से, अधिकतम 100 कनेक्शन), जिसके लिए उसे दंडित किया गया था।

यहाँ बहुत पहला नुकसान है: Django के पास डेटाबेस कनेक्शन पूल नहीं है , क्योंकि यह केवल सिंक्रोनस कोड में आवश्यक नहीं है। एक एकल तुल्यकालिक Django प्रक्रिया समानांतर में अनुरोधों को संसाधित नहीं कर सकती है; यह किसी भी एक समय में केवल एक अनुरोध प्रदान करता है, और इसलिए इसे एक से अधिक डेटाबेस कनेक्शन बनाने की आवश्यकता नहीं है।

वास्तव में ...

वास्तव में, Django मल्टी-थ्रेडेड मोड में काम कर सकता है, जिसमें एक प्रक्रिया कई अनुरोधों को संभाल सकती है। यह एक ऐसा सर्वर है, जिसे मैनेजमेन्डो रनसर्वर कमांड लॉन्च करता है , जबकि डॉक्यूमेंटेशन का कहना है कि यह मोड पूरी तरह से मुकाबला करने के लिए अनुपयुक्त है।

केवल एक समाधान है: हमें तत्काल डेटाबेस कनेक्शन के पूल की आवश्यकता है।

Django के लिए अपेक्षाकृत कुछ पूल कार्यान्वयन हैं, उदाहरण के लिए django-db-pool और django-psycopg2-pool । पहला पूल psycopg2.TreadedConnectionPool पर आधारित है, जो एक खाली पूल से कनेक्शन लेने की कोशिश करते समय एक अपवाद फेंकता है। एप्लिकेशन पहले की तरह ही व्यवहार करेगा, लेकिन अन्य एप्लिकेशन डेटाबेस से कनेक्शन बनाने में सक्षम होंगे। दूसरा पूल gevent.Queue पर आधारित है: जब आप किसी खाली पूल से कनेक्शन लेने की कोशिश करते हैं, तो ग्रीनलेट तब तक अवरुद्ध हो जाएगा जब तक कि एक और ग्रीनलेट कनेक्शन को पूल में नहीं डाल देता।
सबसे अधिक संभावना है कि आप दूसरे समाधान को अधिक तार्किक के रूप में चुनेंगे।

डेटाबेस क्वेरीज़ ग्रीनलेट्स के अंदर

हमने पहले से ही जियोवेंट का उपयोग करके एप्लिकेशन को पैच कर दिया है और हमारे पास कुछ सिंक्रोनस कॉल हैं, इसलिए ग्रीनलेट्स का सबसे अधिक निचोड़ क्यों नहीं? हम कई HTTP अनुरोध समानांतर में बना सकते हैं या उपप्रोसेस बना सकते हैं। हम डेटाबेस को ग्रीनलेट्स में उपयोग करना चाहते हैं:

 def some_view(request): greenlets = [gevent.spawn(handler, i) for i in xrange(5)] gevent.joinall(greenlets) return HttpResponse("Done") def handler(number): obj = MyModel.objects.get(id=number) obj.response = send_http_request_somewhere(obj.request) obj.save(update_fields=['response'])

कई घंटे बीत गए, और अचानक हमारे आवेदन ने पूरी तरह से काम करना बंद कर दिया: किसी भी अनुरोध के लिए हमें 504 गेटवे टाइमआउट मिला । इस बार क्या हुआ? स्पष्टीकरण के लिए आपको कुछ Django कोड पढ़ना होगा।

सभी कनेक्शन django.db.connections द्वारा संग्रहीत किए जाते हैं , जो django.db.utils.ConnectionHandler वर्ग का एक उदाहरण है। जब ओआरएम अनुरोध करने के लिए तैयार होता है, तो यह कनेक्शन ['डिफ़ॉल्ट'] को कॉल करके डेटाबेस से कनेक्शन का अनुरोध करता है। ConnectionHandler .__ getattr__ , ConnectionHandler._connections में कनेक्शन के बदले में चेक करता है, और यदि यह खाली है, तो यह एक नया कनेक्शन बनाता है।

उपयोग के बाद सभी खुले कनेक्शन बंद होने चाहिए। Request_finished संकेत, जो django.http.HttpResponseBase.close में चलता है, ऐसा करता है । Django बहुत अंतिम समय में डेटाबेस कनेक्शन बंद कर देता है, जब कोई भी उनसे संपर्क नहीं करेगा, जो काफी तार्किक है।

पकड़ बिल्कुल है कि कैसे ConnectionHandler डेटाबेस कनेक्शन संग्रहीत करता है। ऐसा करने के लिए, वह थ्रेडिंग.लोक का उपयोग करता है, जिसे मैनपिंग करने के बाद gevent.local.local में बदल जाता है। एक बार घोषित किए जाने के बाद, यह डेटा संरचना काम करती है जैसे कि यह हर ग्रीनलेट में अद्वितीय थी। कुछ_व्यू नियंत्रक को एक ग्रीनलेट में संसाधित किया जाना शुरू हुआ, और ConnectionHandler._connections में पहले से ही एक डेटाबेस कनेक्शन है। हमने कई नए ग्रीनलेट बनाए, जिनमें ConnectionHandler._connections खाली हो गए, और इन ग्रीनलेट्स के लिए पूल से अधिक कनेक्शन ले लिए गए। हमारे नए ग्रीनलेट्स गायब हो जाने के बाद, उनके स्थानीय () गायब हो जाने की सामग्री गायब हो गई थी, डेटाबेस से कनेक्शन बिल्कुल खो गए थे और कोई भी उन्हें वापस पूल में नहीं लौटा रहा था। समय के साथ, पूल पूरी तरह से खाली है।

Django + gevent को विकसित करते समय, आपको हमेशा इस बारीकियों को याद रखना होगा और django.db.close_connection को कॉल करके प्रत्येक ग्रीनलेट के अंत में डेटाबेस कनेक्शन को बंद करना होगा । अपवाद होने पर भी आपको इसे कॉल करने की आवश्यकता होती है, जिसके लिए आप एक छोटे से डेकोरेटर-प्रसंगकर्ता का उपयोग कर सकते हैं।

इस तरह के एक डेकोरेटर का एक उदाहरण

 class autoclose(object): def __init__(self, f=None): self.f = f def __call__(self, *args, **kwargs): with self: return self.f(*args, **kwargs) def __enter__(self): pass def __exit__(self, exc_type, exc_info, tb): from django.db import close_connection close_connection() return exc_type is None

आपको इस आवरण का बुद्धिमानी से उपयोग करने की आवश्यकता है: ग्रीनलेट्स के प्रत्येक स्विच से पहले सभी कनेक्शनों को बंद करें (उदाहरण के लिए, urllib2.urlopen से पहले), और यह भी सुनिश्चित करें कि मॉडल . objects.all () जैसे इटैलिक ट्रांजेक्शन या लूप के माध्यम से कनेक्शन बंद न हों।

हम Django ORM का उपयोग Django से अलग करते हैं

यदि हम क्रोन या सेलेरी का एनालॉग बनाते हैं, तो हम उन्हीं समस्याओं को समझ सकते हैं, जो समय-समय पर डेटाबेस से प्रश्न करेंगे। यदि आप Django को gevent.WSGIServer का उपयोग करके उठाते हैं तो वही चीज हमें इंतजार करती है और साथ ही साथ एक अलग प्रोटोकॉल के साथ किसी भी सेवा को बढ़ाते हैं जो Django ORM उपयोग करेगा। मुख्य बात डेटाबेस पूल में समय पर कनेक्शन वापस करना है, फिर आवेदन पूरी तरह से काम करेगा और आपको खुशी देगा।

निष्कर्ष

इस पोस्ट में, प्राथमिक नियमों के बारे में कहा गया था कि आपको डेटाबेस कनेक्शन पूल का उपयोग करना होगा और उपयोग के तुरंत बाद आपको कनेक्शन को वापस पूल में वापस करना होगा। आप निश्चित रूप से इस पर विचार करेंगे यदि आपने केवल gevent और psycopg2 का उपयोग किया है। लेकिन Django ORM ऐसे उच्च-स्तरीय अमूर्त के साथ काम करता है जो डेवलपर डेटाबेस कनेक्शन के साथ व्यवहार नहीं करता है, और समय के साथ, इन नियमों को भुलाया और फिर से खोजा जा सकता है।

Django ORM, हरे रंग में भूरा और रेक

Django ORM और DB कनेक्शन पूल

डेटाबेस क्वेरीज़ ग्रीनलेट्स के अंदर

हम Django ORM का उपयोग Django से अलग करते हैं

निष्कर्ष

More articles: