أداء الحوسبة والتخزين

معظم شكاوى الأداء على AWS ليست أعطالاً. هي حدود بُلغت بصمت: خادم يعمل عند خط أساس لا عند سقفه المعلن، وحجم استنفد أرصدة اندفاعه، وحاوية S3 تُخنق لأن كل الكتابات تهبط في بادئة واحدة. ويعلّمك هذا الموضوع أن تسمّي الحد قبل أن تغيّر شيئاً، وهي المهارة التي تفصل التشخيص عن التخمين في المهارتين 1.3.1 و1.3.2 و1.3.3 و1.3.4 و1.3.6 من اختبار SOA-C03.

ما الذي يغطيه هذا الموضوع

• تحديد الحجم المناسب لخوادم EC2 عبر Compute Optimizer: تصنيفات النتائج وأسبابها ومخاطرة الأداء، ولماذا لا تُرى الذاكرة بلا وكيل CloudWatch، ونموذج أرصدة عائلة T
• أداء شبكة EC2: حد التدفق الواحد مقابل النطاق الإجمالي، وأرصدة إدخال/إخراج الشبكة، وعدّادات ENA التي تكشف الخنق الذي تخفيه CloudWatch، وenhanced networking وENA Express وEFA
• مجموعات التموضع cluster وpartition وspread بحدودها الصارمة، والحالة التي تناسب كلاً منها
• أداء EBS: العلاقة بين IOPS والإنتاجية وحجم عملية الإدخال/الإخراج، وأنواع الأحجام الستة، ونموذج أرصدة gp2، والتمييز بين خنق الحجم وخنق الخادم، وتعديل الأحجام عبر Elastic Volumes
• أداء S3 ونقل البيانات: معدّلات الطلبات لكل بادئة واستجابات 503، والرفع متعدد الأجزاء، وجلب النطاقات البايتية، وTransfer Acceleration وDataSync وأجهزة Snow، ودورة حياة فئات التخزين
• التخزين المشترك: أوضاع أداء EFS وإنتاجيته وسياسات دورة حياته، وأنظمة FSx الأربعة، وMountpoint for Amazon S3

لماذا هذا مهم

تُصاغ أسئلة الأداء في هذا الاختبار على شكل أعراض لا على شكل تعريفات: خادم بسعة 25 جيجابت ينقل 5 فقط، ومهمة ليلية تنهار بعد 33 دقيقة بالضبط، وتطبيق يفقد حزماً بينما منحنيات الشبكة مستوية. والإجابة في كل حالة هي معرفة أي حد بُلغ، وأي مقياس يثبته، وأي إصلاح يخصّ ذلك الحد بعينه. وأشيع خطأ هو إصلاح الطبقة الخاطئة: تزويد مزيد من IOPS بينما الخادم هو المخنوق، أو تفعيل Transfer Acceleration بينما المشكلة معدّل طلبات لا مسافة.

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