28 ديسمبر 2025·5 دقيقة
Claude Code لتحقيقات الأداء: سير عمل مقاس
استخدم Claude Code في تحقيقات الأداء بدورة قابلة للتكرار: قس، كوّن فرضية، غيّر قليلًا، وأعد القياس قبل النشر.
استخدم Claude Code في تحقيقات الأداء بدورة قابلة للتكرار: قس، كوّن فرضية، غيّر قليلًا، وأعد القياس قبل النشر.
أخطاء الأداء تدعو إلى التخمين. يلاحظ شخص ما أن صفحة تبدو بطيئة أو أن واجهة برمجة تطبيقات توقفت عن العمل، والحل السريع يكون "تنظيف" الشيفرة، إضافة كاش، أو إعادة كتابة حلقة. المشكلة أن "تبدو بطيئًا" ليس مقياسًا، و"أنظف" ليس هو نفسه أسرع.
بدون قياس، تضيع الفرق ساعات في تغيير الشيء الخاطئ. قد يكون المسار الحار في قاعدة البيانات، أو الشبكة، أو تخصيص غير متوقع واحد، بينما تُصقَل الشيفرة التي لم تكن المشكلة الحقيقية. والأسوأ، قد يجعل تغيير يبدو ذكيًا الأداء أسوأ: تسجيل إضافي داخل حلقة ضيقة، كاش يزيد ضغط الذاكرة، أو عمل متوازي يخلق تلاحم أقفال.
التخمين يعرض أيضًا السلوك للكسر. عندما تغيّر الشيفرة لتسريعها، قد تغيّر النتائج، أو معالجة الأخطاء، أو الترتيب، أو محاولات الإعادة. إن لم تعِد التحقق من الصواب والسرعة معًا، قد "تفوز" في معيار بينما تُرسِل خطأً بهدوء.
عامل الأداء كأنّه تجربة، لا مناظرة. الحلقة بسيطة وقابلة للتكرار:
العديد من النجاحات متواضعة: تقليم 8% من p95، تقليل ذروة الذاكرة بـ50 ميغابايت، أو حذف استعلام قاعدة بيانات واحد. تلك المكاسب مهمة، لكن فقط إذا كانت مقاسة، مؤكدة وقابلة للتكرار.
هذا يعمل بشكل أفضل كحلقة، لا كطلب وحيد "اجعله أسرع". الحلقة تحافظ على موضوعيتك لأن كل إجراء يرتبط بدليل ورقم يمكنك مراقبته.
تتبع واضح:
كل خطوة تحميك من نوع مختلف من الخداع الذاتي. القياس أولًا يمنعك من "إصلاح" شيء لم يكن مشكلة حقيقية. الافتراض المكتوب يمنعك من تغيير خمسة أشياء دفعة واحدة ثم التخمين أيها أثّر. التغييرات الصغيرة تقلل خطر كسر السلوك أو إضافة عنق زجاجة جديد. إعادة القياس تكشف الانتصارات الوهمية (مثل تشغيل أسرع بسبب كاش دافئ) وتكشف الانحدارات.
"الانتهاء" ليس شعورًا. إنه نتيجة: تحرّك المقياس الهدف في الاتجاه الصحيح، ولم يسبب التغيير انحدارات واضحة (أخطاء، زيادة الذاكرة، تفاقم p95، أو بطء نقاط نهاية مجاورة).
معرفة متى تتوقف جزء من سير العمل. توقف حين تتسطح المكاسب، أو المقياس جيد بما يكفي للمستخدمين، أو عندما تتطلب الفكرة التالية إعادة هيكلة كبيرة مقابل فائدة صغيرة. عمل الأداء دائمًا له تكلفة فرصة؛ تساعدك الحلقة على قضاء الوقت حيث يؤتي ثماره.
إذا قست خمسة أشياء دفعة واحدة فلن تعرف ما الذي تحسّن. اختر مقياسًا أساسيًا واحدًا لهذا التحقيق وعامل كل ما عدا ذلك كإشارات داعمة. للعديد من المشاكل المواجهة للمستخدم، ذلك المقياس هو زمن الاستجابة. لعمل الدفع قد يكون الإنتاجية، وقت CPU، استخدام الذاكرة، أو حتى تكلفة السحابة لكل تشغيل.
كن محددًا حول السيناريو. "API بطيء" غامض جدًا. "POST /checkout بعربة نموذجية من 3 عناصر" قابل للقياس. حافظ على ثبات المدخلات حتى تكون الأرقام ذات معنى.
اكتب خط الأساس وتفاصيل البيئة قبل أن تلمس الشيفرة: حجم مجموعة البيانات، نوع الآلة، وضع البناء، أعلام الميزات، التزامن، والإحماء. هذا الخط الأساس هو مرساتك. بدونه، كل تغيير يمكن أن يبدو تقدمًا.
بالنسبة للزمن، اعتمد على النسب المئوية وليس المتوسط فقط. p50 يظهر التجربة النموذجية، بينما p95 وp99 يكشفان ذيل الألم الذي يشتكي منه المستخدمون. تغيير يحسّن p50 لكنه يُسوء p99 قد يشعر المستخدم بأنه أبطأ.
قرّر مسبقًا ماذا يعني "مهم" حتى لا تحتفل بضوضاء:
بمجرد تحديد هذه القواعد، يمكنك اختبار الأفكار دون تحريك أهدافك.
ابدأ بأبسط إشارة يمكنك الوثوق بها. توقيت واحد حول طلب يمكن أن يخبرك ما إذا كانت هناك مشكلة حقيقية، وكم هي تقريبًا. احفظ البروفايل العميق عندما تحتاج إلى شرح سبب البطء.
عادةً ما تأتي الأدلة الجيدة من مزيج مصادر:
استخدم مقاييس بسيطة عندما يكون السؤال "هل هو أبطأ وبأي قدر؟" استخدم البروفايل عندما يكون السؤال "أين يذهب الوقت؟" إذا تضاعف p95 بعد نشر، ابدأ بالتوقيتات والسجلات لتأكيد الانحدار وتحديد النطاق. إذا أظهرت التوقيتات أن معظم التأخير داخل شيفرة التطبيق (وليس DB)، فإن بروفايلر CPU أو رسم شعلة يمكن أن يوجّهك إلى الدالة المحددة التي نمت.
حافظ على قياسات آمنة. اجمع ما تحتاجه لتصحيح الأداء، لا محتوى المستخدم. فضّل التجميعات (الزمن، العدّادات، الأحجام) على الحمولة الخام، واحجب المعرفات افتراضيًا.
الضوضاء حقيقية، لذلك خذ عينات متعددة ولاحظ القيم الشاذة. نفّذ نفس الطلب 10 إلى 30 مرة، وسجّل الوسيط وp95 بدلاً من تشغيل واحد "الأفضل".
اكتب وصفة الاختبار الدقيقة حتى تتمكن من تكرارها بعد التغييرات: البيئة، مجموعة البيانات، النقطة النهائية، حجم جسم الطلب، مستوى التزامن، وكيفية التقاط النتائج.
ابدأ بعَرَض يمكنك تسميته: "p95 ارتفع من 220 ملِّي ثانية إلى 900 ملِّي ثانية أثناء ذروة الحركة"، "CPU يصل إلى 95% على نواتين"، أو "الذاكرة تنمو 200 ميغابايت في الساعة." الأعراض الغامضة مثل "يبدو بطيئًا" تقود إلى تغييرات عشوائية.
بعد ذلك، ترجم ما قستَه إلى منطقة مشتبه بها. قد يُظهر رسم الشعلة أن معظم الوقت في ترميز JSON، قد تُظهر التتبعات مسار استدعاء بطيئًا، أو قد تُظهر إحصاءات DB استعلامًا واحدًا يهيمن على الوقت الكلي. اختر أصغر منطقة تشرح معظم التكلفة: دالة، استعلام SQL واحد، أو استدعاء خارجي واحد.
الافتراض الجيد جملة واحدة، قابل للاختبار، ومرتبط بتنبؤ. أنت تطلب مساعدة لاختبار فكرة، لا تطلب من أداة جعل كل شيء أسرع بطريقة سحرية.
استخدم هذا الشكل:
مثال: "لأن البروفايل يظهر 38% من CPU في SerializeResponse، إن تخصيص مخزن جديد لكل طلب يسبب ارتفاعات CPU. إذا أعدنا استخدام المخزن، يجب أن ينخفض p95 بحوالي 10–20% وCPU ينخفض بـ15% تحت نفس الحمل."
احفظ مصداقيتك بتسمية البدائل قبل أن تلمس الشيفرة. ربما الجزء البطيء هو اعتماد علوي، أو تلاحم أقفال، أو تغيير في معدل إصابة الكاش، أو نشر زاد حجم الحمولة.
اكتب 2 إلى 3 تفسيرات بديلة، ثم اختر التي تدعمها الأدلة أفضل. إذا لم يحرك التغيير المقياس، سيكون لديك الافتراض التالي جاهزًا.
يكون Claude مفيدًا في عمل الأداء عندما تعاملّه كمحلل حريص، لا كمنجم. اربط كل اقتراح بما قستَه، وتأكد أن كل خطوة قابلة للدحض.
قدّمه بمُدخلات حقيقية، لا وصف غامض. ألصق أدلة صغيرة ومركزة: ملخّص بروفايل، بعض أسطر السجل حول الطلب البطيء، خطة استعلام، ومسار الشيفرة المحدد. أدرج أرقام "قبل" (p95، وقت CPU، وقت DB) حتى يعرف خط أساسك.
اطلب منه تفسير ما تشير إليه البيانات وما لا تدعمه. ثم اجبره على طرح تفسيرات متنافسة. مطالبة مفيدة تنتهي بـ: "اعطني 2–3 افتراضات، ولكلٍ منها أخبرني ما الذي يدحضها." هذا يمنع التمسّك بالقصة الأولى المعقولة.
قبل تغيير أي شيء، اطلب أصغر تجربة يمكنها تأكيد الافتراض القيادي. اجعلها سريعة وقابلة للعكس: أضف مؤقتًا واحدًا حول دالة، فعل علم بروفايلر واحد، أو شغّل استعلام DB مع EXPLAIN.
إذا أردت هيكلًا صارمًا للمخرجات، اطلب:
إن لم يستطع تسمية مقياس محدد، موقع، ونتيجة متوقعة، فأنت تعود للتخمين.
بعد أن تملك أدلة وافتراضًا، قاوم الرغبة في "تنظيف كل شيء." عمل الأداء يكون أسهل للاعتماد عندما يكون تغيير الشيفرة صغيرًا وسهل التراجع.
غيّر شيئًا واحدًا في كل مرة. إن عدّلت استعلامًا وأضافت كاشًا وأعدت كتابة حلقة في نفس الالتزام، فلن تعرف ما الذي أفاد (أو أضر). التغييرات ذات المتغير الواحد تجعل القياس التالي ذو معنى.
قبل لمس الشيفرة، اكتب ما تتوقعه بالأرقام. مثال: "p95 يجب أن ينخفض من 420 ملِّي ثانية إلى أقل من 300 ملِّي ثانية، ووقت DB يجب أن يقل بحوالي 100 ملِّي ثانية." إن لم يصقّل النتيجة، تتعلّم سريعًا أن الافتراض كان ضعيفًا أو غير كامل.
اجعل التغييرات قابلة للعكس:
"صغير" لا يعني "تافه." يعني مركزًا: كاش لنتيجة دالة مكلفة واحدة، إزالة تخصيص متكرر في حلقة ضيقة، أو إيقاف عمل لا تحتاجه بعض الطلبات.
أضف توقيتًا خفيفًا حول عنق الزجاجة المشتبه بها حتى ترى ما تغيّر. طابع زمني واحد قبل وبعد استدعاء (مسجّلًا أو كمقياس) يمكن أن يؤكد أن التغيير استهدف الجزء البطيء أم أن الوقت انتقل لمكان آخر.
بعد التغيير، أعِد تشغيل نفس السيناريو المستخدم لخط الأساس: نفس المدخلات، البيئة، وشكل الحمل. إن كان الاختبار يعتمد على الكاش أو الإحماء، اجعل ذلك صريحًا (مثال: "التشغيل الأول بارد، الخمس التالية دافئة"). وإلّا ستجد تحسينات محض حظ.
قارن النتائج بنفس المقياس ونفس النسب المئوية. المتوسطات قد تخفي الألم، لذا راقب p95 وp99 بالإضافة إلى الإنتاجية ووقت CPU. شغّل تكرارات كافية لترى استقرار الأرقام.
قبل الاحتفال، تحقّق من الانحدارات التي لا تظهر في رقم واحد:
ثم قرّر بناءً على الأدلة، لا الأمل. إن كان التحسّن حقيقيًا ولم تُدخل انحدارات، ابقَ على التغيير. إن كانت النتائج مختلطة أو ضوضائية، ارجع التغيير وكون افتراضًا جديدًا، أو قلّص النطاق أكثر.
إذا كنت تعمل على منصة مثل Koder.ai، فإن أخذ لقطة قبل التجربة يمكن أن يجعل التراجع خطوة واحدة، مما يسهل تجربة أفكار جريئة بأمان.
وأخيرًا، اكتب ما تعلمته: خط الأساس، التغيير، الأرقام الجديدة، والاستنتاج. هذه السجلة القصيرة تمنع تكرار نفس المسارات الميتة في الجولة التالية.
عمل الأداء ينحرف عادة عندما تفقد الصلة بين ما قستَه وما غيّرتَه. حافظ على سلسلة أدلة نظيفة حتى تستطيع القول بثقة ما الذي جعل الأمور أفضل أو أسوأ.
المخالفون المتكرّرون:
مثال صغير: تبدو نقطة نهاية بطيئة، فتحسّن المُسلسل لأنه ساخن في بروفايل. ثم تعيد الاختبار بمجموعة بيانات أصغر فيبدو أسرع. في الإنتاج، p99 يتفاقم لأن DB لا تزال عنق الزجاجة وزيادة الحمولة الناتجة عن التغيير زادت حجم الحمولة.
ابدأ برقم واحد يتوافق مع الشكوى، عادةً p95 latency لنقطة نهاية وإدخال محددين. سجّل خط الأساس في نفس الظروف (حجم البيانات، التزامن، ذاكرة التخزين المؤقت باردة/دافئة)، ثم غيّر شيئًا واحدًا وأعد القياس.
إذا لم تتمكن من إعادة إنتاج خط الأساس، فأنت لم تبدأ القياس بعد — أنت تخمّن.
يشمل خط أساسي جيد ما يلي:
اكتبه قبل أن تلمس الشيفرة حتى لا تُحرّك معايير الهدف.
تُظهر النسب المئوية تجربة المستخدم أفضل من المتوسط. p50 هو "النمطية"، لكن المستخدمين يشتكون من الذيل البطيء، وهو p95/p99.
إذا تحسّن p50 بينما ساء p99، قد يشعر النظام بأنه أبطأ رغم أن المتوسط يبدو أفضل.
استخدم توقيتات بسيطة/سجلات عندما تسأل "هل هو أبطأ وبأي قدر؟" استخدم التحليل بواسطة البروفايلر عندما تسأل "إلى أين يذهب الوقت؟"
تدفق عملي: أكد الانحدار بتوقيتات الطلبات، ثم قم بالبروفايل فقط بعد أن تعرف أن التباطؤ حقيقي ومحدود.
اختر مقياسًا أساسيًا واحدًا، واجعل البقية حواجز حماية. مجموعة شائعة:
هذا يمنعك من "الفوز" في رسم بياني واحد بينما تتسبب بهدوء في نفاد المهلات أو زيادة الذاكرة أو تفاقم ذيل الاستجابة.
اكتب افتراضًا جيدا بجملة واحدة مرتبط بالأدلة وتنبؤ:
إذا لم تستطع تسمية الدليل والتحرّك المتوقع للمقياس، فالافتراض غير قابل للاختبار بعد.
اجعله صغيرًا، مركزًا، وقابلًا للعكس:
الاختلافات الصغيرة تجعل القياس التالي مفيدًا وتقلّل من احتمالية كسر السلوك أثناء المطاردة وراء السرعة.
أعد تشغيل نفس السيناريو الذي استخدمته لخط الأساس: نفس المدخلات، البيئة، وشكل الحمل. إذا كان الاختبار يعتمد على الكاشات أو الإحماء، فاجعل ذلك صريحًا (مثال: "التشغيل الأول بارد، الخمس التالية دافئة"). وإلّا ستجد تحسينات محض حظ.
قارن النتائج بنفس المقياس ونفس النسب المئوية. قبل الاحتفال، تحقّق من الانعكاسات:
إذا كانت النتائج ضوضائية، خذ عينات أكثر أو ارجع التغيير وشدّ التجربة.
ناولها بدليل مُحدّد واجبره على البقاء قائمًا على الاختبار:
إذا لم يتضمن الناتج مقياسًا محددًا وخطة لإعادة الاختبار، فأنت تعود إلى التخمين.
توقف عندما:
عمل الأداء له تكلفة فرصة. الحلقة (قياس → افتراض → تغيير → إعادة قياس) تساعدك على إنفاق الوقت حيث تُثبت الأرقام أنها مهمة.