هل من المقبول استخدام المتغيرات الثابتة لتخزين المعلومات مؤقتًا في ASP.net؟

Question

أعمل حاليًا على تطبيق مسؤول المشروع في C# 3.5 على ASP.net.من أجل تقليل الزيارات إلى قاعدة البيانات، أقوم بتخزين الكثير من المعلومات مؤقتًا باستخدام المتغيرات الثابتة.على سبيل المثال، يتم الاحتفاظ بقائمة المستخدمين في الذاكرة في فئة ثابتة.يقرأ الفصل جميع المعلومات من قاعدة البيانات عند بدء التشغيل، وسيقوم بتحديث قاعدة البيانات كلما تم إجراء تغييرات، لكنه لا يحتاج أبدًا إلى القراءة من قاعدة البيانات.

يقوم الفصل بإجراء اختبار ping على خوادم الويب الأخرى (إذا كانت موجودة) بمعلومات محدثة في نفس وقت الكتابة إلى قاعدة البيانات.آلية اختبار الاتصال هي إحدى خدمات Windows التي يتم تسجيل كائن ذاكرة التخزين المؤقت لها باستخدام منفذ عشوائي متاح.يتم استخدامه لأشياء أخرى كذلك.

كمية البيانات ليست كبيرة جدًا.في الوقت الحالي، أستخدمه فقط للتخزين المؤقت للمستخدمين (تجزئة كلمة المرور، والأذونات، والاسم، والبريد الإلكتروني، وما إلى ذلك) فهو يحفظ فقط كومة من المكالمات التي يتم إجراؤها إلى قاعدة البيانات.

كنت أتساءل عما إذا كانت هناك أي عيوب في هذه الطريقة و/أو إذا كانت هناك طرق أفضل لتخزين البيانات مؤقتًا؟

Answer 1

مأزق:يتم تحديد نطاق الحقل الثابت لكل مجال تطبيق، وسيؤدي التحميل المتزايد إلى قيام الخادم بإنشاء المزيد من مجالات التطبيق في التجمع.هذه ليست مشكلة بالضرورة إذا قرأت فقط من الإحصائيات، ولكنك ستحصل على بيانات مكررة في الذاكرة، وستحصل على نتيجة في كل مرة يتم فيها إنشاء مجال التطبيق أو إعادة تدويره.

من الأفضل استخدام كائن ذاكرة التخزين المؤقت - فهو مخصص لأشياء مثل هذه.

يحرر:تبين أنني كنت مخطئًا بشأن AppDomains (كما هو موضح في التعليقات) - المزيد من الأمثلة على طلب سيتم إنشاؤها تحت التحميل، ولكن سيتم تشغيلها جميعًا في نفس AppDomain.(ولكن لا يزال يتعين عليك استخدام كائن ذاكرة التخزين المؤقت!)

Answer 2

طالما يمكنك أن تتوقع أن ذاكرة التخزين المؤقت لن تنمو أبدًا إلى حجم أكبر من حجم الذاكرة المتوفرة، فلا بأس.تأكد أيضًا من أنه سيكون هناك مثيل واحد فقط لهذا التطبيق لكل قاعدة بيانات، وإلا فإن ذاكرات التخزين المؤقت في المثيلات المختلفة للتطبيق قد "تخرج عن المزامنة".

في المكان الذي أعمل فيه، لدينا O/RM محليًا، ونقوم بشيء مشابه لما تفعله مع جداول معينة لا يُتوقع أن تنمو أو تتغير كثيرًا.لذا، فإن ما تفعلونه ليس أمرًا غير مسبوق، وفي الواقع، في نظامنا، هو مجرب وصحيح.

Answer 3

المأزق الآخر الذي يجب عليك مراعاته هو سلامة الخيط.يتم تشغيل كافة طلبات التطبيق الخاصة بك في نفس AppDomain ولكن قد تأتي في سلاسل رسائل مختلفة.يجب أن يؤدي الوصول إلى متغير ثابت إلى حساب إمكانية الوصول إليه من عدة سلاسل رسائل.ربما أكثر قليلا من النفقات العامة مما كنت تبحث عنه.كائن ذاكرة التخزين المؤقت أفضل لهذا الغرض.

Answer 4

أمم...ستكون الطريقة "الكلاسيكية" هي ذاكرة التخزين المؤقت للتطبيق، ولكن بشرط عدم تحديث المتغيرات الثابتة مطلقًا، أو فهم مشكلات القفل إذا قمت بذلك، وفهم أنها يمكن أن تختفي في أي وقت مع إعادة تشغيل مجال التطبيق، فأنا لا أرى حقًا ضرر في استخدام ثابت.

Answer 5

أقترح عليك البحث عن طرق للحصول على ذاكرة تخزين مؤقت موزعة لتطبيقك.يمكنك إلقاء نظرة على نكاش أو indeXus.Net

السبب وراء اقتراحي لذلك هو أنك قمت بتطبيق طريقتك المخصصة لتحديث المعلومات التي تقوم بتخزينها مؤقتًا.المتغيرات/المراجع الثابتة جيدة ولكنها لا يتم تحديثها/تحديثها (لذلك سيتعين عليك التعامل مع التقادم بنفسك) ويبدو أن لديك إعدادًا موزعًا.