क्या कोई लेख/पुस्तक है जो डब्ल्यूएस टाइमआउट के लिए ऊपरी सीमा वाली डिज़ाइन सीमा को परिभाषित करती है? क्या आप सर्वर पर टाइमआउट करते हैं या क्लाइंट विशिष्ट टाइमआउट्स की भी सलाह देते हैं?वेब सेवा टाइमआउट के लिए सर्वोत्तम अभ्यास
है वहाँ की तरह "WS कि लंबे समय तक 60 सेकंड से ले जा सकते हैं डिजाइन कभी नहीं, का उपयोग एक अतुल्यकालिक टोकन पैटर्न"
मैं जानते हुए भी क्या आप भी कर सकते हैं या आपकी राय में दिलचस्पी है एक आम सबसे अच्छा अभ्यास।
यह सवाल है, और यह के जवाब में से जुड़ा हुआ हैं, मदद कर सकता है: Is there some industry standard for unacceptable webapp response time?
अपने प्रश्न का कुछ हद तक स्पर्शरेखा (कोई समय अंतराल, खेद), लेकिन मैं अपने काम के लिए उपयोगी संदेह: एक आम टाइमआउट के लिए दृष्टिकोण उन्हें "बैक-ऑफ" टाइमर के साथ संतुलित करना है।
यह इस तरह कुछ चला जाता है: पहली बार सेवा समय समाप्त होने पर, इसके बारे में चिंता न करें। पंक्ति में दूसरी बार एक सेवा समय समाप्त होने पर, इसे एन सेकंड के लिए कॉल करने से परेशान न करें। पंक्ति में तीसरी बार एक सेवा समय बाहर, इसे एन + 1 सेकंड के लिए कॉल न करें। फिर एन + 2, एन + 3, एन +5, एन +8, आदि, जब तक आप कुछ अधिकतम सीमा तक पहुंच नहीं पाते हैं एम
जब आपको वैध प्रतिक्रिया मिलती है तो टाइमआउट काउंटर रीसेट हो जाता है।
मैं यहां "बैक-ऑफ" समय अवधि बढ़ाने के लिए एक फाइबोनैकी अनुक्रम का उपयोग कर रहा हूं, लेकिन निश्चित रूप से आप किसी भी अन्य उपयुक्त कार्य का उपयोग कर सकते हैं - बिंदु यह है कि यदि आप जिस सेवा की कोशिश कर रहे हैं, वह आपको समय देता है, तो आप " विश्वास "इसमें छोटे और छोटे हो जाते हैं, इसलिए आप इसे कम करने के लिए कम संसाधन खर्च करते हैं, और दरवाजे पर अधिक दुर्लभ रूप से दस्तक देते हैं। इससे दूसरी छोर पर सेवा में मदद मिल सकती है, जिसे आसानी से अधिभारित किया जा सकता है और फिर से अनुरोध करने से मामलों को और भी खराब कर दिया जा सकता है, और यह आपके प्रतिक्रिया समय को बढ़ाएगा क्योंकि आप उस सेवा के लिए इंतजार नहीं करेंगे जो उत्तर देने की संभावना नहीं है।
अपनी वेब सेवा के माध्यम से ट्रांसफर करने वाले डेटा की मात्रा लें, यह देखने के लिए कि प्रक्रिया कितनी देर तक लेती है।
उस संख्या और परीक्षण में 60 सेकंड जोड़ें।
यदि आप इसे अच्छे कनेक्शन पर टाइमआउट पर प्राप्त कर सकते हैं तो 30 और सेकंड जोड़ें।
कुल्ला और दोहराना।
हम आम तौर पर उस वेब सेवा के लिए अपेक्षित प्रतिक्रिया समय लेते हैं (जैसा कि हमारे इंटरफेस विनिर्देश में दस्तावेज है) और इसमें 30 सेकंड जोड़ें।
फिर हम यूएटी के दौरान लॉग देखने की निगरानी करते हैं कि क्या कोई पैटर्न है (उदा। विशिष्ट डीबी कॉल लंबे समय लेते हैं) और उचित के रूप में बदलते हैं।
यह सामान लगभग 30+ सेकंड टाइमआउट हास्यास्पद सलाह है, आईएमओ। आपका टाइमआउट लगभग 3 सेकंड होना चाहिए। हाँ। तीन। दो और पहले चार के बाद की संख्या। यदि आप एसओए के आधार पर एक आवेदन बना रहे हैं, तो निश्चित रूप से 3 सेकंड, या कम।
इसके बारे में सोचें ... आपके ऐप के उपयोगकर्ता को लगभग पांच सेकंड या उससे कम (अधिमानतः लगभग तीन) के कुल प्रतिक्रिया समय की उम्मीद है। यदि प्रत्येक व्यक्तिगत सेवा कॉल वापस लौटने के लिए कुछ * मिलीसेकंड * से अधिक ले रही है, तो आप को रोक दिया गया है। एक सेवा लौटने के लिए 30+ सेकंड प्रतीक्षा करना एक अनंत काल है। उपयोगकर्ता उस लंबे समय तक कभी इंतजार नहीं करेगा।इसके अलावा, यदि आप जानते हैं कि उन्हें उप-एक दूसरी श्रेणी में वापस जाना है, तो या किसी त्रुटि स्थिति को सिग्नल करने के लिए और अधिक सेकंड की प्रतीक्षा करने का क्या मतलब है; यह जादुई रूप से काम नहीं करेगा जहां 28 सेकंड पहले नहीं था। यदि आपके आवेदन में औसत प्रतिक्रिया समय में जंगली स्विंग्स उप-एक सेकेंड से 30 सेकंड तक है, तो कुछ गलत तरीके से डिज़ाइन किया गया था। आप कुछ कैशिंग या कुछ के बारे में सोच सकते हैं।
यह एप्लिकेशन सर्वर के बीच एक सेवा हो सकता है, वास्तव में उपयोगकर्ता से संबंधित नहीं है। – MMind
दिलचस्प, @Robert आप उस नंबर पर कैसे आते हैं: 3 सेकंड? – DanielV
यह सलाह facetious लगता है। बेशक उपयोगकर्ता त्वरित प्रतिक्रिया की उम्मीद करते हैं, लेकिन 20 सेकंड में वैध जवाब प्राप्त करने से 3 सेकंड में वास्तव में बेहतर त्रुटि प्राप्त हो रही है? एक त्वरित प्रतिक्रिया के लिए डिजाइनिंग और क्लाइंट टाइमआउट चुनना एक ही बात नहीं है। – Nick
सर्वर को हथौड़ा होने से रोकने के लिए एक रैखिक प्रगति (उदाहरण के लिए एन, 2 एन, 4 एन) की बजाय ज्यामितीय प्रगति होना आम बात है। – ashes999
पहले के बाद प्रत्येक पुनः प्रयास में यादृच्छिक राशि जोड़ना भी आम है ताकि नीचे दी गई सेवा उसी सटीक समय पर पुनः प्रयास करके सब कुछ नष्ट न हो। –