#تحسين أداء الموقع مع Ruby On Rails
سنتحدّث في هذه الحلقة عن أداء موقع GoRails. فقد طُرح الموضوع في المنتدى مؤخرًا. وبالتحديد ما هي الأساليب التي استخدمها في تحسين أداء الموقع بهدف الحصول على تحميل أسرع للصفحة. بالنسبة لي لا أظن أن الموقع بشكله الحالي هو فائق السرعة بل إن الأداء جيد ومقبول نسبيًا.
لنتحدّث أوّلًا عن الخادم. الموقع يستخدم خدمة الاستضافة المقدمة من DigitalOcean بالخطة الشهرية ذات السعر 20 دولارًا مع ذاكرة عشوائية بحجم 2 جيغا.
التحسين سيكون منقسمًا إلى جزئين: الجزء الخاص بالخادم والجزء الخاص بالواجهة. فبعد أي طلب من طلبات المتصفح سيكون لدينا وقت استجابة الخادم بالإضافة إلى الجزء الخاص بتحميل ملفات CSS و جافاسكربت ورسم وطباعة الصفحة على المتصفّح، وتحميل الصور، الخ.
إذًا، الأساس هو الخادم المقدّم من DigitalOcean ومواصفاته. ومن ثم لدينا برمجيات خادم الويب و خادم التطبيق. أما لخادم الويب استخدم NGINX. ولخادم التطبيق استخدمPassenger. كما قمت بإعداد الخادم ليستخدم عددًا مناسبًا من workers وذلك بما يتناسب مع الذاكرة العشوائية والمعالج التي يملكها الخادم. وبذلك سأحصل على أفضل أداء ممكن الخادم واستغلاله بكامل طاقته دون الزيادة عن الحد الأعظمي.
لا يختلف الإعداد سواء كنت تستخدم heroku أوDigitalOcean أو AWS أو أي مزود استضافة. كل ما عليك فعله هو تفحّص مواصفات الخادم من ذواكر ومعالج، ومن ثم إعداد خادم الويب ليتلائم معها.
أما من ناحية التطبيق وأقصد به تطبيق Rails، فإن أهم ما أركز عليه هو التقليل من عدد استعلامات قواعد البيانات Database Query في كل صفحة قدر الإمكان. وهذه المهمة ليست سهلة كما قد يبدو عليه الأمر. خذ الصفحة الرئيسية لهذا الموقع، فبنظرة سريعة يمكن لنا أن نحصي سبعة استعلامات على الأقل:
- قسم آخر الحلقات
- قسم آخر الأسئلة
- المستخدمون أصحاب الأسئلة السابقة
- استعلام المستخدم الحالي (في حال تسجيل الدخول)
- قسم الشروحات Guides أيضًا هي من ضمن قاعدة البيانات
- الإشعارات
- صاحب الإشعار
هذا العدد من الاستعلامات ليس بقليل وهو مرشح للزيادة في المستقبل. لذا من المستحسن دائما التقليل من عدد الاستعلامات وتبسيطها. ويجب عدم الاكتراث بالرقم الذي يظهر في الطرفية معبرًا عن الزمن المستغرق لكل استعلام، فبعد أي استعلام على مكتبة Acitve Record معالجة هذه العائد من هذا الاستعلام وتحويله إلى كائنات، ومنها إلى HTML. وهنا يبرز الدور الكبير للتخبيئة caching للتحسين من أداء الاستعلامات الكبيرة والمعقّدة.
##التخبئة Caching عند استخدام التخبئة من المستحسن جدًا استخدام برمجيات مثل Redis أو Memcached والتي تعمل على تخبئة البيانات في الذاكرة العشوائية بدلًا من استخدام القرص الصلب ذو السرعة المنخفضة (حتى مع أقراص SSD السربعة). طبعًا في جميع الأحوال التخبئة باستخدام القرص الصلب هي أفضل من القيام بالاستعلام، ولكن التخبئة على الذاكرة العشوائية لا تُقارن بسرعة القرص الصلب بأي حالٍ من الأحوال. وهذا بالضبط ما استخدمه في موقع GoRails هنا. تجدر الإشارة إلى أنه يمكن أيضًا استخدام أسلوب التخبئة: Russian Dolls (أي الدمى الروسيّة) والذي يساعدنا هذا الأسلوب من التخبئة في التقليل من عدد الاستعلامات بين العميل والخادم.
##الأصول Assests تعتبر جزئية التعامل مع الأصول هامة للغاية، والتي فيها ننتقل من تحسين الأداء على مستوى الخادم إلى التحسين على مستوى العميل Front-End. لإدارة هذه الأصول يتم استخدام الخوادم البرمجيذة مثل: NGINS أو Apache والتي تَتقدّم على طبقة التطبيق في الناحية الهيكلية أو لنقل الهرميّة. وهذا النوع من الخوادم من مهمته تخديم الملفات الثابتة static files. ولكن يجب الانتباه إلى نقطة هامّة هنا، إن استضافة الملفات الثابتة (الصور أو ملفات التنسيق أو أي ملف ثابت) على نفس خادم التطبيق سيؤدّي إلى بطئ في تحميل الصفحة. ويعود هذا الأمر إلى أن متصفحات الوب لا تقوم بتحميل أكثر من خمسة ملفّات للمجال الواحد في الوقت نفسه، وبالتالي كلما كانت الملفات الثابتة موزعة على أكثر من مجال كلما زادت عدد التحميلات في اللحظة الواحدة.
والنقطة الأخرى الأخرى التي يجب أخذها بعين الاعتبار هي استخدام خدمات CDN والتي ستتمكن من خلالها بتوزيع ملفاتك الثابتة على خوادم منتشرة في مختلف أرجاء العالم. والعميل سيتمكن عندها من تحميل أي ملف ثابت من الخادم الأقرب إليه، الأمر الذي سيقلل من زمن التحميل نسبيًا.
بالنسبة لموقع GoRails فأنا استضيف الصور المصغّرة على موقع Wistia والصور الشخصية الخاصة بكل مستخدم على موقع Gravatar. لذا فالتطبيق نفسه لا يتعامل مع مشاكل الملفات والتحميل والرفع. الأمر الذي يسهل علي من مهمة التطوير والصيانة.
##Turbolinks لا نستطيع التحدث عن تحسين الأداء على جهة الخادم من دون التطرق إلى أُطر العمل المبينية بلغة جافاسكربت، والتي يتحدث عنها الجميع في الوقت الحالي، وذلك نحو React أو Angular أو Ember. ولكن في رأي الشخص أن السلاح السرّي هو استخدام مكتبة turbolinks. ويعود السبب في ذلك إلى أن turbolinks صغيرة للغاية مقارنة بمكتبات جافاسكربت، وكما أنها لا تحاول فعل الكثير بل الكافي.
إن الفكرة الجوهرية في مكتبات جافاسكربت أو turbolinks هي أنها تقوم بتحميل كافة عناصر وأجزاء الصفحة مرّة واحدة ومن ثم تحمّل ما هو ضروري ولازم في كل طلب، بدلا من تحميل كافة عناصر الصفحة. ولتحقيق هذه المهمة فيما مضى كنا نستخدم Ajax، ولكن الأمور لم تكن سهلة على الإطلاق أو مريحة بالنسبة للمطور. وهنا برزت الحاجة إلى هذا النوع من المكتبات. ولكن هذه المكتبات في نفس الوقت أيضًا لها مشاكل، أبرزها عدم التوافق مع عناكب البحث. فمحركات البحث حتى الآن لا تجيد أرشفة جافاسكربت بالشكل الأمثل.
أبرز ما يعجبني في turbolinks هو أنها تتيح لي بناء الموقع مرّة واحدة وعلى جهة الخادم، والحصول على سرعة مضاهية للسرعة التي تقدمها باقي مكتبات جافاسكربت.
الاتجاه نحو استخدام مكتبات جافاسكربت يتطلب مطوّر مختص ضمن فريق العمل للتعامل مع هذا النوع من المكتبات على عكس turbolinks، وهذه من النقاط الهامة التي يجب أخذها بعين الاعتبار. أما النقطة الأخرى هي حجم ملفات هذه المكتبات، وهذا الحجم له تأثير كبير على أجهزة الهاتف المحمول بطبيعة الحال.
على الجهة الأخرى إن كان التطبيق يتطلّب تفاعل معقّد مع المستخدم، فربما مكتبات جافاسكربت هي الخيار الأفضل. أو من الممكن جدًا استخدام turbolinks والاستعانة بمكتبة React مع الأجزاء المعقدة من التطبيق. فالمكتبتان تتلائمان بشكل مثالي فيما بينهما.
إلى هنا نكون قد وصلنا إلى نهاية الحلقة. أرجو أن تكون قد نالت إعجابكم.