2012-03-20 14 views
15

मैं जल्द ही एक उच्च प्रदर्शन एएसपी.नेट जेसन एपीआई लिख रहा हूं> 1000 अनुरोध/दूसरा। मेरे सभी तर्क और प्रसंस्करण एक IHttpHandler में किया जाता है। मैंने स्टॉपवॉच क्लास के माध्यम से मापा और हैंडलर 0,1 - 0,5 मिलीसेकंड में एक अनुरोध पूरा करता है।उच्च प्रदर्शन एएसपी.नेट साइट (> 1000 अनुरोध/सेकेंड)

लेकिन ऐसा लगता है कि आईआईएस और/या अन्य HTTP हैंडलर (मॉड्यूल?) बहुत सारे प्रदर्शन को दूर कर रहे हैं। क्या मैं इसे किसी भी तरह माप सकता हूं? सर्वोत्तम प्रदर्शन के लिए कॉन्फ़िगर किए जाने पर आईआईएस में अनुरोध कितना ओवरहेड होगा?

उन सभी HTTPHandlers सहायता को हटा देगा, या इसे गति देने के लिए अन्य चालें हैं? मुझे सत्र के अलावा एएसपी.NET फीचर्स की अधिक आवश्यकता नहीं है (यह भी कामकाज कर सकता है कि अगर यह एक महत्वपूर्ण प्रदर्शन बढ़ावा देता है)।

+1

के बाद से यह मूल रूप से 'async है और स्वयं के द्वारा होस्ट (ताकि आप IIS में चल रहा से बचने कर सकते) हो सकता है, ऐसा लगता है जैसे कि यह ASP.NET वेब एपीआई (बिल्ट-इन MVC4 करने पर देख लायक हो जाएगा, लेकिन यह भी उपलब्ध स्टैंडअलोन)। मैं @ http://blogs.msdn.com/b/henrikn/ –

+2

Fwiw, प्रश्न के शब्दों में एक छोटे से मुझे अब तक के लिए अजीब है हेनरिक के ब्लॉग से इसके बारे में एक अच्छा सा सीखा है के रूप में यह मिश्रण करने विलंबता/बैंडविड्थ लगता है (नेटवर्क शर्तों का उपयोग करने के लिए)।एक विशेष अनुरोध की सेवा करने की विलंबता प्रभावी और समवर्ती रूप से उनकी सेवा करने की क्षमता के सापेक्ष महत्वपूर्ण (बाहरी उपयोगकर्ता अनुभव के बाहर, लेकिन स्केलेबिलिटी के लिए ऑर्थोगोनल) के रूप में महत्वपूर्ण नहीं लगती है। आईओयू, अगर हर अनुरोध ने सेवा के लिए 1000ms लिया, लेकिन आप एक समय में 2000 की सेवा कर सकते हैं, तो आप अभी भी ठीक रहेगा, है ना? –

+0

यह सुनिश्चित नहीं है कि आपके द्वारा बनाए जा रहे एपीआई पर यह कितना लागू होगा, लेकिन यदि कुछ भी कैश करने योग्य है, तो ऐसा करना सुनिश्चित करें। और यदि आप स्टेटलेस रह सकते हैं, तो संभवतः आप एआरआर का उपयोग कर सकते हैं और यदि आवश्यक हो तो स्केल आउट कर सकते हैं। –

उत्तर

9

वेब सर्वर का प्रदर्शन मापना कोई मामूली कार्य नहीं है। विचार करने के लिए कुछ बातें:

  • वास्तविक बाधा पाएं। यह स्मृति, डिस्क का उपयोग, कैशिंग, डेटाबेस पहुंच, नेटवर्क विलंबता आदि हो सकता है। पता लगाने के लिए एक मेमोरी प्रोफाइलर, या अन्य performance profiler का उपयोग करें।
  • WireShark का उपयोग करें ताकि यह पता लगा सके कि आपके मशीन पर अनुरोध कितना समय है और आपका कोड कितना समय चलता है।
  • अन्य कॉन्फ़िगरेशन आज़माएं। एएसपी.नेट को और अधिक मेमोरी दें। परीक्षण प्रणाली को अपग्रेड करें। यानी, 8 जीबी/2.5 गीगाहर्ट्ज से 600 अनुरोध/सेकेंड से 16 जीबी/3.0GHz तक जाकर 6500 अनुरोध/सेकेंड मिल सकते हैं। प्रदर्शन वृद्धि अक्सर रैखिक नहीं है। this document from Microsoft देखें।
  • अतिरिक्त मशीन जोड़ने पर विचार करें। यह आपके द्वारा कॉन्फ़िगर किए जाने के तरीके के आधार पर 50 या उससे अधिक प्रदर्शन अपग्रेड तक पहुंच सकता है। एमएस से फिर से दस्तावेज़ देखें।
  • these hints by Jon Skeet देखें। टिप्पणी धागा कुछ गैर-स्पष्ट संभावित बाधाओं को भी प्रकट करता है।

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

नोट 2: स्टैक ओवरफ्लो के मूल साइड-लक्ष्यों में से एक एएसपी.नेट में एक साइट बनाना था जिसमें अधिकतम 2 सर्वर पर शानदार प्रदर्शन था और प्रति घंटे 1 एमएलएन आगंतुकों को संभाला जा सकता था। वे ऐसा करने में कामयाब रहे। मेरा मानना ​​है कि उन्होंने कुछ ब्लॉगपोस्ट लिखे हैं, लेकिन मुझे याद नहीं है कि वे कहां हैं।

5

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

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

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

+0

दरअसल, यह एक सुनहरा नियम नहीं है कि _tiny_ सर्वर एक बड़े HTTP सर्वर से अधिक अनुरोधों की सेवा कर सकता है। विपरीत अधिक आम है। – Abel

+1

यह छोटे और बड़े के बारे में नहीं है। यह प्रति अनुरोध चलाने वाले कोड की मात्रा के बारे में है। हम विलंबता से बता सकते हैं कि ओपी ने उल्लेख किया है कि बहुत सारे कोड चल रहे हैं। HTTP शीर्षकों को पार्स करने और सॉकेट का उपयोग करने से कहीं अधिक। – usr

+1

सक्षम मॉड्यूल को हटाने के साथ सहमत हैं। असफल इवेंट ट्रेसिंग सक्षम करें (100-999 प्रतिक्रियाओं के लिए) और बुलाए गए सभी मॉड्यूल देखें। फिर उन सभी मॉड्यूल को हटा दें जिनकी आपको आवश्यकता नहीं है। - मैं छोटे सर्वर विचार से असहमत हूं (लेकिन मैंने आपको वैसे भी ऊपर उठाया :)) – RickAndMSFT

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