सत्र चर

Question

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

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

Answer 1

यह ऐसा आवेदन विशेष है, क्योंकि जवाब देने के लिए बहुत मुश्किल है, लेकिन यहाँ कुछ दिशा निर्देश मैं उपयोग कर रहे हैं:

1. सत्र में यथासंभव कम रखो।
2. उपयोगकर्ता-विशिष्ट चयन जो केवल किसी दिए गए विज़िट के दौरान ही रहें, एक अच्छी पसंद
3. अक्सर, वेरिएबल जिन्हें आपकी साइट पर उपयोगकर्ता की यात्रा के दौरान कई पृष्ठों तक पहुंचने की आवश्यकता होती है (पृष्ठ से पृष्ठ पर उन्हें सहेजने से बचने के लिए) सत्र में रखना भी अच्छा है।

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

Answer 2

DO NOT put UI objects in session.

कि परे, मैं कहना चाहता हूँ यह बदलता रहता है। सत्र में बहुत अधिक आपको धीमा कर सकता है यदि आप प्रक्रिया सत्र में उपयोग नहीं कर रहे हैं क्योंकि आप प्रदाता की गति + बहुत सी धारावाहिक होने जा रहे हैं। कैश और सत्र का उपयोग कम और सावधानीपूर्वक किया जाना चाहिए। सत्र में न डालें क्योंकि आप सुविधाजनक या सुविधाजनक हो सकते हैं। बैठ जाओ और विश्लेषण करें कि क्या यह समझ में आता है।

Answer 3

सत्र में डेटाबेस कनेक्शन जानकारी डालें।

जहां तक ​​कैशिंग है, मैं संभवतः कैशिंग के लिए सत्र का उपयोग करने से बचूंगा - आप उन मुद्दों पर चले जाएंगे जहां कोई उपयोगकर्ता डेटा का उपयोग कर रहा है, और आप उपयोगकर्ताओं के बीच कैश किए गए डेटा को साझा नहीं कर सकते । एएसपी.नेट कैश, या कुछ अन्य कैशिंग उपयोगिता (जैसे मेमकैच या वेग) का प्रयोग करें।

जहाँ तक क्या सत्र, कुछ भी पर लागू होने वाला सब ब्राउज़र विंडो एक उपयोगकर्ता खुला है अपनी साइट (प्रवेश, सुरक्षा सेटिंग्स, आदि) के लिए में जाना चाहिए के रूप में सत्र में होना चाहिए। चीजों को किस वस्तु को देखा/संपादित किया जा रहा है, वास्तव में स्क्रीन के बीच पारित/POST चर होना चाहिए ताकि उपयोगकर्ता आपके एप्लिकेशन के साथ काम करने के लिए एकाधिक ब्राउज़र विंडो का उपयोग कर सके (जब तक कि आप इसे रोकना नहीं चाहते)।

Answer 4

ए very similar question पहले PHP सत्रों के बारे में पूछा गया था। असल में, सत्र उपयोगकर्ता-विशिष्ट डेटा को स्टोर करने के लिए एक बेहतरीन जगह है जिसे आपको कई पेज लोड तक पहुंचने की आवश्यकता होती है। डेटाबेस कनेक्शन संदर्भों को संग्रहीत करने के लिए सत्र एक महान स्थान नहीं हैं; आप कुछ प्रकार के कनेक्शन पूलिंग सॉफ़्टवेयर का उपयोग करना बेहतर होगा या प्रत्येक पृष्ठ लोड पर अपना कनेक्शन खोलें/बंद करें।सत्र में डेटा कैशिंग करने तक, यह इस बात पर निर्भर करता है कि सत्र डेटा कैसे संग्रहीत किया जा रहा है, आपको कितनी सुरक्षा चाहिए, और उपयोगकर्ता के लिए डेटा विशिष्ट है या नहीं। कैशिंग डेटा के लिए कुछ और उपयोग करना बेहतर शर्त होगी।

Answer 5

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

Answer 6

ए: डेटा जो केवल सापेक्ष है एक उपयोगकर्ता आईई: एक उपयोगकर्ता नाम, एक उपयोगकर्ता आईडी। पर उपयोगकर्ता का प्रतिनिधित्व करने वाला एक ऑब्जेक्ट। कभी-कभी यूआरएल-रिश्तेदार डेटा (जैसे किसी को लेना है) या एक त्रुटि संदेश स्टैक सत्र में धक्का देने के लिए उपयोगी होता है।

यदि आप विभिन्न उपयोगकर्ताओं के बीच संभावित रूप से सामान साझा करना चाहते हैं, तो एप्लिकेशन स्टोर या कैश का उपयोग करें। वे बहुत बेहतर हैं।

Answer 7

स्टीफन,
क्या आप "आई" से शुरू होने वाली कंपनी के लिए काम करते हैं, जिसकी वेबसाइट "बीसी" से शुरू होती है? यह बिल्कुल वैसा ही लगता है जब मैंने पहली बार .NET में विकास करना शुरू किया था (और युवा और बेवकूफ था) - मैंने सत्र और एप्लिकेशन में जो कुछ भी सोचा था, मैंने उसे क्रैक किया। कहने की जरूरत नहीं है, वह डबल प्लस असहज था।
सामान्य रूप से, जितना संभव हो सके सत्र को छोड़ दें। निश्चित रूप से, गैर-धारावाहिक वस्तुओं को वहां संग्रहित नहीं किया जाना चाहिए (डेटाबेस कनेक्शन और ऐसे), लेकिन यहां तक ​​कि बड़ी, serializable वस्तुओं या तो नहीं होना चाहिए। आप सिर्फ ओवरहेड नहीं चाहते हैं।

Answer 8

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

हालांकि यह बहुत खराब है, छुपे हुए क्षेत्रों के माध्यम से स्वचालित रूप से राज्य के प्रबंधन के एएसपी.NET मॉडल को वास्तव में सत्र चर में कुछ भी रखने की आवश्यकता को समाप्त करना चाहिए।

अंगूठे का मेरा नियम यह है कि ऐप को जितना अधिक स्केलेबल (उपयोगकर्ताओं/हिट के मामले में) होना चाहिए, उतना कम आप सत्र स्थिति का उपयोग कर सकते हैं। हालांकि, एक व्यापार बंद है। वेब अनुप्रयोगों के लिए जहां उपयोगकर्ता बार-बार उसी डेटा तक पहुंच रहा है और आमतौर पर साइट के प्रति उपयोग के लिए काफी लंबा सत्र होता है, कुछ कैशिंग (सत्र ऑब्जेक्ट्स में आवश्यक होने पर) वास्तव में डीबी सर्वर पर लोड को कम करके स्केलेबिलिटी में मदद कर सकता है। यहां विचार यह है कि बैक एंड डीबी की तुलना में प्रस्तुति परत को खेत करने के लिए यह बहुत सस्ता और कम जटिल है। बेशक, सभी चीजों के साथ, इस सलाह को संयम में लिया जाना चाहिए और सभी परिस्थितियों में लागू नहीं होता है, लेकिन काफी सरल घर के सीआरयूडी ऐप के लिए, यह आपको अच्छी तरह से सेवा देना चाहिए।

Answer 9

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