ASP.NET MVC प्रदर्शन

Question

मुझे कुछ जंगली टिप्पणी मिली कि ASP.NET MVC, ASP.NET WebForms की तुलना में 30 गुना तेज है। वास्तविक प्रदर्शन अंतर क्या है, क्या इसे मापा गया है और प्रदर्शन लाभ क्या हैं।

यह ASP.NET MVC से ASP.NET वेबफ़ॉर्म से आगे बढ़ने पर विचार करने में मेरी मदद करने के लिए है।

Comments

WebForms के साथ काम करने के बाद जब से वे बाहर आए, मैं कभी भी स्वेच्छा से वापस नहीं जाऊंगा! MVC ने मेरे <3 को चुरा लिया है - और यह साइट बीटा 5 पर अजीब तरह से चल रही है!

— जारोड डिक्सन

इस प्रश्न पर सभी संशोधन रोलबैक के साथ क्या है ..?

— निक

@ निक: ओपी किसी भी संपादन को वापस ला रहा है, और उन्हें समझाते हुए किसी भी टिप्पणी को हटा रहा है।

— GEOCHET

@ रीच बी: सही है, उन्होंने मेरी 5 टिप्पणियों को हटा दिया।

— जॉर्ज स्टॉकर

अब हमें MVC3 रिलीज़ के करीब पहुंचने के लिए एक अपडेट की आवश्यकता है।

— एंड्रयू लुईस

Answer 1

हमने किसी भी निष्कर्ष के साथ आने के लिए स्केलेबिलिटी और पूर्ण परीक्षण के प्रकार का प्रदर्शन नहीं किया है। मुझे लगता है कि स्कॉटगू संभावित पूर्ण लक्ष्यों पर चर्चा कर रहा होगा। जैसे-जैसे हम बीटा और आरटीएम की ओर बढ़ते हैं, हम आंतरिक रूप से अधिक परिपूर्ण परीक्षण करेंगे। हालाँकि, मुझे यकीन नहीं है कि हमारी नीति संपूर्ण परीक्षणों के परिणामों को प्रकाशित करने पर है।

किसी भी मामले में, ऐसे किसी भी परीक्षण को वास्तव में वास्तविक दुनिया अनुप्रयोगों पर विचार करने की आवश्यकता है ...

Comments

अब जब एमवीसी जारी किया गया है, तो क्या पूर्ण परिणाम जारी करने पर कोई अपडेट है?

— क्रिस

सिर्फ इसलिए वोट देना क्योंकि 5,999 प्रतिनिधि स्कोर मेरी आँखों को चोट पहुँचा रहा था :(

— डेमियन

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

— तवानफोसन

संख्या 42 है। :) सामान्य तौर पर, हमारी संख्या शायद वास्तविक दुनिया के ऐप्स के लिए बेकार होगी इसलिए हम एक नियम के रूप में उन्हें बाहर नहीं देते हैं। हालाँकि, मुझे Microsoft की अन्य टीमों के बारे में पता है कि वे बड़े पैमाने पर वेबसाइटों का निर्माण करती हैं जो अनुकूल संख्या दिखाती हैं। दूसरे शब्दों में, किसी भी पूर्ण मुद्दे की रूपरेखा में किसी भी अंतर्निहित मुद्दों की तुलना में प्रोग्रामर गलतियों के कारण होने की अधिक संभावना है। आमतौर पर डेटाबेस और बाहरी सेवाओं के साथ बातचीत अपराधी हैं। :)

— हेक

सच! कृपया इसे अपडेट करें! हो सकता है कि बेंचमार्क न हो लेकिन एक संक्षिप्त विचार, क्या वे बराबर हैं या mvc एक वीईटी पर बेहतर है?

— गिदोन

Answer 2

