كيف تنجو التجارة الإلكترونية من الترقيات على نطاق واسع. الاستعداد لأحمال الذروة على الويب [الجزء 1]

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

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

ما يهدد الجمعة السوداء

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

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



بالمقارنة مع القمم اليومية العادية ، عندما لا يتم الاحتفاظ بأي أسهم ، فإن حركة المرور في الجمعة السوداء تنمو بنسبة 100-200٪ ، وهذا ليس الحد الأقصى.

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

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

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

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

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

الإعداد الفني للموقع

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

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

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

نظرًا لوجود جانبين في سياق أداء الموقع - سرعة الاستجابة وعدد الطلبات التي تتم معالجتها في وقت واحد ، فإننا سنحسن هذه المعلمات.

في أغلب الأحيان ، يمثل النشاط التجاري سرعة الاستجابة كسرعة الموقع وفقًا لـ Google Analytics ، وعدد الطلبات المتزامنة مثل عدد المستخدمين في نفس الوقت على الموقع.

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

نحن نحسن سرعة الاستجابة

عند تحسين سرعة الاستجابة ، نحن مهتمون بمؤشرين: سرعة استجابة الخادم ووقت تحميل الصفحة.

يتكون وقت تحميل الصفحة من الروابط التالية:

• وقت إنشاء صفحة الخادم ؛
• وقت نقل الصفحة من الخادم إلى العميل ؛
• وقت معالجة الصفحة في متصفح العميل.

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

1. تحقق من تحميل قناة الإنترنت. احسب النمو المقدر. إذا كنت في شك ، قم بتوسيع القناة. قد يقدم لك بعض موفري الخدمة ، بالإضافة إلى الإضافات باهظة الثمن بشكل مستمر ، تمديدًا مؤقتًا لفترة الذروة (أرخص بكثير) أو حتى يسمح لك بتجاوز السرعة القصوى لفترة وجيزة.
2. باستخدام CDN؟ اتصل بالدعم الفني وحذر من نمو حركة المرور المخطط له. إنهم يستعدون أيضًا للقمة العامة ، وستكون توقعاتك مفيدة. إذا وعدت CDN بأن كل شيء سيكون على ما يرام ، ولكن على الرغم من كل شيء ، سوف "يستلقي" ، فإن وجود المراسلات سيساعد في وضع مطالبات بالتعويض.
3. مقدمًا ، قم بعمل برنامج نصي لتعطيل المكونات الخارجية مؤقتًا في حالة حدوث مشاكل. قم بمحاذاة السيناريو مع العمل. لن يكون من غير الضروري التواصل مع الدعم الفني للخدمات المستخدمة ، على أي حال من المستحيل عادة التأثير عليها بطريقة أو بأخرى.
4. في العديد من المواقع ، يتم تقديم ثابت باستخدام خادم التطبيق. تحت العبء المرتفع ، يزداد عدد طلبات الإحصاء عدة مرات ، ويبدأون في التنافس على الموارد مع التطبيق نفسه. تأكد من تكوين الإحصائيات العائدة مباشرة من Nginx. أولاً ، ستتعامل بشكل أفضل مع هذا ، وثانيًا ، سيكون هناك عمل أكثر فائدة لخيوط Apache أو Tomcat أو Jetty.

تحسين سرعة الاستجابة

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

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

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

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

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

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

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

فيما يلي خطة التدريب الفني العامة:

1. تعرف على المؤشرات الحالية (قم بإجراء اختبار تحميل الإصدار الحالي من الموقع) ؛
2. لفهم ما هو مفقود بالضبط ومقدار الموارد المطلوبة للطلب ؛
3. إضافة موارد ؛
4. كرر اختبار الإجهاد ومعرفة ما إذا كان ذلك يساعد.

تبدو سهلة للغاية؟ أنت على حق ، كل نقطة محفوفة بالعديد من المفاجآت.

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

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

نقوم بإجراء اختبار الحمل بشكل صحيح

أين الاختبار؟

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

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

يجب أن تستوفي المتطلبات التالية:

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

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

كيف تولد حمولة؟

1. اختبار الطلبات من السجلات

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

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

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

2. باستخدام Yandex.Tank و Phantom

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

ولكن ، على الرغم من كل الراحة ، فإن الخزان له عيب كبير: فهو لا يعرف كيفية استخدام جلسات المستخدم.

يمكنك نسيان التفويض ، والعمل الكامل مع ملفات تعريف الارتباط والتأخير المتغير. يمكن للدبابة أن "تنقر" الطلبات من عنوان واحد فقط.

سوف يناسبك إذا:

• لا يوجد فرق في وقت استجابة الخادم للمستخدمين المصرح لهم وغير المصرح لهم ، أو أنه لا يكاد يذكر ؛
• اختبار API بدون جلسات HTTP بشكل صريح ؛
• يتوافق هذا النهج بشكل عام مع منطق موقعك (عادةً لا يناسب المتاجر عبر الإنترنت).

3. باستخدام Apache JMeter

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

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

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

توصيات اختبار الإجهاد

يعتمد اختبار الحمل الجيد على تحليل حركة المرور المختصة وإعداد جودة عالية للنموذج الإحصائي والملفات الشخصية للمحاكاة.

قم بتمييز 5-7 أنواع رئيسية من الصفحات (لا تنس أيضًا الصفحات المقصودة للأسهم) ، احسب النسبة المئوية لإجمالي عدد الزيارات الموزعة بينهما. ضع في اعتبارك أنه قد تكون هناك عدة طلبات لمحتوى ديناميكي لكل صفحة. بالنسبة لك ، الصفحة هي مجموعة كاملة من هذه الطلبات. قم بتحليل مقدار الوقت الذي يقضيه المستخدمون في كل نوع من أنواع الصفحات: متوسط ​​ومتوسط ​​الحد الأدنى ومتوسط ​​الحد الأقصى.

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

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

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

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

تلعب الملفات الشخصية دورًا لـ JMeter فقط ، ولكن من خلال إنشاء قوائم استعلام ، يمكنك تجهيز خراطيش "الخزان".

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

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

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

هل كل شيء جاهز؟ رائع ، انطلق!

نستخدم المراقبة في الاختبارات

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

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

من حيث المبدأ ، سيحب المضيف هذا النهج. قد تحصل حتى على وضع عميل ذهبي.

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

عوامة حياتك في البحر من الأسباب المحتملة هي نظام للرصد.



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

فيما يلي قائمة لمساعدتك على البدء:

• تحميل وحدة المعالجة المركزية (استخدام وحدة المعالجة المركزية ، تحميل وحدة المعالجة المركزية) ؛
• تحميل ذاكرة الوصول العشوائي
• تحميل القرص (IOPS ، الكمون) ؛
• عدد اتصالات الشبكة (وقت الانتظار ، انتظار الانتظار ، إغلاق الانتظار ، تأسيس) ؛
• عدد المقابس المفتوحة ؛
• عدد عمليات المستخدم ؛
• عدد الملفات المفتوحة ؛
• حركة مرور الشبكة (بالميغابت والحزم ، بالإضافة إلى الأخطاء والقطرات).

وأيضًا:

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

. , « ». , «» , .

, , .

- , : , HDD SSD. -, .

. .

: , , ? , , , 2- , - (, 0,5 ) 1,5 . - «, ».

1 , . , . , . , ( ) , .

, , , .

«» , . 2-3 , , .

, : . , . , , , , .

. . , SLA, , , , , «» .

. , . .

, , . , , .

, .
-, ( ), -, . .

, . - , .

, , , « e-commerce. », 16 . .