ما هي المعلومات الصحيحة للتخزين المؤقت؟ما هو الوقت المناسب لتحميل الصفحة؟

Question

أنا بصدد تطوير موقع شبكة اجتماعية.

وكنت أفكر في قابلية التوسع منذ اليوم الأول للمشروع، وقمت بضبط الموقع والاستعلامات بأفضل ما أستطيع.

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

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

الاستعلام الأثقل هو الحصول على معلومات الأعضاء، حيث يحصل هذا الاستعلام على جميع معلومات الأعضاء وأي شيء متعلق بهم، كما هو الحال في حالة هذا الموقع، أهدافهم، وإدخالات نوع المدونة، والتشجيعات، والصور، وتحديثات الحالة (مثل تويتر)، ومعلومات المدونة (لنشر إدخالاتهم في منشورات متعددة) ) الخ الخ

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

Answer 1

وكنت تنفيذ التخزين المؤقت في كل طبقة من التطبيق الخاص بك إذا كان ذلك ممكنا.

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

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

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

Answer 2

الجواب النموذجي هو:

• معلومات ذاكرة التخزين المؤقت التي نادرا ما يتم تحديثها.
• لا تقم بتخزين ما يتغير بشكل متكرر.

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

الآن فيما يتعلق بوقت التحميل (والذي يمكن أن يكون مختلفًا جدًا اعتمادًا على موقع المستخدم)، إليك بعض الأرقام المفيدة من منتدى PHP لأحد مواقع الألعاب:

• وقت تحميل JS:0.274
• عدد الاستعلامات:15
• وقت تحميل PHP:0.0524
• استخدام الذاكرة:1.013 ميجابايت

وهذا يعتبره المجتمع تجربة جيدة.لكنها ذاتية بشكل رهيب.

Answer 3

تم طرح سؤال تحميل الصفحة بالفعل:

ما هو وقت الاستجابة المناسب لتطبيق ويب ديناميكي ومخصص؟

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

Answer 4

لبيانات محددة تعريف المستخدم، تخزين أكبر قدر ما تستطيع في FormsAuth تذكرة / كوكي. سيتطلب بنود محددة التخزين المؤقت (HttpContext.Current.Cache) المستخدم الموارد X على الخادم الخاص بك لكل مستخدم، وهو نفس الجلسة من شأنه (ولكن مع أقل من الصداع). إذا كنت تستطيع افراغ قدر الإمكان إلى المستخدمين تذكرة أو الكعكة (في مثل 4K) فإنك سوف تساعد حقا أداء الخوادم في حين رفع.

ويجب عليك فقط أن استرجاع بت من المعلومات التي تحتاج الصفحة. على سبيل المثال، إذا كنت تقوم بتحميل البيانات بلوق، تحميل DONT الصورة ل. في المزيد من العمل، نعم، ولكن إذا كنت ترغب في توسيع نطاق سيكون لديك لتحليل الاحتياجات لكل صفحة.

تأكد من أنك تفهم أن هناك اختلافات بين قاعدة بيانات سؤال التخزين المؤقت (تنفيذ خطة إعادة استخدامها)، كائن التخزين المؤقت (Httpcontext.Cache)، والتخزين المؤقت الصفحة (Response.Headers [تنتهي]).

Answer 5

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

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

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

وأود أن يبقيه بسيط، وريفاكتور للأداء فقط حيث كنت في حاجة للقيام بذلك.

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

Answer 6

وتشير بعض الأبحاث إلى أن تطبيق تفاعلي يجب تقديم ردود الفعل داخل 250ms للا تجعل المستخدم يعتقد أنه عالق أو أن فشلت العملية. مستوى القبول على شبكة الإنترنت هو أعلى إلى حد ما رغم ذلك، وعادة ما يتم تقديم تعليقات من WebBrowser التي صفحة جديدة يتم تحميل. مع أجاكس عليك أن تأخذ الرعاية لتوفير نوع سوم من ردود الفعل على الرغم من أنه سيقوم المتصفح لا تظهر ما يحدث.