मुझे लगता है कि यह निश्चित रूप से जवाब देने के लिए एक कठिन सवाल होगा क्योंकि ए पर बहुत निर्भर करेगा ) कि आप वेबफार्म एप्लिकेशन कैसे लागू करते हैं, और बी) आप एमवीसी एप्लिकेशन को कैसे लागू करते हैं। अपने "कच्चे" रूपों में, MVC WebForms की तुलना में तेजी से संभव है, लेकिन साल और साल के उपकरण और अनुभव ने तेजी से WebForms अनुप्रयोगों के निर्माण के लिए कई तकनीकों का उत्पादन किया है। मैं शर्त लगा सकता हूं कि एक वरिष्ठ ASP.NET डेवलपर एक WebForms एप्लिकेशन का उत्पादन कर सकता है जो किसी भी MVC एप्लिकेशन की गति को प्रतिद्वंद्वी करता है- या कम से कम एक नगण्य अंतर को प्राप्त करता है।

असली अंतर- जैसा कि @tvanfosson ने सुझाव दिया है - परीक्षण योग्य और स्वच्छ SoC में है। यदि प्रदर्शन में सुधार करना आपकी मुख्य चिंता है, तो मुझे नहीं लगता कि WebForms पर जहाज कूदने और MVC में फिर से निर्माण शुरू करने का यह एक बड़ा कारण है। कम से कम तब तक जब तक आप WebForms के अनुकूलन के लिए उपलब्ध तकनीकों की कोशिश नहीं करते।

Comments

महान जवाब टोड (एक डेवलपर इंजीलवादी के लिए वास्तव में व्यावहारिक प्रतिक्रिया के लिए कितना आश्चर्य की बात है)। केवल एक चीज जो आपको गलत लगी वह है कच्चे कार्यान्वयन वेबफॉर्म में वास्तव में काफी तेजी से।

— क्रिस मैरिसिक

Answer 3

इसने 2 एमबी पेलोड से 200k तक मेरे पृष्ठों में से एक को घटा दिया, बस व्यूस्टेट को हटाकर प्रस्तुत आउटपुट के साथ काम करने के लिए इसे प्रोग्रामेबल तरीके से बीरेबल बना दिया।

अकेले आकार, भले ही प्रसंस्करण एक ही था, प्रति सेकंड कनेक्शन और अनुरोधों की गति में भारी सुधार पैदा करेगा।

Comments

आप MVC के बिना भी pesky बड़े देखने का समय तय कर सकते हैं

— आंद्रेई R Augnea

बस ViewState विस्तृत करने के लिए @ पेज स्तर या web.config में बंद किया जा सकता है

— bbqchickenrobot

हाँ, लेकिन एमवीसी में इसकी एक सेंस डिफॉल्ट एक डिज़ाइन निर्णय नहीं है जो आपको सभी नियंत्रणों को छोड़ने के लिए मजबूर करता है और वे विक्रेता जो वेब प्रपत्रों पर काम करने का दावा करते हैं, वेब प्रपत्रों को अपनी गलत हड्डी को हटाकर "गलत व्यवहार" करते हैं। मैं इस बात से असहमत नहीं हूं कि आप सिर्फ उस पृष्ठ को फिर से बना सकते हैं, लेकिन संपूर्ण ऐप बिना देखे ही बेहतर था।

— विकासशील

तब न तो आपको लगता है कि यह web.config में व्यूस्टेट को बंद करने के बजाय पूरे ऐप को MVC में पोर्ट करने का सबसे खराब निर्णय है? और नहीं, देखने वाला रीढ़ नहीं है। केवल अगर आपने शोध किया है, तो व्यूस्टेट को कैश के साथ-साथ सत्रों में भी रखा जा सकता है।

— सरल फैलो

Answer 4

मुझे लगता है कि बहुत से लोग जो सोचते हैं कि WebForms स्वाभाविक रूप से धीमा हैं या संसाधन गहन दोष को गलत जगह पर रख रहे हैं। 10 में से 9 बार जब मैं एक वेबफॉर्म ऐप को ऑप्टिमाइज़ करने के लिए लाया जाता हूं, तो कई जगहों पर ऐसे रास्ते होते हैं जहां ऐप लेखक व्यूस्ट के उद्देश्य को गलत समझते हैं। मैं यह नहीं कह रहा हूं कि व्यूस्टेट बिल्कुल सही है या कुछ भी, लेकिन यह दुरुपयोग करने के लिए बहुत आसान है, और यह यह दुरुपयोग है जो फूला हुआ व्यूस्टेट क्षेत्र का कारण बन रहा है।

