هذا المقال مخصص للمؤتمر الذي عقد منذ عامين تقريبا. لماذا أكتب عن مثل هذه الأحداث الطويلة الأمد؟ أولاً ، في رأيي ، لا يعرف الكثير من الناس عن هذا المؤتمر. ثانيًا ، انطباعاتي الشخصية عنها قوية جدًا حتى بعد عامين لدرجة أنني لا أستطيع إلا أن أشاركها. ثالثًا ، أردت حقًا أن أكتب ، ولكن لم يكن من الواضح جدًا كيفية القيام بذلك ، نظرًا لأنني لم أكتب ملاحظات من قبل ، فهذه هي محاولتي الثالثة للكتابة عن هذا المؤتمر. وبالطبع ، أود أن أشكر شركة Distillery ، التي عملت فيها في ذلك الوقت ، ومشرفي سيرجي مشرياكوف على الفرصة لحضور هذا المؤتمر.
يعقد المؤتمر الدولي
لتأثير CMG سنويًا من قبل الرابطة الأمريكية للمتخصصين في مجال تحسين أداء أنظمة تكنولوجيا المعلومات. وقد عقد المؤتمر السنوي CMG منذ عام 1980.
المؤتمر مخصص لهندسة الأداء وتخطيط القدرات. يعد المنظمون والمتحدثون والمشاركون في المؤتمر متخصصين مؤهلين تأهيلاً عالياً في مجال تكنولوجيا المعلومات أو في مجال تخطيط السعة ، بدأ العديد منهم العمل على أجهزة الكمبيوتر المركزية ، ثم ذهبوا إلى الأنظمة الموزعة ، ويواصلون حاليًا العمل في الشركات الرائدة في الصناعة. تأهيل العديد منهم مذهل. كان هناك شركات أو ممثلوها في المؤتمر تتعلق بمراقبة أو اختبار أداء Dynatrace و NewRelic و Soasta و Jmeter و BMC و Moviri و BezNext وغيرها الكثير.
في المؤتمر تم تقديم 120 تقريرًا من أكثر من 15 دولة حول العالم ، خاصة الولايات المتحدة الأمريكية وكندا والدول الأوروبية. تم تنفيذه لمدة خمسة أيام من 7 إلى 11 نوفمبر 2016. كانت طريقة العمل على النحو التالي: بدأت التقارير في الجلسة العامة من الساعة 8.00 صباحًا واستمرت مع التقارير المقطعية في 8 غرف حتى 19.00 مساءً مع استراحة غداء قصيرة في منطقة بعد الظهر. انتهى كل يوم عمل من المؤتمر ببوفيه عام ، كان من الممكن خلاله التواصل شخصيًا مع جميع المتحدثين ومناقشة التقارير المقدمة. كان من الصعب إلى حد ما اختيار تقرير يحضره ، لأنه في جلسات متوازية كانت التقارير ذات الأهمية في نفس الوقت في غرف مختلفة.
في هذه المقالة سأصف بإيجاز التقارير التي أعجبتني أكثر.
أنشأت الجمعية الأمريكية للمتخصصين في تحسين أداء مجموعة أنظمة إدارة أنظمة تكنولوجيا المعلومات في عام 1974 جائزة أبراهام ميكلسون السنوية لمساهمته المهنية في تقييم أداء النظام. تُمنح هذه الجائزة تقليديًا في مؤتمر تأثير CMG.
افتتاح المؤتمر وتقديم جائزة ميشيلسون AA
افتتح المؤتمر بجائزة Andrei Bondi AA Michelson ، وهو مستشار مستقل ، ومؤلف كتاب "أسس هندسة البرمجيات وأداء النظام: العملية ، ونمذجة الأداء ، والمتطلبات ، والاختبار ، وقابلية التوسع ، والممارسة.
بدأت الجلسة العامة الأولى بتقرير من أندريه بوندي. كانت الفكرة الرئيسية للتقرير هي أن الضبط لن يؤدي أبدًا إلى تحسينات في الأداء في بعض الأحيان. وفقا لمؤلف التقرير ، يمكن الحصول على أكبر زيادة في الإنتاجية من خلال القضاء على الأخطاء المعمارية في النظام. أعتقد أن الكثير منكم يعرف ذلك من التجربة الشخصية. خلال مسيرتي المهنية ، توصلت إلى نفس الاستنتاج. على سبيل المثال ، يمكن للانتقال من نظام يبدو أكثر إنتاجية إلى نظام مفتوح المصدر أكثر تواضعا أن يعزز الأداء إذا أزال الفريق الأخطاء المعمارية للإصدار السابق من النظام أثناء النقل.
تحقيق قابلية التوسع والأداء> مليون مستخدم متزامن في الوقت المناسب
Lukas Sliwka ، Grindr
كان العرض التالي المثير للاهتمام بالنسبة لي هو تقرير هؤلاء. مدير Grindr لوكاس كريم. Grindr هو تطبيق المواعدة عبر الإنترنت. تحدث لوكاش في وقت واحد عن تحول الشركة ، وثقافة التنمية (تحولوا إلى سكروم) ، وحول التحول الفني للنظام. Grindr لديها أكثر من 2.5 مليون مستخدم ، منهم مليون نشط. كان المستخدمون الرئيسيون قبل التحويل في الولايات المتحدة الأمريكية وكندا ، حيث ابتعدوا عن الولايات المتحدة ، وانخفض عدد المستخدمين.
كما تقع الخوادم ومستودعات البيانات بشكل رئيسي في الولايات المتحدة الأمريكية. بالإضافة إلى ذلك ، انتقل التطبيق بالفعل إلى أقوى خادم ممكن على الاستضافة ، وتواجه الشركة مشكلة حادة من التحسين والتحجيم. تم حل مشكلة التحسين والتوسع بشكل جذري - أعاد الفريق كتابة المشروع بالكامل من Ruby on Rails إلى Scala ، واستغرق الأمر ستة أشهر. تم اختيار Scala لسببين: أولاً ، كان من الممكن كتابة كود نظيف بأداء جيد ؛ ثانيًا ، كان مطورو Java أكثر توفرًا للتوظيف ، على عكس مطوري Node.js الذين كانوا غاليين وعملوا جميعًا على Facebook.
أثبتت تجربة Grindr المثيرة للاهتمام أنه من أجل التطوير الناجح ، تحتاج في بعض الأحيان إلى بنية جديدة. بعد ذلك ، تم إجراء تحليل لمدة الاستجابة في سياق كل بلد ، وتبين أنه كلما طالت الاستجابة ، قل عدد المستخدمين في هذا البلد. قام فريق التطوير بتحسين وقت الاستجابة ، وتقليله بشكل كبير باستخدام CDN ، وتوزيع مستودع البيانات على الخوادم السحابية مع مراكز في أوروبا وآسيا وأمريكا اللاتينية. بعد حل مشاكل الأداء ، زاد عدد مستخدمي التطبيق في جميع أنحاء العالم. يثبت هذا المثال علاقة مباشرة بين أوقات الاستجابة القصيرة وعدد المستخدمين.
تم تخصيص الجزء الثاني من التقرير لإدارة الفريق. يعمل Grindr على سكروم. يتم فصل الفرق حسب المنتج ، أي أن كل فريق مسؤول تمامًا عن بعض الخدمات أو المنتجات للمستخدم ، وقيمة الأعمال التي يتلقاها المستخدم. الشركة شركة تعتمد على المقاييس ، ولكل فريق مقاييسه ومؤشرات الأداء الرئيسية الخاصة به التي يجب أن يحققها. الإدارة المتوسطة المستوى غائبة تمامًا. لدى الشركة هيكل مسطح ، ويقرر الفريق ما يجب القيام به وكيفية تحقيق أهدافه.
تقارير لوكاش على موقع يوتيوب .
مقابلة لوكاس متاحة هنا .
هل قدراتك متاحة؟
ايجور تروبين ، كابيتال وان بنك
من المثير للاهتمام أن المؤلف بدأ تقريره بمعلومات تفيد أن بنك كابيتال ون قرر أن يصبح شركة مفتوحة إعلامية. من المعروف أن البنوك عادة لا تتحدث عن التقنيات والعمليات. تستخدم في عملهم ، معتبرة هذه المعلومات سرية. ومع ذلك ، في العالم الحديث ، من أجل التنافس على كبار المتخصصين ومواهبهم ، والتي عادة ما تذهب للعمل على Google و Facebook ، يجب أن تكون البنوك أكثر انفتاحًا.
تم تخصيص التقرير لتقييم مزيج من توافر النظام وهامش أدائه. حيث لا يحتاج أحد إلى عرض النطاق الترددي الذي لا يمكن استخدامه.
يصف إيغور شكلًا محددًا لكيفية قياس السعة ومدى توفرها. لديه مقاييس مثل متوسط الوقت بين السقوط ، ومتوسط وقت الاسترداد ، ووقت التوقف لمدة عام ، وغيرها. يعطي Igor صيغة يمكنك من خلالها حساب مدى توفر البنية التحتية الكاملة للمستخدمين. يمكنك رؤية
تقريره بمزيد من التفصيل.
تخطيط سعة التجربة الرقمية
ايمي سبيلمان وريتشارد جيمارك
حديث عن التخطيط لمقاييس إنترنت الأشياء ومقاييس تكنولوجيا المعلومات ومقاييس المرافق.
تقرير حول حقيقة أن العديد من البنى التحتية تعمل الآن بالقرب من عرض النطاق الترددي ، وماذا سيحدث عندما تعمل إنترنت الأشياء في كل مكان. بالنسبة لي ، كان الأكثر إثارة للاهتمام في التقرير هو حجمه. أي أن هناك مهنيين يخططون للموقع ، للمؤسسة ، وهذه صناعة بأكملها. كم مرة نرتقي فيها إلى مثل هذه الرؤية واسعة النطاق؟
ضمان أداء المؤسسة على أساس تحليلات BigData
بوريس زيبيتسكر
يتحدث بوريس عن BigData وأساليب العمل مع البيانات الضخمة. يحدد المراحل التالية للعمل مع البيانات. التحليل التنبئي ، حيث يجب على الشركة اتخاذ قرارات بناءً على البيانات الحالية. الوقت هو المال ولم يتغير شيء على مر السنين ، باستثناء أن الوقت أصبح أكثر تكلفة الآن. المعلومات باهظة الثمن إذا كانت ذات صلة.
يتيح لك العمل مع مجموعات البيانات الكبيرة تقديم التحليل اللازم في الوقت المحدد. ثم يصف بوريس الخطوات. هناك طريقتان رئيسيتان لإجراء تحليل في الوقت الفعلي للبيانات في دفق أو لجمعها في DataLake.
يصف التقرير نهج استخدام خوارزميات معالجة البيانات الكبيرة والتعلم الآلي لإجراء RCA في حالة الفشل ، وكذلك بناء التوقعات على أساس مثل هذه التقارير حول المزيد من سلوك النظام.
نقطة مهمة هي التحقق من موثوقية النتائج ، من خلال مقارنة السلوك الفعلي مع المتوقع.
أعلى 10 عيوب في الأداء تكلف المنظمات عبر الإنترنت الملايين
كريج هايد ، ريجور وريجور
يصف كريغ أغلى 10 أخطاء تؤثر على أداء الموقع. يستشهد كريج بالأرقام التي تفيد بأن الشركة ، في المتوسط ، تخسر 102 مليون دولار من الاحتمالات لثانية واحدة من انتظار المستخدم. مثير للاهتمام ، هاه؟ أجرت الشركة تحليلًا لحوالي 500 موقع ويب وجمعت أهم 10 مشكلات رئيسية تؤدي إلى ضعف الأداء. توصيات Craig حول استخدام ذاكرة التخزين المؤقت ، و CDNs ، وضبط دقة الصورة الصحيحة ، باستخدام الضغط. لكن الشيء الرئيسي هو اختبار ما حدث ، كما اتضح ، يعتقد الكثير من الناس أنهم يستخدمون ذاكرة التخزين المؤقت ، ولكن حوالي 70 ٪ من المحتوى قد لا يتم تخزينه مؤقتًا بسبب الإعدادات غير الصحيحة. يوصي كريغ بتحديد خط أساس الأداء والالتزام به ، وتحديد هدف الأداء للوصول إلى الاختناقات واختبارها وتحسينها. أدوات اختبار اختبار صفحة الويب ، google analytics ، pagepeed ، تقرير مجاني صارم. كانت أكثر الصور متعة بالنسبة لي هي الصور على المواقع بشكل كبير ، في حين أن الحجم لا يسمح لي بتقييم ذلك ، لذلك فإن انخفاض الدقة لا يؤدي إلى تدهور الجودة.
لم أتمكن من العثور على شرائح كريج ، ولكن هنا
تقرير عن نفس الموضوع من قبل أحد موظفي الشركة.
الأعمال الخطرة
جيف بوزن
بضع كلمات عن جيف - إنه مدرس في جامعة هارفارد ، مؤلف 3 كتب ، تم نشر الأول في 71 ، والأخير في 2015 - إعادة التفكير في العشوائية: مؤسسة جديدة للنمذجة العشوائية ،
مقالة ويكي ،
مقابلة مع جيف .
تقرير عن النمذجة والتنبؤ بالأداء. يصف جيف المخاطر التي تنشأ عند نمذجة النظام - مخاطر النموذج ومخاطر معلمات حمل النظام والمخاطر المتوقعة ومخاطر التطبيق ومخاطر الاستخدام - في العمل. يصف جيف بالتفصيل جميع المخاطر المحتملة التي تنشأ عند نمذجة النظام ويحاول التنبؤ بكمية الموارد المطلوبة ونوع توفر النظام المطلوب. الخيارات لأنه ليس من الضروري كتابة اتفاقية مستوى الخدمة - يتم تنفيذ 90٪ من الطلبات في 0.5 ثانية. أقل خطورة - طول قائمة الانتظار أقل من 33x90٪ من الوقت. كتابه عن ذلك. لا تعطي التوقعات التي نستخدمها من الرياضيات الكلاسيكية دائمًا النتائج الصحيحة القابلة للتطبيق ، على الرغم من أن الصيغ قد تكون صحيحة. تعتمد التوقعات إلى حد كبير على افتراضات النموذج. من الأفضل استخدام توقعات تستند إلى تحليل البدائل (AoA ، تحليل البدائل).
جلست وفكرت - إلى أي مدى يبعد هذا عن تجربتي - أوه ، لا يزال لدينا هامش إنتاجية في مرتين ، ماذا؟ كيف عرفت؟ حسنًا ، كانت هناك ذروة وتراكمت الطوابير بالفعل في النظام ، لنأخذ خادمًا أكبر. ماذا تقول حسنا ، ما هي الخطوط؟ حسنًا ، قبل أن نبدأ في استخدامها ، سقط النظام ببساطة. فيما يلي نهج تخطيط الأداء الذي يبدأ بنموذج النظام - كوكب آخر.
كيف تحصل على قيمة من BigData؟
ريناتو بونوميني ، ستيفانو دوني ، موفيري
التالي كان ورشة عمل من
Moviri . Moviri هي شركة أسسها أستاذ في جامعة البوليتكنيك في ميلانو ، ولها مكاتب في ميلانو وبوسطن ، متخصصة في الأداء وتحليل الإنتاجية. حول مدى أهمية ليس فقط جمع الكثير من البيانات ، ولكن أيضًا للاستفادة منها. Stack Yarn ، HDFS ، Pig ، Hive ، Spark ، Zookeeper ، Cassandra ، Cloudera ، Kubernetes. أظهر التقرير مدى سهولة العمل مع تغيير الأداء مع تشغيل الأنظمة في حاويات.
دعاني Moviri إلى مكتبي ، الذي استفدت منه ، منذ حوالي شهر بعد ذلك ذهبت إلى إيطاليا. كان من الرائع مقابلة ستيفانو دوني والتعرف على لوكا فورني ، والاطلاع على المكتب والتحدث عن كل ما يتعلق بتحليل الأداء ، بدءًا من تحليل الأداء وانتهاءً بالمشاكل التي يواجهها المستشارون عند التواصل مع فريق العميل.
مدونة Moviri .
الأداء أم السعة؟ مناهج مختلفة لمهام مختلفة
ألكسندر جيلجور ، فيسبوك
سيكون التقرير مفيدًا لأولئك الذين يشاركون في التنبؤ بالأداء وتخطيط عرض النطاق الترددي. يقدم ألكسندر أمثلة وأساليب يجب استخدامها لكل من الحالات. بشكل عام ، على الرغم من أن مفاهيم القدرة والأداء متقاربة ، يجب استخدام طرق مختلفة للتنبؤات ، مع التركيز على الهدف النهائي للعمل. لماذا نفعل هذا؟ نريد أن نفهم مقدار المعدات التي نحتاجها وما هو النطاق الترددي الذي نريد تقديمه أو نريد التنبؤ بأداء النظام.
هنا يمكنك قراءة
مقال ألكسندر .
شرائح .
كيف تبدأ عندما لا تعرف من أين تبدأ.
جاستن مارتن ، سيرنر
حول لماذا بشكل عام من الضروري القيام بمراقبة الأداء. لكن الحقيقة هي! يعيش الكثير بدون مراقبة ويبدو أن كل شيء على ما يرام معهم. في الواقع ، الكثير لا يحتاجون إليه. حتى ينشروا مقالًا عن موقعهم الرائع على المحور ، ولا يذهب الناس إليهم لمعرفة ما هو موجود. أو حتى لا يؤدي شيء آخر إلى العديد من المستخدمين.
في التقرير ، يخبر جوستين بكل بساطة ما يمكن القيام به للبدء.
إدارة السعة في 90 يومًاخطوات
- حدد ساعات الذروة لنظامك
- افحص حدود أداء مشروعك (اللحظة التي يتوقف فيها النظام بالفعل عن معالجة الطلبات ويبدأ الأداء في التدهور)
- تقليل خسائر الإنتاجية
- حقق التوازن بين الحاجة - ربما يمكنك نقل بعض الأحمال من ساعات الذروة إلى أوقات أقل ازدحامًا.
ينكدين جوستين . يمكن رؤية الشرائح في مقال المؤتمر ، الذي سأقوم بنشره في النهاية.
موازنة الحمل الديناميكي وتقديم الخدمة المستمرة في البنية التحتية السحابية الكبيرة
يوري أردولوف ، RingCentral
يوري يصف انتقال RingCentral من متراصة ، مع رمز قديم إلى الخدمات المصغرة. كانت مشاكل الرمز المترابط هي أنه كان من الصعب تغيير التكوين ، ولم يكن من الممكن القيام بالتوصيل المستمر ، والصعوبات في تحقيق مؤشرات التوفر المطلوبة ، ولم تكن هناك طريقة لإجراء اختبار A \ B ، والقدرة على تطبيق وظائف جديدة فقط لبعض المستخدمين. تم إعادة تصميم النظام وتم استخدام الحاويات والخدمات الصغيرة في التصميم الجديد ، وأصبح من الممكن تغيير حجم النظام عبر الإنترنت ، والقدرة على تغيير إصدار الخدمة دون تغيير التكوين. في بنية الخدمات المصغرة ، تم تخصيص طبقة توجيه التطبيق ، وطبقة موازنة ، وطبقة خدمة (لا تخزن الحالة). بعد إجراء تغييرات العمليات ، تمكنت الفرق من القيام بالتسليم المستمر على الفور ، وزاد توفر النظام من 4 تسع إلى 99.998. تم تقليل الوقت المطلوب لزيادة النظام ونشر خوادم جديدة إلى 4 ساعات.
تجنب التكاليف والتأخيرات والإصدارات الفاشلة باستخدام Lifecycle Virtualization
تود ديكابوا ، خدمات العلامات التجارية CSC الرقمية
يركز تقرير تود على كيفية الحد من مشكلات الإصدار ، والفكرة الرئيسية هي أنه عند اختبار البرنامج ، من المهم النظر في دورة حياة البرنامج بأكملها.
4 مكونات رئيسية:
- المستخدمون - محاكاة افتراضية للمستخدم لسلوك مستخدمي نظامك الحقيقي.
- الخدمات - يجب أن تكون هناك خدمات افتراضية للخدمات حتى تتمكن من التحقق من تشغيل العملية بأكملها من البداية إلى النهاية.
- شبكة - محاكاة ظروف تشغيل الشبكة.
- البيانات - التمثيل الافتراضي للبيانات من خلال عملية بيع من أجل محاكاة مكالمات التطبيق القريبة من ما سيحدث في الواقع.
استنادًا إلى تجربتي ، فإن نسبة كبيرة من الأخطاء أثناء النشر ترجع إلى حقيقة أن القليل من الأشخاص يستوفون جميع الشروط الأربعة ، ولدى المنتج دائمًا شيء لم يكن أحد يتوقعه ، وهذا يكسر الإصدار. من المهم جدًا استخدام حالات استخدام مختلفة مع المبيعات وفقًا لبيانات المستخدم وسلوكه.
هنا مثال من عرض تود:
تود - مؤلف
كتاب عن تحسين الأداء واختبارات الأداء وتفسيرها.
يروي الكتاب مدى أهمية ثقافة اختبار الأداء في المنظمة ، وكيف يمكن إدخالها إذا لم يقم أحد بذلك الآن. يتم إعطاء العديد من الأمثلة من الممارسة مع وصف للمهمة التي يواجهها الفريق ، وخيارات حلها ، والتي تقترب من اختيار الفريق وما كانت العواقب في النظام الحقيقي. في رأيي ، غالبًا ما تدور هذه القصص حول مدى صعوبة التنبؤ بسلوك المستخدم النهائي ، ومدى أهمية جعل مجموعة تركيز صغيرة من عدد محدود من المستخدمين ومعرفة كيف تتوافق توقعاتك مع سلوك مجموعة التركيز.
تطبيق DevOps المستند إلى المقاييس: لماذا وكيف!
أندرياس جرابنر ، Dynatrace
تقرير من Andreas Grabner عن ممارسات DevOps في الشركات المختلفة ولماذا يعتبر وقت قصير من السوق مهمًا. استخدم أندرياس استعارة مثيرة للاهتمام حول التصوير الفوتوغرافي. يتذكر العديد من الأشخاص صور الأفلام - تلتقط صورة ، وتطور ، وتطبع ، وترى أنها غير ناجحة ، ولكن ليس لديك فرصة لإعادة التقاط الصورة ، لأنك في اللحظة الخاطئة بالفعل.
الآن كل شيء مختلف - يمكنك التقاط صورة ، ووضعها على Instagram والحصول على تعليقات فورية ، ويمكنك إنهاء شيء ما يطلبه المشتركون. لا تزال في هذه اللحظة وتتلقى رد فعل في الوقت الفعلي.الآن ، بالعودة إلى البرنامج - كما كان من قبل - تم تخطيط ميزات البرامج الجديدة وتنفيذها واختبارها وصنعها ، على سبيل المثال ، إصدار واحد في السنة. وأدركوا أن الوظيفة التي أنفقت الكثير من المال والجهد كانت مطلوبة من قبل اثنين من ملايين المستخدمين. هل حدث هذا لك؟كيف هي الان رشيقة والقدرة على إصدار الإصدارات كل يوم على الأقل ، كما يفعل Facebook ، هي القدرة على تقييم مدى طلب هذه الوظيفة على الفور من قبل المستخدمين ، سواء كان يجب ترجيحها مع riffs ، أو من الأفضل التخلص منها على الفور وعدم إضاعة الوقت والطاقة.
أوصي بشدة بهذا التقرير للأعمال التي تحاول أن تشرح لفريقها سبب حاجتهم إلى Scrum و Agile! تحاول الآن العديد من شركات الشركات التي لديها إصدارات 3 مرات في السنة أن تصبح أسرع وأنحف وأعلى صوتًا.
بشكل عام ، لا يتعلق التقرير بهذا الأمر ، ولكن حول كيفية بناء ممارسات DevOps ، مما يجعل إصدار الإصدارات جيدًا وغالبًا. نعم ، هذا يحدث. من المهم استخدام المقاييس ومراقبة الوضع مع التطبيق والحمل وإجراء النشر الصحيح على العملية. أندرياس مدافع عن الأداء ولديه عدد غير قليل من التقارير المفيدة حول هذا الموضوع مع شرائح غير عادية وجذابة.هنا تقرير من أندرياس مع شرائح مختلفة قليلا.اختبار الأداء في سياقات جديدة
Eric Proegler، Soasta
في بداية الحديث ، وصف إريك بأثر رجعي كيف تغيرت بنية الأنظمة منذ عام 2000 ، وكيف تغير الانتقال إلى السحابة أو كان يجب أن يتغير ، وكيف تم تصميم الأنظمة مع إمكانية التوسع في السحابة. يقدم إيريك مثالًا من الممارسة عندما أطلقت إحدى شركات التلفزيون التصويت في تطبيق الهاتف المحمول وخلال العرض فقط ، عندما اضطر المستخدمون إلى التصويت ، لم يتمكن النظام من تحمل الحمل وكان يتعذر الوصول إليه. مع ثقافة الشركات الناشئة ، من الصعب التنبؤ بعدد المستخدمين ، ربما تم التخطيط لـ 20 ألفًا ، وسيصل التطبيق بسرعة إلى 50 ألفًا. هناك العديد من التطبيقات لاختبار الأداء في سحابة BlazeMeter (Jmeter) ، Selenium ، Gatling ، Grinder. إنها مجانية ، ولكن تصور النتائج ليس مناسبًا جدًا.لذلك ، يوصى باستخدام إما أداة تصور أخرى (Tableau) أو استخدام قاعدة البيانات الخاصة بك لتحليل ما حدث لاحقًا. عند اختبار تطبيقات الويب ، من المهم التأكد من توزيع مستخدمي الاختبار الوارد جغرافيًا. من المستحسن إجراء اختبارات أداء صغيرة لكل تجميع ومقارنتها بالنتائج الأساسية.يمكن عرض شرائح إريك على عرض الشرائح.إريك هو مؤلف المدونة .بالإضافة إلى التقارير المقدمة في المؤتمر ، تم تنظيم العديد من المناقشات في شكل "مائدة مستديرة". أدان العديد من الخبراء الموضوع في شكل حوار نشط وحيوي مع الجمهور. في رأيي ، هذا شكل مثير للاهتمام للغاية ، حيث يمكن للمشاركين في المؤتمر مشاركة تجربتهم المثيرة للإعجاب في كثير من الأحيان ، ويمكن للمرء أن يأتي للتحدث مع كل خبير ومشارك ، لمناقشة القضايا ذات الاهتمام.محادثات Offtopic و وراء الكواليس
جزء خاص من انطباعاتي عن المؤتمر هو التواصل غير الرسمي مع المتحدثين والمشاركين. بفضل تنسيق المناقشات والعشاء والموائد المستديرة وحفلات الاستقبال ، يمكنك التعرف على أشخاص من جميع أنحاء العالم من شركات مختلفة وتبادل الخبرات. الكثير من التواصل داخل المؤتمر. الناس منفتحون للغاية ومستعدون لتبادل الخبرات.أود أيضًا أن أذكر ديبي شيتز. عملت ديبي في BMC وبدأت تحليل أدائها على أجهزة الكمبيوتر المركزية. ثم تحولت إلى الأنظمة الموزعة. تجربتها في المراقبة واسعة ومثيرة للاهتمام للغاية.لقد كنت محظوظًا أيضًا للدردشة مع أنوش نجاريان من MathWorks ، التي تستحق تجربتها أيضًا الانتباه.لسوء الحظ ، لا يسمح عدد التقارير بزيارتها جميعًا ، ولا يتم الاحتفاظ بالتقارير ، أي أنه لا توجد طريقة لمراجعتها في المنزل. يستخدم المنظمون المقالات لاختيار المتحدثين ، ثم يتم تمرير هذه المقالات إلى المشاركين في المؤتمر ، ولكن لا توجد مواد من المتحدثين المدعوين في المجموعة.هنا مقال Anush عن المؤتمر .تأثير CMG هو مؤتمر مفيد ومثير للاهتمام للغاية مع جو رائع لتبادل الخبرات ، والذي أوصي بحضوره.