كيف تُسرّع موقع جامعتك المبني على دروبال: التخزين المؤقت وشبكة توصيل المحتوى (CDN) وتقنية BigPipe

تعمل المواقع الإلكترونية للجامعات بسلاسة في معظم أيام السنة، لكنها تتعثّر في عدد قليل من الأيام المزدحمة. ونادرًا ما يكون السبب خادمًا ذا سعة غير كافية، بل لأن معظم الصفحات في تلك الأيام لم يعد من الممكن تقديمها من نسخة مخزّنة. يشرح هذا المقال بلغة مبسّطة كيف يخزّن دروبال الصفحات، وما الذي تُسرّعه شبكة توصيل المحتوى (CDN) وما الذي لا تُسرّعه، ومن أين تبدأ إذا أردت أن يصمد الموقع.

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

متى يتباطأ موقع الجامعة فعلًا؟

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

أما في الأيام المزدحمة فيتغيّر هذا المزيج. إذ يصبح جزء كبير من الزوار طلابًا مسجّلين للدخول. وبمجرد أن يسجّل أحدهم دخوله، تصبح الصفحة خاصة به، ولا تعود النسخة المخزّنة للجميع مناسبة له. فيبدأ الخادم ببناء آلاف الصفحات من الصفر في الوقت نفسه.

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

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

كيف يخزّن دروبال الصفحات

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

للزوار غير المسجّلين للدخول

هذه هي الحالة السهلة. فالجميع يرى الصفحة نفسها، ولذلك تكفي نسخة مخزّنة واحدة لخدمة الجميع. صفحات البرامج والأخبار وبيانات التواصل تصل إلى آلاف الأشخاص من النسخة نفسها، ولا يكاد الخادم يبذل أي جهد.

للمستخدمين المسجّلين للدخول

في اللحظة التي يسجّل فيها أحدهم دخوله، يصبح جزء من الصفحة خاصًا به وحده: اسمه، وإشعاراته، ومقرراته. ولا يعود من الممكن استخدام نسخة واحدة مخزّنة للجميع.

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

وإذا ظلّت تلك الأجزاء الشخصية بطيئة، يتدخّل BigPipe. طُوِّر هذا الأسلوب أولًا في Facebook، ثم اعتمده دروبال في نواته. وطريقة عمله بسيطة: تُرسَل الأجزاء المشتركة من الصفحة فورًا، وتتبعها الأجزاء الشخصية حالما تجهز، فيرى الزائر الصفحة وهي تكتمل تدريجيًا بدلًا من التحديق في شاشة فارغة. ووفقًا لوثائق دروبال، فإن هذه الميزة مفعّلة افتراضيًا في التثبيت القياسي منذ الإصدار 8.5، ما يعني أنها تعمل بالفعل على معظم المواقع.

ما الذي يحدث عندما يتغيّر المحتوى

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

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

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

ما الذي تُسرّعه شبكة CDN، وما الذي لا تُسرّعه

تقدّم شبكة CDN ملفات الموقع من خوادم موزّعة حول العالم، فتصل الصور والفيديوهات والخطوط من مكان قريب من الزائر. وفي مواقع الجامعات تشكّل هذه الملفات معظم حجم الصفحة، لذا فالمكسب حقيقي.

على جانب دروبال، تتولّى ذلك وحدة CDN. وهناك تفصيل يؤثر في التخطيط: فالإصدار المستقر يعمل مع دروبال 9 و10، بينما لا يزال دعم دروبال 11 قيد الاختبار. وعلى المؤسسة التي تعمل بالفعل على دروبال 11 أن تعرف ذلك مسبقًا.

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

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

الصفحات التي تعرض بيانات حيّة

أعداد المقاعد والجداول الدراسية والنتائج تأتي من نظام آخر ولا يجوز أن تصبح قديمة. ولأنه لا يمكن تخزينها، فهي أكثر الصفحات كلفةً في الموقع.

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

تناولنا جانب البيانات في هذه الصفحات في مقال تكامل دروبال مع نظام معلومات الطلاب.

تشغيل مواقع متعددة من منصة واحدة

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

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

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

ما الذي ينبغي قياسه

لأدوات القياس نقطة عمياء تستحق المعرفة. فمعظمها يختبر الموقع دون تسجيل الدخول، ما يعني أنها لا ترى أبدًا الصفحات التي تتعثّر في اليوم المزدحم. فقد تحصل الصفحة الرئيسية على درجة مثالية بينما تنهار شاشة اختيار المقررات.

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

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

من أين تبدأ

يُجدي البدء قبل الذروة بشهر على الأقل واتّباع الترتيب التالي.

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

بعد ذلك، راجع الصفحات التي يراها المستخدمون المسجّلون للدخول وحدّد الأجزاء الشخصية فعلًا. ففي معظم المواقع تكون هذه الأجزاء أقل مما هو متوقع، ويمكن جعل كل ما سواها قابلًا للتخزين.

ثم افصل العناصر التي تعرض بيانات حيّة، وامنح كلًّا منها عمرًا معقولًا، وقرّر ما يعرضه كل منها عندما يكون النظام الآخر غير متاح.

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

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

إن منصات دروبال التي يبنيها فريق Drupal4edu في دروبارت لمؤسسات مثل جامعة يديتبه وجامعة إستينيه وجامعة ميديبول مُعدّة لاستيعاب هذه الذروات بهذه الطريقة تحديدًا. يمكنك قراءة المزيد عن نهجنا في صفحة دروبال في التعليم العالي.

أسئلة شائعة حول سرعة مواقع دروبال