यह लेख मुझे इन गालियों को समझने में मदद करने में अमूल्य था। https://weblogs.asp.net/infinitiesloop/truly-understanding-viewstate

MVC और WebForms के बीच एक वैध तुलना करने के लिए हमें यह सुनिश्चित करने की आवश्यकता है कि दोनों एप्लिकेशन आर्किटेक्चर का सही उपयोग कर रहे हैं।

Answer 5

मेरा परीक्षण एमवीसी पर 2x और 7x अधिक req / sec के बीच कुछ दिखाता है, लेकिन यह निर्भर करता है कि आप अपने webforms ऐप का निर्माण कैसे करते हैं। उस पर सिर्फ "हैलो वर्ल्ड" टेक्स्ट के साथ, बिना किसी सर्वर साइड कंट्रोल के, mvc लगभग 30-50% तेज है।

Answer 6

मेरे लिए एमवीसी में वास्तविक "प्रदर्शन" सुधार आवेदन की परीक्षण योग्य सतह में वृद्धि है। WebForms के साथ बहुत सारे अनुप्रयोग थे जिनका परीक्षण करना कठिन था। एमवीसी के साथ कोड की मात्रा जो मूल रूप से परीक्षण योग्य हो जाती है, दोगुनी हो जाती है। मूल रूप से सभी जो आसानी से परीक्षण योग्य नहीं है वह कोड है जो लेआउट उत्पन्न करता है। आपके सभी व्यावसायिक तर्क और डेटा एक्सेस लॉजिक - तर्क सहित, जो दृश्य में उपयोग किए जाने वाले वास्तविक डेटा को पॉप्युलेट करता है - अब परीक्षण के लिए उत्तरदायी है। जबकि मुझे उम्मीद है कि यह और अधिक अच्छा होगा - पेज जीवन चक्र बहुत सरल है और वेब प्रोग्रामिंग के लिए अधिक उत्तरदायी है - भले ही यह एक ही या थोड़ा धीमा हो, यह एक गुणवत्ता के दृष्टिकोण से स्विच करने के लायक होगा।

Comments

मैं वास्तव में यह जानना पसंद करूंगा कि किसी ने इस उत्तर को क्यों गलत समझा।

— तवान्फोसन

मेरी समझ यह है कि यह डाउनवोट हो सकता है क्योंकि एक अच्छी तरह से डिज़ाइन किया गया ASP.NET वेब एप्लिकेशन एक MVC एप्लिकेशन के रूप में परीक्षण योग्य है। दोनों को विकसित करने के साथ मेरा अनुभव यह है कि एमवीसी आपको एक स्वच्छ प्रोग्रामिंग मॉडल (जो इसकी सबसे बड़ी ताकत, आईएमओ में से एक है) में मजबूर करता है। वेब फॉर्म आपको आलसी चीजें करने की सुविधा देते हैं, लेकिन वेब रूपों में एक ही परीक्षण योग्य सतह होना अभी भी बहुत संभव है। वैसे भी मेरा अनुमान है।

— dudemonkey

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

— रिचर्ड हाउर

@ रीचर्ड हाउर वस्तुतः यह सच नहीं था जब मैंने यह लिखा था लेकिन उन्होंने उस पर सुधार किया है। चूंकि WebForms को .NET Core में कोई भविष्य नहीं लगता है, इसलिए यह एक म्यूट पॉइंट लगता है।

— tvanfosson

