हेरोकू पर फ्लास्क: request.form बड़े पोस्ट डेटा के साथ अविश्वसनीय रूप से धीमा है?

Question

मैं ईवेंटलेट श्रमिकों के साथ बंदूकधारी का उपयोग करके हेरोोकू पर एक फ्लास्क ऐप चला रहा हूं। मेरे ऐप पर एक विशेष मार्ग अक्सर 500 केबी के क्रम में - कुछ काफी चंकी क्षेत्रों के साथ पोस्ट डेटा (एक्स-www-form-urlencoded) प्राप्त करता है।

यह ठीक काम करता है जब स्थानीय स्तर पर चल रहा है, लेकिन Heroku पर, अनुरोध करता है कि मार्ग 5 से 30 सेकंड से कहीं भी ले जाता है पूरा करने के लिए - और समय की लगभग 100% Request.Form तक पहली पहुँच में खर्च किया जाता है:

t = time.time() 
action = str(request.form['action']) 
dt = time.time() - t # Often 10 seconds or more! 

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

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

क्या किसी को पता है कि क्या गलत हो रहा है? क्या यह फ्लास्क के साथ एक समस्या है, या कुछ है जिसके बारे में मुझे हेरोोकू समर्थन से संपर्क करने की आवश्यकता है?

Answer 1

मुझे लगता है कि मुझे पता चला कि वास्तव में क्या चल रहा था। टीएल; डीआर यह वास्तव में सर्वर अंत में धीमा नहीं था, मुझे न्यूरेलिक के प्रतिक्रिया प्रतिक्रिया समय से गुमराह किया गया था!

मैंने @AllanAnderson के सुझाव के रूप में dotCloud के सैंडबॉक्स पर एक ही कोड चलाने का प्रयास किया। मैंने पहले एक कम परीक्षण केस बनाया: कुछ छिपे हुए फ़ील्ड वाले एक साधारण HTML फॉर्म के बारे में 900 केबी डेटा के साथ प्री-लोड किया गया है, और एक व्यू फ़ंक्शन जो request.form शब्दकोश से पढ़ने के अलावा कुछ भी नहीं करता है और प्रत्येक एक्सेस के लिए समाप्त होने वाले समय को मापता है time.time()।

Heroku पर, परिणाम इस तरह देखा:

5.87100 seconds: read field "p1": 786432 bytes 
0.00019 seconds: read field "p2": 131072 bytes 
0.00003 seconds: read field "p3": 12288 bytes 
0.00001 seconds: read field "p4": 1024 bytes 

और dotCloud पर:

0.00096 seconds: read field "p1": 786432 bytes 
0.00019 seconds: read field "p2": 131072 bytes 
0.00003 seconds: read field "p3": 12288 bytes 
0.00001 seconds: read field "p4": 1024 bytes 

हालांकि, दोनों परीक्षण अपने ब्राउज़र में उतना ही समय लेने के लिए लग रहा था ... और अब तक आपने शायद इस "समस्या" के वास्तविक जवाब का अनुमान लगाया है। :-)

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

इससे न्यूरिलिक की मीट्रिक कम उपयोगी होती है, लेकिन यह वास्तव में अंतिम उपयोगकर्ता अनुभव के साथ कोई समस्या नहीं है।