مرحبا يا هبر! اسمي أليكسي بريستافكو ، وأنا مدير مشاريع الويب في DataLine. مقالتي اليوم حول كيفية إصلاح أو منع مشاكل أداء الواجهة الخلفية لتطبيقات الويب.
سيركز هذا على كيفية تحسين تطبيقات الويب التي تعاني من مشاكل مزمنة في قابلية التوسع أو الأداء أو الموثوقية.
أي شخص مهتم - نرحب تحت التخفيض!
المصطلحات
لنبدأ بإلقاء نظرة على المصطلحات. بالحديث عن أداء مشاريع الويب أو أنظمة الويب ، أعني في المقام الأول النهاية الخلفية ومكون الخادم. ما يحدث عندما يكون تحميل الصفحات في متصفح قصة مختلفة تمامًا ، والتي ، على الأرجح ، سيتم تخصيصها لمقال منفصل.
- سيكون مقياس أداء التطبيق هو عدد الطلبات التي تمت معالجتها في الثانية (RPS) وسرعة تنفيذها (TTFB - الوقت حتى البايت الأول).
- وفقًا لذلك ، نعني بقابلية التوسع في النظام مجموعة من الفرص لزيادة RPS.
الآن عن الموثوقية. هنا من الضروري فصل مفهومين: التسامح مع الخطأ والتسامح مع الكوارث.
- مرونة الفشل - قدرة النظام على الفشل إذا فشل خادم واحد أو أكثر في مواصلة العمل ضمن المعلمات المطلوبة.
- تعتبر الأنظمة ذات التكرار الكامل للنسخ الاحتياطي (ما يسمى الكتف الثاني) والقادرة على العمل دون تقليص قوي مع الفشل الكامل لأحد مراكز البيانات مقاومة للكوارث .
في نفس الوقت ، النظام الذي يتحمل الكوارث هو نظام آمن من الفشل. إن الوضع الذي يستمر فيه النظام الذي يتحمل الكوارث ولكنه لا يتحمل الأخطاء يعمل على "كتف" واحد هو أمر طبيعي تمامًا. ولكن إذا فشل أحد الخوادم ، فسوف يفشل النظام أيضًا.
الآن بعد أن اكتشفنا المفاهيم الرئيسية وقمنا بتحديث المصطلحات الحالية ، حان الوقت للانتقال مباشرة إلى أساسيات التحسين واختراق الحياة.
من أين تبدأ التحسين
كيف تفهم من أين تبدأ التحسين؟ قبل الإسراع في التحسين ، خذ نفسًا عميقًا واقضي بعض الوقت في البحث عن التطبيق.
تأكد من رسم مخطط تفصيلي. اعرض عليه كل مكونات التطبيق وعلاقاته. بعد فحص هذا المخطط ، يمكنك اكتشاف نقاط الضعف غير الواضحة سابقًا ونقاط الفشل المحتملة.
"ماذا؟ الى اين؟ متى؟ " - تحسين الاستعلامات
انتبه بشكل خاص للطلبات المتزامنة. دعني أذكرك ، هذه هي الطلبات عندما نرسل طلبًا في نفس الموضوع وننتظر الرد عليه. هذا هو المكان الذي تكمن فيه أسباب الفرامل الخطيرة عندما يحدث خطأ ما على الجانب الآخر. لذلك ، إذا كان بإمكانك تقليل عدد الطلبات المتزامنة أو استبدالها بطلبات غير متزامنة ، فقم بذلك.
إليك بعض الحيل لمساعدتك في تتبع طلباتك:
- تعيين معرف فريد لكل طلب وارد. يحتوي Nginx على متغير مدمج $ request_id لهذا الغرض. قم بتمرير المعرف في الرؤوس الموجودة على الجانب الخلفي واكتب على جميع السجلات. حتى تتمكن من تتبع الطلبات بسهولة.
- تسجيل ليس فقط نهاية الطلب إلى المكون الخارجي ، ولكن أيضا بدايته. لذا يمكنك قياس المدة الفعلية للمكالمة الخارجية. يمكن أن تختلف بشكل كبير عما تراه على النظام البعيد ، على سبيل المثال ، بسبب مشاكل في الشبكة أو فرامل DNS.
لذلك ، يتم جمع البيانات. الآن دعونا نحلل نقاط المشكلة. حدد:
- أين يقضي معظم الوقت؟
- من أين تأتي معظم الطلبات؟
- من أين تأتي أطول الطلبات؟
نتيجة لذلك ، ستحصل على قائمة بالأقسام الأكثر إثارة للاهتمام في النظام للتحسين.
نصيحة: إذا جمعت أي نقطة الكثير من الاستعلامات الصغيرة ، فحاول دمجها في استعلام واحد كبير لتقليل النفقات العامة. غالبًا ما تكون نتائج الاستعلامات الطويلة منطقية في ذاكرة التخزين المؤقت.
نقوم بالتخزين بحكمة
هناك قواعد تخزين مؤقت عامة يجب عليك الاعتماد عليها عند التحسين:
- كلما كانت ذاكرة التخزين المؤقت أقرب إلى المستهلك ، زادت سرعة المهمة. بالنسبة للتطبيق ، سيكون المكان "الأقرب" هو ذاكرة الوصول العشوائي. للمستخدم ، متصفحه.
- التخزين المؤقت يسرع الحصول على البيانات ويقلل الحمل على المصدر.
إذا قامت عشرة خوادم ويب بإجراء نفس استعلامات قاعدة البيانات ، فإن ذاكرة التخزين المؤقت المركزية المركزية ، على سبيل المثال في Redis ، ستعطي نسبة أعلى من النتائج (مقارنة بذاكرة التخزين المؤقت المحلية) وتقليل الحمل الكلي على قاعدة البيانات ، مما سيحسن بشكل كبير الصورة الإجمالية.
نصيحة 1: هل التخزين المؤقت لمكون الصفحة النهائية على جانب Nginx باستخدام Edge Side Includes. تتناسب بشكل جيد مع بنية الخدمات الصغيرة / SOA وتفريغ النظام ككل ، مما يحسن بشكل كبير سرعة الاستجابة.
نصيحة 2: تتبع حجم الكائنات في ذاكرة التخزين المؤقت ونسبة الضرب وكتابة / قراءة وحدات التخزين. كلما كان الكائن أكبر ، كلما استغرقت المعالجة وقتًا أطول. إذا كنت تكتب إلى ذاكرة التخزين المؤقت في كثير من الأحيان أو أكثر مما تقرأ ، فإن ذاكرة التخزين المؤقت هذه ليست صديقك. من الجدير إما إزالة أو التفكير في زيادة فعاليته.
نصيحة 3: استخدام مخابئ قاعدة البيانات الخاصة بك حيثما أمكن ذلك. التكوين الصحيح يمكن أن يسرع العمل.
تحميل ملفات التعريف
نمر لتحميل ملفات التعريف. كما تعلم ، هناك نوعان رئيسيان: OLAP و OLTP.
- بالنسبة إلى OLAP (المعالجة التحليلية عبر الإنترنت) ، يعد مقدار حركة المرور التي يتم إنفاقها في الثانية أمرًا مهمًا.
- بالنسبة إلى OLTP (معالجة المعاملات عبر الإنترنت) ، يكون المؤشر الرئيسي هو سرعة الاستجابة وتوقيتات المللي ثانية.
في معظم الأحيان ، يكون من الفعال فصل هذين النوعين من الحمل. كحد أدنى ، ستحتاج إلى ضبط منفصل لقاعدة البيانات ، وربما مكونات أخرى من النظام.
نصيحة: تتم معالجة طلبات القراءة من لوحة المشرف عادةً باستخدام نوع OLAP. قم بإنشاء نسخة منفصلة من قاعدة البيانات وخادم الويب لهذه المهمة لتفريغ النظام الرئيسي.
قواعد البيانات
لذلك ، اقتربنا بطبيعة الحال من واحدة من أصعب مراحل التحسين - وهي تحسين قاعدة البيانات.
دعني أذكرك بالقاعدة العامة: كلما صغر حجم قاعدة البيانات ، زادت سرعة عملها. تنظيم قاعدة البيانات أمر حاسم عندما يتعلق الأمر بالسرعة.
إذا أمكن ، قم بتخزين
البيانات التاريخية وسجلات التطبيق والبيانات
المستخدمة بشكل متكرر في قواعد بيانات مختلفة. والأفضل من ذلك ، نشرها على خوادم مختلفة. لن يؤدي ذلك إلى تسهيل عمر قاعدة البيانات الرئيسية فحسب ، بل سيوفر أيضًا مساحة أكبر لمزيد من التحسين ، على سبيل المثال ، في بعض الحالات ، سيسمح باستخدام فهارس مختلفة لأحمال مختلفة. أيضا ، "انتظام" الحمل يبسط عمر المجدول ومحسن الاستعلام لخادم قاعدة البيانات.
ومرة أخرى حول أهمية التخطيط
حتى لا تضغط على التحسين حيث لا تكون هناك حاجة إليه حقًا ، اختر الأجهزة بناءً على المهام.
- بالنسبة للطلبات الصغيرة ، ولكن المتكررة ، من الأفضل أخذ المزيد من نوى المعالج.
- للطلبات الثقيلة - عدد أقل من النوى مع سرعة ساعة أعلى.
حاول وضع حجم العمل لقاعدة البيانات في ذاكرة الوصول العشوائي. إذا لم يكن ذلك ممكنًا أو كان هناك عدد كبير من طلبات الكتابة ، فقد حان الوقت للبحث عن نقل قواعد البيانات إلى SSDs. ستعطي زيادة كبيرة في سرعة العمل مع القرص.
تحجيم
أعلاه ، وصفت الآليات الرئيسية لتحسين أداء التطبيقات دون زيادة مواردها المادية.
سنتحدث الآن عن كيفية اختيار استراتيجية التحجيم وزيادة المرونة.
هناك نوعان من تحجيم النظام:
- رأسيًا - نمو الموارد مع الحفاظ على عدد الكيانات ؛
- أفقي - زيادة في عدد الكيانات.
تنمو طويل القامة
لنبدأ باختيار استراتيجية قياس رأسي.
أولاً ، ضع في الاعتبار
زيادة قوة النظام . إذا كان نظامك يعمل ضمن خادم واحد ، فسيتعين عليك الاختيار بين زيادة سعة الخادم الحالي أو شراء خادم آخر.
قد يبدو أن الخيار الأول أسهل وأكثر أمانًا. ولكن سيكون من بعيد النظر شراء خادم آخر والحصول على قدر كبير من الخطأ كمكافأة للإنتاجية. لقد تحدثت عن هذا في بداية المقال.
إذا كان النظام الخاص بك يحتوي على العديد من الخوادم وكان الخيار هو زيادة سعة الخوادم الموجودة أو شراء المزيد ، فعليك الانتباه إلى الجانب المالي. على سبيل المثال ، قد يكون أحد الخوادم القوية أكثر تكلفة من اثنين "أضعف" بنسبة 50٪. لذلك ، سيكون من المعقول التفكير في خيار الحل الوسط الثاني. في الوقت نفسه ، مع وجود عدد كبير من الخوادم ، تعتبر نسبة الأداء واستهلاك الطاقة وتكلفة الحامل الكامل أمرًا بالغ الأهمية.
تنمو على نطاق واسع
التحجيم الأفقي هو قصة عن التسامح مع الخطأ والتجميع. في الحالة العامة ، كلما زادت حالات وجود كيان واحد لدينا ، زادت درجة تحمل الخطأ للحل بأكمله.
ربما يكون أول شيء تريد قياسه هو
خوادم التطبيقات . العائق الأول لذلك هو تنظيم العمل مع مصادر البيانات المركزية. بالإضافة إلى قواعد البيانات ، فهي أيضًا بيانات الجلسة والمحتوى الثابت. إليك ما أوصيك به:
- لتخزين الجلسات ، استخدم Couchbase ، وليس Memcached المعتاد ، لأنه يعمل مع نفس البروتوكول ، ولكن ، على عكس memcached ، فإنه يدعم التجميع.
- يتم تخزين جميع الإحصاءات ، خاصةً الكميات الكبيرة من الصور والمستندات ، بشكل منفصل ويتم تقديمها باستخدام Nginx ، وليس من رمز التطبيق. سيوفر لك هذا المال على التدفقات ويبسط إدارة البنية التحتية.
"سحب" قاعدة البيانات
من الصعب تحجيم قواعد البيانات. هناك أسلوبان رئيسيان لهذا: التقسيم والتكرار. اعتبرهم.
أثناء
النسخ المتماثل ، نضيف نسخًا متطابقة تمامًا من قاعدة البيانات إلى النظام ، بينما
يتم تقسيم الأجزاء وأجزاء منفصلة منطقيًا إلى أجزاء. في نفس الوقت ، من المرغوب فيه للغاية إجراء تقسيم إلى شرائح بالتوازي مع النسخ المتماثل (النسخ المتماثل) لكل قطعة حتى لا تفقد تحمل الخطأ.
تذكر: غالبًا ما تتكون كتلة قاعدة البيانات من عقدة رئيسية واحدة تتولى دفق الكتابة والعديد من العقد التابعة المستخدمة للقراءة. من وجهة نظر التسامح مع الخطأ ، هذا أفضل قليلاً من خادم واحد ، حيث يتم تحديد التسامح العام للخطأ بواسطة العنصر الأقل استقرارًا في النظام.
المخططات التي تحتوي على أكثر من معالجات قاعدة بيانات (طوبولوجيا الحلقة) دون تأكيد السجل على كل خادم ، غالبًا ما تعاني من عدم الاتساق. في حالة فشل أحد الخوادم ، سيكون من الصعب للغاية استعادة التكامل المنطقي للبيانات في الكتلة.
نصيحة: إذا لم يكن من المنطقي أن يكون لديك العديد من الخوادم الرئيسية ، ففكر في الإمكانية المعمارية للنظام الذي يعمل بدون سيد لمدة ساعة على الأقل. في حالة وقوع حادث ، سوف يمنحك هذا الوقت لاستبدال الخادم دون توقف النظام بأكمله.
نصيحة: إذا كنت بحاجة إلى الاحتفاظ بأكثر من 2 من سادة البيانات ، فأوصيك بالنظر في حلول NoSQL ، نظرًا لأن العديد منها يحتوي على آليات مدمجة لإدخال البيانات في حالة متسقة.
في السعي وراء التسامح مع الخطأ ، لا تنسى بأي حال من الأحوال أن النسخ المتماثل يؤمنك
فقط ضد فشل الخادم الفعلي . لن يتم الحفظ من تلف البيانات المنطقية بسبب خطأ المستخدم.
تذكر: يجب نسخ أي بيانات مهمة احتياطيًا وتخزينها كنسخة مستقلة غير قابلة للتحرير.
بدلا من الاستنتاج
أخيرًا ، بعض النصائح للأداء للنسخ الاحتياطي:
نصيحة 1: اسحب البيانات من نسخة متماثلة منفصلة لقاعدة البيانات حتى لا تفرط في تحميل الخادم النشط.
النصيحة 2: احصل على "تأخر" طفيف في نسخة طبق الأصل من قاعدة البيانات. في حالة وقوع حادث ، سيساعد ذلك على تقليل كمية البيانات المفقودة.
لا يجب أبدًا استخدام الأساليب والتقنيات الواردة في هذه المقالة بشكل أعمى ، دون تحليل الوضع الحالي وفهم ما ترغب في تحقيقه. قد تواجه "الإفراط في التحسين" ، وسيكون النظام الناتج أسرع بنسبة 10٪ فقط ، ولكنه أكثر عرضة للحوادث بنسبة 50٪.
هذا كل شيء. إذا كان لديك أي أسئلة ، يسعدني الرد عليها في التعليقات.