@tvanfosson सहमत - अब यह लूट है। निश्चित नहीं है कि आपको कौन सा बिट लगता है कि यह सच नहीं है, शायद आपको "सचमुच" के मेरे उपयोग पर आपत्ति है? वैसे भी, टैग हेल्पर्स के साथ MVC के नए संस्करण, लेआउट में कोड डालने की आदत को तोड़ने में मदद करते हैं जो अंततः मेरे लिए यह सब काम कर सकता है। इस पोस्ट की सराहना करना निश्चित रूप से काफी पुराना है, लेकिन उस समय भी, एक अच्छी तरह से बनाया गया वेबफोर्म फॉर्म एमवीसी के "मैजिक वायरिंग" में से कोई भी नहीं है और कोई भी कोड बिल्कुल भी नहीं है।

— रिचर्ड हाउर

Answer 7

मुझे लगता है कि यहां समस्या यह है कि पुराने वेबफॉर्म की तुलना में एएसपी.नेट एमवीसी कितना भी तेज क्यों न हो, इससे कोई फर्क नहीं पड़ेगा, क्योंकि ज्यादातर समय डेटाबेस में लगता है। अधिकांश समय, आप वेब सर्वर 0-10% CPU उपयोग के लिए बैठे रहेंगे, बस अपने डेटाबेस सर्वर पर प्रतीक्षा कर रहे हैं। जब तक आपको अपनी वेबसाइट पर बहुत बड़ी संख्या में हिट नहीं मिलते हैं, और आपका डेटाबेस बहुत तेज़ है, तब तक शायद आपको बड़ा अंतर नज़र नहीं आएगा।

Comments

आपके उपयोगकर्ता हो सकते हैं - कोई दृश्य नहीं।

— उपराष्ट्रपति

Answer 8

केवल वही ठोस संख्याएँ जो मुझे मिल सकती हैं जो कि शुरुआती ASP.NET MVC- विकास से हैं, इस फोरम-थ्रेड पर हैं:

http://forums.asp.net/p/1231621/2224136.aspx

रॉब कॉनरी खुद कुछ हद तक इस कथन की पुष्टि करता है कि स्कॉटग्यू ने दावा किया है कि ASP.NET MVC प्रति सेकंड 8000 अनुरोधों की सेवा दे सकता है।

हो सकता है कि जेफ़ और उनका दल इस साइट के विकास से किसी तरह का संकेत दे सकते हैं।

Answer 9

स्वीकृत राय के विपरीत, अनुकूलित वेबफॉर्म का उपयोग कच्चे प्रदर्शन के मामले में एमवीसी को पूरी तरह से मार देता है। MVC के पास अब तक HTML की सेवा के कार्य के लिए वेबफॉर्म हाइपर-ऑप्टिमाइज़ किए गए हैं।

मेट्रिक्स http://www.techempower.com/benchmark/#section=data-r7&hw=i7&test=db पर उपलब्ध हैं

हर एक तुलना mvc सूची के निचले-मध्य / निचले-ऊपरी रैंकिंग पर है, जबकि ऊपरी-मध्य / ऊपरी-निचली रैंकिंग में अनुकूलित वेबफॉर्म का उपयोग स्थान है।

इन मेट्रिक्स के एनकाउंटर लेकिन बहुत गंभीर सत्यापन, www.microsoft.com MVC नहीं, बल्कि वेबफॉर्म द्वारा किए जाते हैं। क्या यहां किसी को विश्वास है कि अगर यह आनुभविक रूप से तेज होता तो वे MVC को नहीं चुनते?

Answer 10

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

Answer 11

मैंने लगभग एक साल पहले एमवीसी में काम शुरू किया था, मैं प्रेरित हुआ लेकिन प्रभावित नहीं हुआ।

मैं दृश्य स्थिति को ढीला करता हूं और इसे ASP.NET के संदर्भ में सभी बुराई की जड़ के रूप में देखता हूं। यही कारण है कि मैं अभी इसका उपयोग नहीं करता हूं और आप पूरी तरह से ईमानदार क्यों होंगे?

मैंने मूल रूप से ASP.NET MVC फ्रेमवर्क अवधारणा को लिया और इसे अपने तरीके से बनाया। मैंने हालांकि कुछ चीजों को बदल दिया। मैंने अपने नियंत्रक रैपिंग कोड, या डायनामिक पुनर्संयोजन के आसपास URL रूटिंग कोड बनाया।

