2012-02-24 18 views
7

मेरे पास यह देखने के लिए एक परिदृश्य है कि मेरा वेब ऐप सत्र में डेटा संग्रहीत कर रहा है और इसे पुनर्प्राप्त कर रहा है। मुझे यह इंगित करना चाहिए कि मैं अपने सत्र स्टोर के रूप में SQL सर्वर का उपयोग कर रहा हूं।एएसपी.नेट सत्र - बड़ी वस्तु बनाम बड़ी वस्तुएं

मेरा परिदृश्य मुझे बाद के उपयोग के लिए उपयोगकर्ता के सत्र में स्ट्रिंग मानों के लिए मैप किए गए अद्वितीय आईडी की एक सूची स्टोर करने की आवश्यकता है। वर्तमान कोड जो मैंने विरासत में प्राप्त किया है, एक कस्टम ऑब्जेक्ट के साथ List<T> का उपयोग कर रहा है लेकिन मैं पहले से ही किसी प्रकार का शब्दकोश प्रदर्शन के लिए कहीं बेहतर दिख सकता हूं।

मैं विकल्पों के लिए दो विचारों परीक्षण किया है:

  1. सत्र में एक Dictionary<int, string> भंडारण। जब मुझे तार वापस पाने की आवश्यकता होती है, तो मुझे एक बार सत्र से शब्दकोश मिलता है और शब्दकोश वस्तु पर प्रत्येक आईडी का परीक्षण कर सकता है।

  2. चूंकि सत्र मूल रूप से एक शब्दकोश की तरह है, इसलिए एक अद्वितीय सत्र कुंजी का उपयोग कर सीधे सत्र में स्ट्रिंग को संग्रहीत करें। Session["MyString_<id>"] = stringValue"। सत्र से मूल्य प्राप्त करना मूल रूप से व्यस्त ऑपरेशन होगा। 4552 बाइट्स, 0.1071 सेकंड आपरेशन करने के लिए

  3. सत्र प्रत्यक्ष - - 4441 बाइट्स

    • शब्दकोश:

मेरे परीक्षण के परिणाम आपरेशन मुझे क्या करना है और 100 से तार का उपयोग कर की जरूरत के आधार पर निम्न शो , ऑपरेशन करने के लिए 0.0845 सेकेंड

इन परिणामों से मैं देखता हूं कि मैं सत्र में कुछ जगह बचाता हूं (शायद क्योंकि मुझे एक शब्दकोश obj serialising का ओवरहेड नहीं मिला है ect) और सत्रों से मूल्यों को वापस प्राप्त करते समय यह तेज़ प्रतीत होता है, हो सकता है क्योंकि स्ट्रिंग ऑब्जेक्ट्स की तुलना में deserialise के लिए तेज़ हैं।

तो मेरा सवाल यह है कि क्या प्रदर्शन के लिए प्रदर्शन में बेहतर है कि सत्र में कई छोटी वस्तुओं को एक बड़े से ज्यादा स्टोर किया जाए? क्या बहुत छोटी वस्तुओं को बनाकर कुछ नुकसान हो रहा है, जो एक बड़ी वस्तु है जिसे मैंने नहीं देखा है?

+0

आपको – Jonathan

उत्तर

1

बड़ी वस्तुओं को क्रमबद्ध करने और खोजने के लिए दंड हैं (वे अधिक जटिल संरचना का प्रतिनिधित्व करने की आवश्यकता के कारण अधिक जगह और प्रोसेसर समय लेते हैं)।

और 2 खोज क्यों करते हैं जब आप केवल एक ही कर सकते हैं।

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

+0

से प्यार किया गया है क्या आपके पास इस दस्तावेज़ के लिए एक लिंक उपलब्ध है? मुझे इसे पढ़ने में दिलचस्पी होगी –

0

मुझे लगता है कि आपने यह दिखाने में लगभग अपने प्रश्न का उत्तर दिया है कि हां, वस्तुओं को deserializing के साथ एक उपर है लेकिन मुझे लगता है कि वास्तविक कारण प्रबंधन और रखरखाव में से एक होना चाहिए।

जब आप 100 ऑब्जेक्ट्स के बारे में बात कर रहे हैं तो स्टोरेज अंतर का आकार न्यूनतम होगा, लेकिन जब आप इसे 1000 ऑब्जेक्ट तक स्केल करते हैं तो अंतर भी बढ़ेगा, खासकर यदि आप जटिल कस्टम ऑब्जेक्ट्स का उपयोग कर रहे हैं। यदि आपके पास एक ऐसा एप्लिकेशन है जिसमें 1000 से अधिक सत्रों का उपयोग करने वाले कई उपयोगकर्ता हैं तो आप कल्पना कर सकते हैं कि यह केवल स्केलेबल नहीं है।

इसके अलावा, कई सत्र ऑब्जेक्ट्स होने पर आपको निस्संदेह प्रत्येक अलग-अलग ऑब्जेक्ट को संभालने के लिए और कोड लिखना होगा।यह एक विशाल राशि नहीं हो सकती है, लेकिन निश्चित रूप से अधिक है। इससे संभावित रूप से तर्कसंगत समझने के लिए आपके कोड को चुनने वाले डेवलपर के लिए और अधिक कठिन बना दिया जाएगा और इसलिए अपना कोड बढ़ाएं।

यदि आप एक बेयरबोन प्रारूप में सत्र को संभाल सकते हैं जैसे कि आईन्यूमेरेबल या आईडीर्नी, तो मेरी राय में यह मामूली ओवरहेड शामिल होने पर भी बेहतर है।

+0

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

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