يعرف أي شخص كتب ASP أكبر قليلاً أن كائن الجلسة سهل الاستخدام حقًا ويمكن استخدامه لتسجيل متغيرات البيانات الخاصة للمستخدم، وهو آمن ومريح. ولكن هل تعرف حقًا كيف تعمل الجلسة؟ يعرف أي شخص كتب ASP أكبر قليلاً أن كائن الجلسة سهل الاستخدام حقًا ويمكن استخدامه لتسجيل متغيرات البيانات الخاصة للمستخدم، وهو آمن ومريح. ولكن هل تعرف حقًا كيف تعمل الجلسة؟ ربما بعد فهم ذلك، لن تجرؤ بعد الآن على استخدام هذا الشيء المحبوب والمكروه. على الرغم من أن الطريقة البديلة مزعجة بعض الشيء، إلا أنه لا بد من تنفيذها بعد دراسة طويلة الأمد.
أولاً، لنتحدث عن فوائد الجلسة: يمكن استخدامها لتسجيل متغيرات البيانات الخاصة بالعميل ولن تختفي خلال النطاق الزمني. هذه وظيفة مهمة حقًا، خاصة بالنسبة للأنظمة التي تحتوي على أعضاء والتي يجب استخدامها. مثل حساب تسجيل الدخول الخاص بالعضو والوقت والحالة والعديد من البيانات في الوقت الفعلي التي يجب تسجيلها (مثل نظام التسوق الذي يسجل العناصر الموجودة في سلة التسوق الخاصة بالمستخدم، هذه المعلومات مطلوبة بشكل خاص من قبل كل مستخدم وعادة ما يستخدمها المطورون). معالجة سجل الجلسة.
ومع ذلك، تتكون الجلسة في ASP من ملفات تعريف الارتباط، ويقوم الخادم بنقل جميع البيانات المسجلة في الجلسة إلى متصفح المستخدم في شكل ملفات تعريف الارتباط. عادةً ما تقوم المتصفحات العامة بتخزين ملفات تعريف الارتباط هذه، وعندما ينقر المستخدم على رابط ويتصل بالخادم مرة أخرى، سيرسل المتصفح ملفات تعريف الارتباط هذه مرة أخرى إلى الخادم للمعالجة. هذا هو مبدأ تشغيل الجلسة. عندما تكون كمية البيانات أكبر، نظرًا لأنه يجب إرسالها واستعادتها، فإنها لا تستهلك عرض النطاق الترددي للخط فحسب، بل تقلل أيضًا من الأداء لأن الخادم يجب أن ينفق المزيد من الموارد على المعالجة وإعادة التكوين عبر الإنترنت. الذاكرة. ربما تفكر الآن، "لا بد لي من استخدام هذه الوظيفة، لذلك يجب أن أضحي بها." ومع ذلك، فإن هذه المقالة تتحدث عن Session هناك بدائل والشيء التالي الذي يأتي هو أنه ينتمي أيضًا إلى كائن التطبيق Global.asa.
التطبيق جيد أيضًا في تسجيل ومعالجة البيانات المؤقتة، وإمكانياته واستخدامه هي نفس الجلسة من جميع النواحي، ولكن بالمقارنة، فإن البيانات التي يسجلها تكون عامة، أي مساحة متغيرة يمكن مشاركتها من قبل أي مستخدم. على عكس الجلسة، لا ينقل التطبيق البيانات إلى المستخدم وينتظر الاتصال التالي لقراءتها مرة أخرى، ويتم تسجيلها مباشرة في الذاكرة على الخادم، وبالمقارنة، فإن الأداء أسرع بكثير من الجلسة.
نظرًا لأن كائن التطبيق عام، فإن أول ما يجب فعله هو تخطيط منطقة مشتركة لكل مستخدم، بحيث يمكن لكل مستخدم أن يكون له منطقته الخاصة لتسجيل البيانات، وذلك لتحقيق غرض محاكاة الجلسة. هناك نهجان الآن:
1. تهيئة مساحة ذاكرة المستخدم وإنشائها وتخصيصها مسبقًا عند تنشيط الخادم عادةً، على الرغم من أن هذا الأسلوب يشغل الكثير من الموارد بمجرد بدء تشغيل الخادم، إلا أنه يوفر أيضًا مشكلة الاضطرار إلى تخصيصها في كل مرة يقوم فيها المستخدم. متواجد حاليا في المستقبل. ولكن هناك قيود يجب أن تحدد هذه الطريقة الحد الأقصى لعدد الأشخاص، نظرًا لأنه يتم تهيئتها بمجرد تنشيطها، يمكننا فقط تقدير إنشاء مقدار معين من مساحة الذاكرة، لذلك تُستخدم هذه الطريقة عادةً في البرامج الصغيرة. مثل غرف الدردشة
2. يجب اعتبار هذه الطريقة أكثر ملاءمة للتطبيقات واسعة النطاق، فهي تعتمد طريقة تخصيص ديناميكية وتبدأ في تخصيص الموارد للمستخدم عندما يتصل المستخدم بالخادم لأول مرة. الغرض من هاتين الطريقتين لمحاكاة الجلسة هو تقليل استهلاك موارد الجلسة، ولكن بعد كل شيء، لا يمكن استبدالها بالكامل، ما زلنا بحاجة إلى استخدام القليل من الجلسة، والتي على الأقل يمكن أن تقلل الكثير من العبء على الخادم.
الخيار الأول
نبدأ أولاً في تنفيذ الحل الأول بما أنه تتم تهيئة التطبيق أثناء التنشيط، بالطبع علينا أن نبدأ من Global.asa:
تم الانتهاء من التهيئة، ولكن كيفية استخدامها؟ نحتاج فقط إلى تغيير البيانات المخزنة في الأصل باستخدام الجلسة، مثل رقم الحساب ووقت تسجيل الدخول، إلى كائن التطبيق الذي أنشأناه حيث يقوم المستخدم بتسجيل الدخول:
انسخ رمز الكود كما يلي:
"ابحث عن المساحة غير المستخدمة."
لأني = 1 إلى التطبيق (ClientMax)
إذا كان التطبيق (User_Status_ & i) = 0 إذن
'الرقم المؤقت للمستخدم
الجلسة (الفهرس) = i
"قفل."
تطبيق التطبيق.قفل
'اضبط على الحالة المستخدمة
التطبيق (User_Status_ & i) = 1 'ضع بيانات متغيرة
التطبيق (User_Account_ & i) = الحساب
التطبيق (User_Logtime_ & i) = الآن ()
'فتح
التطبيق.فتح
الخروج ل
نهاية إذا
التالي
للحصول على بيانات متغيرة متعلقة بالمستخدم، قم بما يلي:
الاستجابة.الكتابة (التطبيق (حساب_المستخدم_ والجلسة (الفهرس))
قد تجد أنه ليس يقال عدم استخدام الجلسة؟ إذن لماذا لا تزال الجلسة موجودة في كود المصدر أعلاه؟ كما ذكرنا من قبل، لا يمكن لهذا البديل أن يحل محل الجلسة بشكل كامل، حيث لا يكون المتصفح متصلاً دائمًا بالخادم، وسيتم قطع الاتصال به بعد قراءة الصفحة، فكيف نعرف أن نفس الشخص متصل في المرة القادمة؟ في هذا الوقت، يجب أن نعتمد على Session. نعطي المستخدم مجموعة من الأرقام في الوقت الفعلي. هذا الرقم هو عدد المساحة المتغيرة للمستخدم على التطبيق. يمكنك أن تتخيل أن هناك العديد من الخزائن الموجودة في البنك مفتاح، والمفتاح يوجد عليه رقم، والرقم الموجود على المفتاح يسمح للموظف بإرشادك إلى خزنتك الخاصة. لا تزال هناك تحسينات على هذه الطريقة، ولكنها كافية للتطبيقات الصغيرة.
الخيار الثاني
فيما يتعلق بالحل السابق، قد تعتقد أيضًا أن أرقامنا المخصصة يتم تسجيلها باستخدام الجلسة. عند الحديث عن الأرقام، يوفر كائن الجلسة طريقة "SessionID". هذا صحيح، بغض النظر عما إذا كنا نريد استخدامه أم لا، سيقوم الخادم تلقائيًا بتعيين رقم لكل مستخدم، ولن يتكرر هذا الرقم، أما هذا الرقم، فسيتم الحصول عليه باستخدام Session.SessionID. هذا الترقيم هو الإجراء الذي ستفعله الجلسة بالتأكيد، يمكننا استخدامه لاستبدال برنامج الترقيم الذي كتبناه بأنفسنا، والذي يوفر أيضًا الكثير من الجهد ويوفر قابلية أكبر للتوسع. لكن في الأساس، لا يزال الحل الأول أعلاه له استخداماته، مثل التطبيقات الصغيرة مثل غرف الدردشة التي تحد من عدد الأشخاص. والبديل التالي هو الأنظمة الأكبر حجمًا.
بالنسبة لمواقع الويب التي تضم مئات أو آلاف أو حتى عشرات الآلاف من الزوار في الثانية، فمن المؤكد أن الحل السابق لن ينجح. لنفترض أنك قمت بتعيين الحد الأعلى لعدد الأشخاص على 10000. بمجرد التنشيط، سيساعدك الخادم على قطع 10000 منطقة لـ 10000 مستخدم. إذا كان هناك 5 متغيرات في منطقة ما، ويشغل متغير واحد 32 بايت، فإن 10000 تشغل المزيد. أكثر من 320000 كيلو (320 ميجابايت)، خادم بمجرد تفعيلها، يتم حشو الكثير من القمامة في الذاكرة، ولا بد أن ينخفض الأداء كثيرًا قبل دخولها إلى ساحة المعركة، ولا تنظر إلى هذه الأرقام الصغيرة، وتعتقد أن 512 ميجابايت لديك ستكون كذلك الأرقام المذكورة أعلاه تفترض الحد الأدنى من العدد، بالإضافة إلى أنه من غير المعروف عدد الموارد الإضافية التي سيستخدمها الخادم عند تكوين الذاكرة، لذلك سيكون فقط أكثر وليس أقل. لذلك، الحل الوحيد هو تكوين مساحة متغير المستخدم ديناميكيًا، وقطع المنطقة فقط عندما يكون المستخدم متصلاً بالخادم. وبهذه الطريقة، ليست هناك حاجة لتكوين ذاكرة ضخمة مسبقًا.
الخيار الثاني سهل التنفيذ نسبيًا، يرجى التخلص من كل شيء في الخيار الأول. لا نحتاج إلى لمس Global.asa، نحتاج فقط إلى تغيير مكان تسجيل دخول المستخدم والأماكن المفيدة الأخرى:
انسخ رمز الكود كما يلي:
'LockApplicationApplication.Lock' ضع البيانات المتغيرة
التطبيق (User_Account_ & Session.SessionID) = الحساب
Application(User_Logtime_ & Session.SessionID) = Now() 'فتح التطبيق.Unlock
للحصول على بيانات متغيرة متعلقة بالمستخدم، قم بما يلي:
انسخ رمز الكود كما يلي:
Response.Write(Application(User_Account_ & Session.SessionID))
في الماضي، قرأت العديد من الكتب التي تقول إن الجلسات تتطلب الكثير من الموارد، لذا حاول عدم استخدامها، ولكن لا يزال يتعين عليك استخدامها عندما يتعين عليك ذلك، ولم تعلم الكتب أي حلول أكثر ملاءمة. الآن بعد أن فهمت كيفية استبدال الجلسة، استفد منها! ربما يمكن تحسين مشكلات الأداء التي أزعجتني دائمًا كثيرًا!