अब, मैं यह कहना चाहूंगा कि ASP.NET MVC एप्लिकेशन इस आधार पर तेज होंगे कि आप इसका उपयोग कैसे करते हैं। यदि आप पूरी तरह से WebForms को छोड़ देते हैं, तो आप ASP.NET जीवन-चक्र को तेजी से बढ़ा देंगे और ऑब्जेक्ट मॉडल विनम्र होता है।

जब आप लिख रहे हैं तो आप एक सेना को तत्काल भेज रहे हैं ... कोई प्रतीक्षा नहीं, वस्तुओं का एक समूह जो आपके विचार के प्रतिपादन में भाग लेंगे। यदि आप जहाँ ASPX पृष्ठ में ही व्यवहार की न्यूनतम मात्रा को व्यक्त करना चाहते हैं, तो यह धीमा होने वाला है। (मुझे दृश्य मतिहीनता की परवाह नहीं है क्योंकि Visual Studio में ASPX पृष्ठों का समर्थन सभ्य है, लेकिन मैंने पूरी तरह से WebForms को एक अवधारणा के रूप में गिरा दिया है और मूल रूप से कोड ब्लोट के कारण या इसे बदलने में सक्षम नहीं होने के कारण किसी भी ASP.NET फ्रेमवर्क। चीजें हैं जो मेरे आवेदन तार)।

मैंने जब भी जरूरत हो विशेष उद्देश्य वस्तुओं और कोड को छोड़ने के लिए गतिशील पुनर्संयोजन (System.Reflection.Emit) पर भरोसा करने के तरीके पाए हैं। इस कोड का क्रियान्वयन प्रतिबिंब की तुलना में तेज है, लेकिन शुरू में प्रतिबिंब सेवा के माध्यम से बनाया गया है। इसने मेरे एमवीसी फ्लेवर्ड फ्रेमवर्क को शानदार प्रदर्शन दिया है लेकिन बहुत ही स्टेटिक रूप से टाइप किया गया है। मैं तार और नाम / मूल्य जोड़ी संग्रह का उपयोग नहीं करता। इसके बजाय मेरी कस्टम कंपाइलर सेवाएँ एक रेफ़रेंटर में एक फार्म पोस्ट को एक रेफेरेंस एक्शन के रूप में एक संदर्भ प्रकार से गुजरती हैं। दृश्य के पीछे बहुत सारी चीजें चल रही हैं लेकिन यह कोड तेज है, वेबफार्म या एमवीसी फ्रेमवर्क की तुलना में बहुत तेज है।

इसके अलावा, मैं URL नहीं लिखता, मैं लैम्ब्डा एक्सप्रेशन लिखता हूं जो URLs में ट्रांसलेट किए जाते हैं जो बाद में बताते हैं कि कौन सी कंट्रोलर एक्शन लागू करनी है। यह विशेष रूप से तेज़ नहीं है, लेकिन इसमें टूटे हुए URL हैं। यह वैसा ही है जैसे कि आपके पास वैधानिक रूप से टाइप किए गए संसाधन और साथ ही स्टेटिक टाइप की गई वस्तुएं हों। एक वैधानिक रूप से टाइप किया गया वेब अनुप्रयोग? वह जो मैं चाहता हूँ!

मैं अधिक लोगों को इसे आज़माने के लिए प्रोत्साहित करूंगा।

Comments

तो यह सवाल का सीधा जवाब नहीं है? यह हालांकि संबंधित है, और यह कुछ अच्छे बिंदु बनाता है। लेकिन हे, यह कुछ मैं अपनी जरूरतों के लिए बनाया गया है, और यह मुझे पूरी तरह से ठीक है। मुझे अपने विचारों को साझा करने में भी मज़ा आता है, भले ही बहुत कम लोग समझें कि क्यों।

— जॉन लीडग्रेन

