2009-09-13 14 views
5

मेरे पास कुछ काफी सरल कोड है जो एक फोटो या वीडियो को एंडपॉइंट पर अपलोड करता है (HTTP PUT या POST का उपयोग करके)। हर बार मैं कनेक्शन बंद अपवादों को फेंक देता हूं, और हकीकत में फोटो/वीडियो को ठीक से अपलोड किया गया था, यह GetResponse को कॉल कर रहा है जहां अपवाद होता है।इतने लंबे समय तक HttpWebRequest GetResponse ब्लॉक क्यों करता है?

एक बात मैंने देखा है कि GetResponse प्रक्रिया के लिए एक बहुत लंबा समय ले सकता है। अक्सर सर्वर के लिए फोटो के वास्तविक अपलोड समय से अधिक लंबा। मेरा कोड RequestStream.Write का उपयोग कर वेब सर्वर को लिखता है।

मैंने थोड़ा परीक्षण किया और सर्वर पर लगभग 40 फोटो/वीडियो अपलोड किए जो कि 1 एमबी से 85 एमबी के आकार में हैं और वापसी के लिए GetResponse के लिए समय 3 से 40 सेकंड तक था।

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

FYI करें, मेरे अपलोड कर रहे हैं HTTP 1.0, समय समाप्त मान अनंत (दोनों समय समाप्ति और ReadWriteTimeout) के लिए सेट

+1

उमर: आप Fiddler में एक सत्र पर राइट क्लिक करें और "गुण" चुनते हैं, तो आप टाइमर संग्रह देख सकते हैं उस सत्र के लिए।दो दिलचस्प मान "ServerGotRequest" और "ServerBeginResponse" हैं। उन लोगों के बीच डेल्टा क्या है? – EricLaw

उत्तर

6

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

यह पूरी तरह से स्पष्ट नहीं है कि फिडलर आपको क्या दिखा रहा है - क्या यह सर्वर प्रतिक्रिया को भेजने से पहले एक लंबा समय दिखा रहा है? यदि हां, तो आप इतना कुछ नहीं कर सकते हैं। मुझे आश्चर्य है कि कनेक्शन पर आपके लिए कनेक्शन बंद हो रहा है। यदि, हालांकि, आप कुछ समय के लिए सर्वर पर लिखा नहीं देख रहे हैं, तो यह एक अलग मामला है।

क्या आप प्रतिक्रिया वापस ले रहे हैं? यदि नहीं, तो आपके पास कनेक्शन हो सकते हैं जिन्हें जीवित रखा जा रहा है। यह कोई समस्या नहीं है यदि यह स्पष्ट रूप से HTTP 1.0 है, लेकिन यह मेरे अनुभव में "लटकाने" वेब कॉल का सबसे आम कारण है।

असल में, यदि आप WebResponse का निपटान नहीं करते हैं तो यह आमतौर पर कनेक्शन पर रखेगा (कम से कम HTTP 1.1 और रखरखाव के साथ)। कनेक्शन की संख्या की एक सीमा है जो एक मेजबान के लिए खुली हो सकती है, ताकि आप आगे बढ़ने से पहले एक पूर्व प्रतिक्रिया को अंतिम रूप देने तक प्रतीक्षा कर सकें।

यदि यह है समस्या, एक सरल using बयान जवाब है:

using (WebResponse response = request.GetResponse()) 
{ 
    ... 
} 
+0

हां, प्रतिक्रिया पर उपयोग विधि का उपयोग कर रहा है और GetResponseStream पढ़ रहा हूँ। इस मामले में ऐसा लगता है कि मुझे बस इस तथ्य के साथ रहना है कि इसमें काफी समय लग रहा है ... –

0

हाँ, प्रतिक्रिया समय एक बहुत सिर्फ अपलोड समय से अधिक समय हो सकता है। सर्वर पर अनुरोध भेजने के बाद इसे संसाधित करना होगा और एक प्रतिक्रिया वापस करनी होगी। अनुरोध संसाधित होने से कुछ समय पहले हो सकता है, और तब फ़ाइल को आम तौर पर कहीं सेव किया जा रहा है। उसके बाद सर्वर वापस भेजा गया प्रतिक्रिया पृष्ठ तैयार करेगा।

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

+1

<< आईआईएस प्रत्येक उपयोगकर्ता से एक समय में केवल एक अनुरोध संभालता है >> बिल्कुल असत्य है। मुझे लगता है कि आप एएसपी "सत्र" ऑब्जेक्ट के साथ आईआईएस को भ्रमित कर रहे हैं, जिसमें एक म्यूटेक्स था जो परिणामस्वरूप सीमित हो सकता है कि कितने पेज प्रति-उपयोगकर्ता निष्पादित होते हैं। – EricLaw

+0

@EricLaw: मुझे नहीं पता कि वेब सर्वर का कौन सा हिस्सा प्रति उपयोगकर्ता एक पृष्ठ पर इंजन को सीमित कर रहा है, लेकिन चूंकि यह एक .NET प्रश्न है, हम एएसपी.NET इंजन के माध्यम से अनुरोधों के बारे में बात कर रहे हैं। यह निश्चित रूप से सच है कि सर्वर केवल प्रत्येक उपयोगकर्ता से एक अनुरोध को संभालेगा। – Guffa

संबंधित मुद्दे