performance-engineer
تحسين أداء التطبيق والمراقبة
تؤدي التطبيقات البطيئة إلى فقدان المستخدمين والإيرادات. توفر هذه المهارة إرشادات متخصصة حول profilig والمراقبة وتحسين الأداء عبر gesamte Stack.
تنزيل ZIP المهارة
رفع في Claude
اذهب إلى Settings → Capabilities → Skills → Upload skill
فعّل وابدأ الاستخدام
اختبرها
استخدام "performance-engineer". تطبيق React الخاص بنا يحمل الصفحات ببطء. LCP هو 4.2 ثانية. ساعد في تحديد المشكلات.
النتيجة المتوقعة:
- الأسباب المحتملة: الصور غير المحسنة، موارد حظر العرض، استجابات API بطيئة
- الإجراءات الفورية: تنفيذ التحميل الكسول، إضافة ضغط الصور، تمكين HTTP/2
- قياس الأثر: استهداف LCP أقل من 2.5 ثانية، المراقبة باستخدام أدوات RUM
استخدام "performance-engineer". زاد زمن استجابة API من 50 مللي ثانية إلى 500 مللي ثانية بعد النشر. استعلامات قاعدة البيانات بدون تغيير.
النتيجة المتوقعة:
- التحقق: استنزاف مجموعة الاتصالات، زيادة جمع البيانات المهملة، تكوين الشبكة
- مقارنة فرق النشر: تحديثات التكوين، تغييرات تكوين حدود الموارد
- المرشح للتراجع: إذا تم العثور على ارتباط مع commit معين، إعداد خطة التراجع
التدقيق الأمني
آمنStatic analysis flagged 4 patterns that were all determined to be false positives. The skill is a text-based AI prompt for performance engineering guidance with no executable code, network calls, or command execution capabilities. All flagged patterns were matches on unrelated text (frontmatter description, load testing references). The skill includes responsible safety guidelines for production load testing.
درجة الجودة
ماذا يمكنك بناءه
تحسين منصة التجارة الإلكترونية
تحسين أوقات تحميل الصفحة وأداء الخروج لمتجر إلكتروني عالي الحركة خلال مواسم الذروة.
إعداد مراقبة الخدمات المصغرة
تنفيذ تتبع موزع شامل ومراقبة عبر بنية الخدمات المصغرة المُحزّنة.
ضبط أداء واجهة برمجة التطبيقات
تقليل زمن الاستجابة وزيادة الإنتاجية لواجهات برمجة التطبيقات REST و GraphQL التي تخدم العملاء mobiles والويب.
جرّب هذه الموجهات
راجع بنية التطبيق وحدد أهم 3 اختناقات للأداء. Stack الحالي: [describe your tech stack]. الشكاوى الرئيسية: [describe issues]. الأولوية: [speed/cost/reliability].
إنشاء استراتيجية اختبار الحمل لـ [service name] تتعامل مع [requests per second] مع [current users]. تضمين معايير النجاح وتوصيات السيناريوهات والأدوات. البنية التحتية الحالية: [describe setup].
تصميم stack المراقبة لـ [microservices/monolith] باستخدام [preferred tools if any].我们需要 تتبع [specific metrics] والتنبيه على [conditions]. حجم الفريق: [number]. مزود السحابة: [AWS/GCP/Azure].
تحليل هذا الحادث في الأداء: [describe symptoms, timeline, affected services]. البيانات المتاحة: [logs, metrics, traces]. المساعدة في تحديد السبب الجذري والتوصية بالإصلاحات الفورية plus الوقاية طويلة المدى.
أفضل الممارسات
- قم دائمًا بإنشاء أسس للأداء قبل إجراء التغييرات لقياس الأثر الفعلي
- ركز جهود التحسين على المقاييس التي تؤثر مباشرة على تجربة المستخدم وأهداف العمل
- تنفيذ ميزانيات الأداء في خطوط CI/CD لاكتشاف الانحدارات قبل النشر في الإنتاج
تجنب
- التحسين بدون قياس يؤدي إلى الجهد المهدور على عدم الاختناقات
- اختبار الحمل في الإنتاج بدون موافقات وحماية يعرض الخدمة لخطر الانقطاعات
- إضافة التخزين المؤيد بدون استراتيجية إبطال يسبب بيانات قديمة ومشكلات التناسق
الأسئلة المتكررة
ما الوصول الذي يجب أن أقدمه لتحليل الأداء؟
هل يمكن لهذه المهارة تشغيل اختبارات الحمل تلقائيًا؟
كيف أقيس ما إذا كانت تحسينات الأداء تعمل؟
هل هذه المهارة مناسبة لتحسين أداء تطبيقات الجوال؟
ماذا لو كانت تقنيات تطبيقي غير مذكورة في القدرات؟
هل يمكن أن يساعد هذا في تحسين تكلفة السحابة المتعلقة بالأداء؟
تفاصيل المطور
المؤلف
sickn33الترخيص
MIT
المستودع
https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/performance-engineerمرجع
main
بنية الملفات
📄 SKILL.md