ठीक है, आपको अपना वोट नहीं बदलना है, लेकिन आपको इस पर वोट डालने की जरूरत नहीं है, क्योंकि यह 'जवाब' नहीं है। यदि आप पाठ में कुछ समय लेते हैं, तो ऐसी कई चीजें हैं जो ASP.NET MVC को WebForms से तेज़ होने का संकेत देती हैं और ऐसा क्यों है। और यह प्रतिबिंब और ऑब्जेक्ट मॉडल और WebForms के ViewState ओवरहेड जैसी चीजों को उबालता है।

— जॉन लेडिग्रेन 10

@ जॉन - अब जब एमवीसी 2 बेहतर मॉडल बाइंडिंग, वेलिडेशन, दृढ़ता से टाइप किए गए हेल्पर्स इत्यादि के साथ बाहर है, तो आप अपने तरीके की तुलना में इसका मूल्यांकन कैसे करेंगे?

— तवानफोसन

एमवीसी 2 बहुत बेहतर है, मेरा मानना ​​है कि यह उस समय बहुत बदल गया है जो मैं उस समय बना रहा था (बीटा में एमवीसी 1 के साथ)। मैं मौजूदा टूलींग से बाहर निकले बिना ASP.NET के शीर्ष पर बनाने के लिए जो कुछ भी करने की कोशिश कर रहा था, उसके संबंध में समस्याओं का सामना करना पड़ा। कहने के लिए पर्याप्त है, मैंने बहुत कुछ सीखा और अंततः इसे उत्पादन में लाया। मुझे अब एहसास हुआ कि वर्तमान टूलींग / ढांचा (VS / ASP.NET / C #) वास्तव में इस सामान के लिए उपयुक्त नहीं है और अंततः यदि आप इस सड़क से नीचे जाना चाहते हैं, तो आपको अपने स्वयं के कंपाइलर / मॉडल-जाँच में निवेश करने की आवश्यकता होगी अपने पक्ष में काम करने के लिए कुछ चीजों के लिए सामान।

— जॉन लीडग्रेन

मैंने उस समय ASP.NET MVC के बारे में ज्यादा नहीं सोचा। इसमें उन चीजों की कमी थी जो मैं जानता था कि मैं चाहता था। लेकिन, मुझे इन चीजों को विकसित करने, परीक्षण करने और लगाने में काफी समय देना पड़ा। मुझे अभी भी लगता है कि मैं जिस वेब फ्रेमवर्क का स्थैतिक पहलू बना रहा था, उस संबंध में MVC से बेहतर है लेकिन उस समस्या को हल करने के लिए C # कंपाइलर अक्षम है। आपको कुछ भाषा / संकलक की आवश्यकता होती है जो मेटा प्रोग्रामिंग के लिए अधिक लचीलेपन की अनुमति देता है। मुझे उस समय बहुत कुछ करना था और अक्सर संकलित उदाहरणों को कैश करना असंभव था, इसलिए मुझे चीजों को गतिशील रूप से पुन: व्यवस्थित करना पड़ा।

— जॉन लीडग्रेन ने

Answer 12

दृश्य स्टूडियो के साथ बनाई गई परियोजनाएं। एक है mvc4 टेम्प्लेट, दूसरा है WebForm (ट्रैंडिशियल)। और जब WCAT के साथ लोड टेस्ट करें, तो यह परिणाम है,

MVC4 WebForms, किसी भी विचार से काफी धीमा है?

MVC4

• के बारे में 11 rps मिल सकता है
• rps 2-cpu या 4-cpu सर्वर दोनों के लिए काफी कम है

WebForms (aspx)

• 2500 आरपीएस से ऊपर हो सकता है

• प्रदर्शन हत्यारा पाया गया है कि यह एमवीसी बाटा या आरसी का बग है। एक बार जब मैं बंडल चीजों को हटा दूंगा तो प्रदर्शन बेहतर होगा। अब नवीनतम संस्करण ने इसे तय किया।

Answer 13

प्रदर्शन इस बात पर निर्भर करता है कि आप क्या कर रहे हैं ... आमतौर पर MVC, asp.net की तुलना में अधिक तेज़ है क्योंकि Viewstate अनुपस्थित है और क्योंकि MVC डिफ़ॉल्ट रूप से पोस्टबैक से कॉलबैक के साथ अधिक काम करता है।

यदि आप अपने वेबफ़ॉर्म पेज को ऑप्टिमाइज़ करते हैं तो आपके पास MVC के समान प्रदर्शन हो सकता है लेकिन यह बहुत काम आएगा।

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

वेबसाइट का प्रदर्शन आपके आर्किटेक्चर पर बहुत निर्भर करता है। चिंता के अच्छे पृथक्करण के साथ एक स्वच्छ आप एक अधिक स्वच्छ कोड और प्रदर्शन को बेहतर बनाने का एक बेहतर विचार लाएंगे।

आप इस टेम्पलेट " नियोस-एसडीआई एमवीसी टेम्पलेट " पर एक नज़र डाल सकते हैं जो डिफ़ॉल्ट रूप से बहुत सारे प्रदर्शन सुधारों के साथ एक स्वच्छ वास्तुकला का निर्माण करेगा (चेक MvcTemplate वेबसाइट की जाँच करें)।

Answer 14

मैंने कुछ बुनियादी कोड के साथ एक छोटा VSTS लोड परीक्षण प्रयोग किया और ASP.NET MVC प्रतिक्रिया समय को ASP.NET वेबफॉर्म की तुलना में दोगुना तेज पाया। ऊपर प्लॉट के साथ संलग्न ग्राफ है।

आप इस CP आलेख के विवरणों में इस लोड परीक्षण प्रयोग को https://www.codeproject.com/Articles/864950/ASP-NET-MVC-vs-ASP-NET-WebForm-performance-compari पर पढ़ सकते हैं

परीक्षण VSTS और टेलिक लोड लोड सॉफ्टवेयर का उपयोग करके नीचे दिए गए विनिर्देशों के साथ आयोजित किया गया था: -

उपयोगकर्ता 25 उपयोगकर्ताओं को लोड करता है।

परीक्षण की रन अवधि 10 मिनट थी।

मशीन विन्यास डेल 8 जीबी राम, कोर i3

प्रोजेक्ट को IIS 8 में होस्ट किया गया था।

एमवीसी 5 का उपयोग करके परियोजना बनाई गई थी।

नेटवर्क लैन कनेक्शन ग्रहण किया गया था। इसलिए यह परीक्षण अभी के लिए नेटवर्क अंतराल के लिए जिम्मेदार नहीं है।

परीक्षण में ब्राउज़र क्रोम और इंटरनेट एक्सप्लोरर का चयन करता है।

एकाधिक पढ़ने जहां अज्ञात घटनाओं को औसत करने के लिए परीक्षण के दौरान लिया गया। 7 रीडिंग जहां ली गई हैं और सभी रीडिंग इस लेख में 1, 2 और इतने पर पढ़ने के रूप में प्रकाशित की गई हैं।

Comments

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

— रिचर्ड हाउर

एक बुरी तकनीक में भी एक ठीक से और सावधानी से बनाया गया अनुप्रयोग चमत्कार काम करेगा। ASP.NET पृष्ठ का जीवन चक्र निश्चित रूप से अधिक पेलोड के रूप में रूटिंग और देखने के निष्पादन की तुलना में है क्योंकि यह HTML यूआई पीढ़ी के साथ काम करता है। रूटिंग ASP.NET फ्रेमवर्क का एक हिस्सा है, इसलिए सामान्य वेबफॉर्म में भी वे मौजूद हैं। एक बात मैं सहमत हूं कि यदि आप अपने प्रदर्शन के पीछे कोड नहीं लिखते हैं तो यह एमवीसी के बराबर होगा। लेकिन वेबफॉर्म टूलबॉक्स इतना लुभावना है कि पीछे का कोड इसका एक अभिन्न हिस्सा बन जाता है। जबकि एमवीसी मुझे ऐसा करने की अनुमति नहीं देता है। मुझे पसंद है कि कैसे रेजर में उन्होंने डिजाइन दृश्य और कोड को पीछे छोड़ दिया है।

— शिवप्रसाद कोईराला