جزء من سلسلة Performance & Scalability
اقرأ الدليل الكاملتحميل استراتيجيات الاختبار لتطبيقات الويب: ابحث عن نقاط التوقف قبل أن يقوم المستخدمون بذلك
يتم اكتشاف 80% من مشكلات الأداء بواسطة المستخدمين النهائيين، وليس عن طريق الاختبار. يعمل اختبار التحميل على قلب هذه النسبة عن طريق محاكاة أنماط حركة المرور في العالم الحقيقي مع تطبيقك قبل أن يواجه المستخدمون مشكلات. الفرق بين الموقع الذي يتعامل مع حركة مرور الجمعة السوداء والموقع الذي يتعطل هو دائمًا ما إذا كان شخص ما قد أجرى اختبار التحميل أولاً.
يغطي هذا الدليل منهجية اختبار التحميل واختيار الأدوات وتصميم الاختبار وتفسير النتائج لتطبيقات الويب ومنصات التجارة الإلكترونية وأنظمة تخطيط موارد المؤسسات (ERP).
الوجبات الرئيسية
- يجب أن يحاكي اختبار التحميل سلوك المستخدم الواقعي، وليس مجرد الوصول إلى نقطة نهاية واحدة
- ضع خطوط أساس للأداء قبل التحسين --- لا يمكنك تحسين ما لم تقم بقياسه
- إجراء اختبارات الحمل في بيئة شبيهة بالإنتاج؛ قد لا تعكس نتائج التدريج سلوك الإنتاج
- أتمتة اختبارات التحميل في CI/CD لرصد تراجعات الأداء قبل النشر
أنواع اختبارات الحمل
| نوع الاختبار | الغرض | المدة | نمط التحميل |
|---|---|---|---|
| اختبار الدخان | التحقق من الوظائف الأساسية تحت الحد الأدنى من التحميل | 1-2 دقيقة | 1-5 مستخدمين |
| اختبار التحميل | التحقق من صحة الأداء في ظل حركة المرور المتوقعة | 10-30 دقيقة | حركة مرور عادية |
| اختبار الإجهاد | أوجد نقطة الانهيار | 15-30 دقيقة | زيادة تدريجية |
| اختبار سبايك | اختبار الزيادات المفاجئة في حركة المرور | 5-10 دقائق | قفزة مفاجئة |
| اختبار النقع | كشف تسرب الذاكرة وتدهورها | 2-8 ساعات | الحمل الطبيعي المستدام |
اختبار التحميل باستخدام k6
اختبار الحمل الأساسي
// k6/load-test.js
import http from 'k6/http';
import { check, sleep } from 'k6';
export const options = {
stages: [
{ duration: '2m', target: 50 }, // Ramp up to 50 users
{ duration: '5m', target: 50 }, // Stay at 50 users
{ duration: '2m', target: 100 }, // Ramp up to 100 users
{ duration: '5m', target: 100 }, // Stay at 100 users
{ duration: '2m', target: 0 }, // Ramp down
],
thresholds: {
http_req_duration: ['p(95)<500', 'p(99)<1000'],
http_req_failed: ['rate<0.01'],
http_reqs: ['rate>100'],
},
};
export default function () {
// Simulate realistic user behavior
const homeResponse = http.get('https://example.com/');
check(homeResponse, {
'homepage status is 200': (r) => r.status === 200,
'homepage loads in under 1s': (r) => r.timings.duration < 1000,
});
sleep(Math.random() * 3 + 1); // 1-4 seconds think time
const productsResponse = http.get('https://example.com/api/v1/products');
check(productsResponse, {
'products API is 200': (r) => r.status === 200,
'products API under 500ms': (r) => r.timings.duration < 500,
});
sleep(Math.random() * 2 + 1);
}
اختبار رحلة مستخدم التجارة الإلكترونية
// k6/ecommerce-journey.js
import http from 'k6/http';
import { check, group, sleep } from 'k6';
export const options = {
scenarios: {
browsing: {
executor: 'ramping-vus',
startVUs: 0,
stages: [
{ duration: '5m', target: 200 },
{ duration: '10m', target: 200 },
{ duration: '5m', target: 0 },
],
exec: 'browsingScenario',
},
purchasing: {
executor: 'ramping-vus',
startVUs: 0,
stages: [
{ duration: '5m', target: 20 },
{ duration: '10m', target: 20 },
{ duration: '5m', target: 0 },
],
exec: 'purchaseScenario',
},
},
thresholds: {
'http_req_duration{scenario:browsing}': ['p(95)<800'],
'http_req_duration{scenario:purchasing}': ['p(95)<2000'],
http_req_failed: ['rate<0.01'],
},
};
export function browsingScenario() {
group('Browse Products', () => {
http.get('https://store.example.com/');
sleep(2);
http.get('https://store.example.com/products');
sleep(3);
http.get('https://store.example.com/products/sample-product');
sleep(2);
});
}
export function purchaseScenario() {
group('Purchase Flow', () => {
// Browse
http.get('https://store.example.com/products/sample-product');
sleep(1);
// Add to cart
http.post('https://store.example.com/api/cart', JSON.stringify({
productId: 'prod_123',
quantity: 1,
}), { headers: { 'Content-Type': 'application/json' } });
sleep(2);
// Checkout
http.get('https://store.example.com/cart');
sleep(3);
// Place order (simulated)
const orderResponse = http.post('https://store.example.com/api/checkout/validate', JSON.stringify({
email: `test-${__VU}@example.com`,
}), { headers: { 'Content-Type': 'application/json' } });
check(orderResponse, {
'checkout validates': (r) => r.status === 200 || r.status === 201,
});
sleep(1);
});
}
اختبار الإجهاد (العثور على نقطة الانهيار)
// k6/stress-test.js
import http from 'k6/http';
import { check } from 'k6';
export const options = {
stages: [
{ duration: '2m', target: 100 },
{ duration: '5m', target: 100 },
{ duration: '2m', target: 200 },
{ duration: '5m', target: 200 },
{ duration: '2m', target: 500 },
{ duration: '5m', target: 500 },
{ duration: '2m', target: 1000 },
{ duration: '5m', target: 1000 },
{ duration: '5m', target: 0 },
],
};
export default function () {
const res = http.get('https://example.com/api/v1/products');
check(res, {
'status is 200': (r) => r.status === 200,
});
}
تفسير النتائج
المقاييس الرئيسية
| متري | صحي | تحذير | حرجة |
|---|---|---|---|
| زمن الاستجابة P95 | <500 مللي ثانية | 500 مللي ثانية -2 ثانية | > 2 ث |
| زمن الاستجابة P99 | <1س | 1-5 ث | >5ث |
| معدل الخطأ | <0.1% | 0.1-1% | >1% |
| الإنتاجية | يلبي الهدف | 80% من الهدف | <80% من الهدف |
أنماط عنق الزجاجة الشائعة
عنق الزجاجة المرتبط بوحدة المعالجة المركزية: يزداد وقت الاستجابة خطيًا مع التحميل. يتباعد P95 وP99 ببطء.
- الإصلاح: تحسين مسارات التعليمات البرمجية الساخنة، أو إضافة سعة وحدة المعالجة المركزية، أو التوسع أفقيًا
عنق الزجاجة في قاعدة البيانات: يزداد وقت الاستجابة بشكل كبير عند حد تحميل محدد. استنفاد تجمع الاتصال.
- الإصلاح: تحسين الاستعلام، وتجميع الاتصالات، وقراءة النسخ المتماثلة (راجع دليل قياس قاعدة البيانات)
عنق الزجاجة في الذاكرة: التدهور التدريجي بمرور الوقت. يتسبب توقف GC مؤقتًا في حدوث طفرات في زمن الوصول.
- الإصلاح: زيادة الذاكرة، وإصلاح تسرب الذاكرة، وتحسين تخصيص الكائنات
عنق الزجاجة في الشبكة: يزداد وقت الاستجابة بشكل موحد عبر جميع نقاط النهاية. تشبع عرض النطاق الترددي.
- الإصلاح: CDN للأصول الثابتة، والضغط، وتقليل أحجام الحمولة
خطوط الأساس للأداء
إنشاء خط الأساس
قبل التحسين، قم بتوثيق أدائك الحالي:
# Run baseline test
k6 run --out json=baseline-results.json k6/load-test.js
# Compare after optimization
k6 run --out json=optimized-results.json k6/load-test.js
ميزانية الأداء
تحديد الأداء المقبول لكل نقطة نهاية:
| نقطة النهاية | هدف P95 | هدف الإنتاجية |
|---|---|---|
| الصفحة الرئيسية | 500 مللي ثانية | 200 طلب/ثانية |
| قائمة المنتجات | 800 مللي ثانية | 150 طلب/ثانية |
| تفاصيل المنتج | 600 مللي ثانية | 200 طلب/ثانية |
| أضف إلى السلة | 300 مللي ثانية | 100 طلب/ثانية |
| الخروج | 2000 مللي ثانية | 50 طلب/ثانية |
| بحث | 500 مللي ثانية | 100 طلب/ثانية |
| لوحة تحكم المشرف | 1500 مللي ثانية | 20 طلب/ثانية |
تكامل CI/CD
اختبار انحدار الأداء الآلي
# .github/workflows/performance.yml
name: Performance Test
on:
push:
branches: [main]
jobs:
load-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run k6 load test
uses: grafana/[email protected]
with:
filename: k6/load-test.js
flags: --out json=results.json
env:
K6_TARGET_URL: ${{ secrets.STAGING_URL }}
- name: Check thresholds
run: |
if grep -q '"thresholds":{".*":"fail"' results.json; then
echo "Performance thresholds exceeded!"
exit 1
fi
قائمة التحقق من اختبار التحميل
قبل الاختبار
- البيئة تطابق الإنتاج (أنواع المثيلات وحجم قاعدة البيانات)
- بيانات الاختبار تمثيلية (عدد المنتجات الواقعي، عدد المستخدمين)
- المراقبة نشطة (تتبع مقاييس الخادم أثناء الاختبار)
- يتم إخطار أصحاب المصلحة (يمكن أن تؤدي اختبارات التحميل إلى إطلاق التنبيهات)
- يتم تكوين CDN والتخزين المؤقت كما هو الحال في الإنتاج
أثناء الاختبار
- مراقبة وحدة المعالجة المركزية للخادم والذاكرة وإدخال / إخراج القرص
- مراقبة اتصالات قاعدة البيانات وزمن وصول الاستعلام
- راقب زيادة معدل الخطأ
- التحقق من استنفاد الموارد (واصفات الملفات، الاتصالات)
- لاحظ مستوى التحميل الذي يتراجع فيه الأداء
بعد الاختبار
- توثيق النتائج الأساسية
- تحديد الاختناقات وحدود التحميل الخاصة بها
- إنشاء تذاكر لتحسين الأداء
- المقارنة بميزانية الأداء
- جدولة اختبار المتابعة بعد التحسينات
الأسئلة المتداولة
هل يجب علينا تحميل اختبار الإنتاج أو التدريج؟
كلاهما إن أمكن. التدريج للاختبار المنتظم وتكامل CI/CD. الإنتاج للتحقق الدوري (خلال ساعات حركة المرور المنخفضة) لأن التدريج غالبًا ما يختلف في حجم قاعدة البيانات، ودفء ذاكرة التخزين المؤقت، وتكوين CDN، وطوبولوجيا الشبكة. إذا كان بإمكانك اختبار بيئة واحدة فقط، فاختبر التدريج ولكن اجعلها شبيهة بالإنتاج قدر الإمكان.
كم مرة يجب علينا إجراء اختبارات التحميل؟
اختبارات الدخان في كل عملية نشر (آلية في CI/CD). اختبارات التحميل الكامل أسبوعيًا أو قبل الإصدارات الرئيسية. اختبارات التحمل ربع سنوية أو قبل الأحداث المعروفة ذات الحركة المرورية العالية (المبيعات، الإطلاقات). يتم إجراء اختبارات النقع كل ثلاثة أشهر للكشف عن تسرب الذاكرة وتدهورها على المدى الطويل.
كيف نقوم بتحميل اختبار نظام تخطيط موارد المؤسسات (ERP)؟
يتطلب اختبار تحميل تخطيط موارد المؤسسات (ERP) محاكاة المستخدمين المتزامنين الذين يقومون بمهام مختلفة: إنشاء الفواتير، وإنشاء أوامر الشراء، وتشغيل التقارير، واستيراد البيانات. التركيز على العمليات الأثقل (إنشاء التقارير، واستيراد البيانات) والعمليات الأكثر تزامنًا (إدخال الطلب خلال ساعات الذروة). توفر ECOSIRE اختبار أداء Odoo كجزء من خدمات الدعم لدينا.
ما هو وقت التفكير الواقعي بين الطلبات؟
لتصفح التجارة الإلكترونية: 2-5 ثواني. لملء النموذج: 10-30 ثانية. للخروج: 15-60 ثانية. لاستخدام الإدارة/تخطيط موارد المؤسسات (ERP): 5-15 ثانية. قم دائمًا بإضافة وقت تفكير عشوائي إلى اختبارات التحميل الخاصة بك --- تؤدي الفواصل الزمنية الثابتة إلى إنشاء أنماط تحميل متزامنة غير واقعية.
ما يأتي بعد ذلك
يكشف اختبار التحميل عن الاختناقات التي توجه جهود التحسين الخاصة بك. تابع باستخدام قياس قاعدة البيانات لاختناقات قاعدة البيانات، وتحسين CDN لتسليم الأصول الثابتة، والقياس التلقائي للسعة المرنة.
اتصل بـ ECOSIRE لاختبار الأداء وتحسينه، أو استكشف دليل DevOps للتعرف على إستراتيجية البنية التحتية الكاملة.
تم النشر بواسطة ECOSIRE - لمساعدة الشركات على إنشاء تطبيقات تعمل تحت الضغط.
بقلم
ECOSIRE Research and Development Team
بناء منتجات رقمية بمستوى المؤسسات في ECOSIRE. مشاركة رؤى حول تكاملات Odoo وأتمتة التجارة الإلكترونية وحلول الأعمال المدعومة بالذكاء الاصطناعي.
مقالات ذات صلة
تحسين أداء وكيل الذكاء الاصطناعي: السرعة والدقة وكفاءة التكلفة
قم بتحسين أداء وكيل الذكاء الاصطناعي عبر وقت الاستجابة والدقة والتكلفة باستخدام تقنيات مثبتة للهندسة السريعة والتخزين المؤقت واختيار النموذج والمراقبة.
أنماط بوابة API وأفضل الممارسات للتطبيقات الحديثة
قم بتنفيذ أنماط بوابة واجهة برمجة التطبيقات (API) بما في ذلك تحديد المعدل والمصادقة وتوجيه الطلب وقواطع الدائرة وإصدار واجهة برمجة التطبيقات (API) لبنيات الويب القابلة للتطوير.
تحسين أداء CDN: الدليل الكامل للتسليم العالمي الأسرع
قم بتحسين أداء CDN من خلال إستراتيجيات التخزين المؤقت وحوسبة الحافة وتحسين الصورة وبنيات CDN المتعددة لتوصيل المحتوى العالمي بشكل أسرع.
المزيد من Performance & Scalability
تحسين أداء وكيل الذكاء الاصطناعي: السرعة والدقة وكفاءة التكلفة
قم بتحسين أداء وكيل الذكاء الاصطناعي عبر وقت الاستجابة والدقة والتكلفة باستخدام تقنيات مثبتة للهندسة السريعة والتخزين المؤقت واختيار النموذج والمراقبة.
اختبار ومراقبة وكلاء الذكاء الاصطناعي: هندسة الموثوقية للأنظمة المستقلة
الدليل الكامل لاختبار ومراقبة عوامل الذكاء الاصطناعي التي تغطي اختبار الوحدة، واختبار التكامل، والاختبار السلوكي، وقابلية الملاحظة، واستراتيجيات مراقبة الإنتاج.
تحسين أداء CDN: الدليل الكامل للتسليم العالمي الأسرع
قم بتحسين أداء CDN من خلال إستراتيجيات التخزين المؤقت وحوسبة الحافة وتحسين الصورة وبنيات CDN المتعددة لتوصيل المحتوى العالمي بشكل أسرع.
تحسين محركات البحث للجوال للتجارة الإلكترونية: دليل التحسين الكامل لعام 2026
دليل SEO للجوال لمواقع التجارة الإلكترونية. يغطي فهرسة الهاتف المحمول أولاً، ومؤشرات أداء الويب الأساسية، والبيانات المنظمة، وتحسين سرعة الصفحة، وعوامل تصنيف بحث الهاتف المحمول.
مراقبة الإنتاج والتنبيه: دليل الإعداد الكامل
قم بإعداد مراقبة الإنتاج والتنبيه باستخدام Prometheus وGrafana وSentry. يغطي المقاييس والسجلات والتتبعات وسياسات التنبيه وسير عمل الاستجابة للحوادث.
أداء واجهة برمجة التطبيقات: تحديد المعدل، وترقيم الصفحات، والمعالجة غير المتزامنة
أنشئ واجهات برمجة تطبيقات عالية الأداء باستخدام خوارزميات تحديد المعدل والترقيم المستند إلى المؤشر وقوائم انتظار المهام غير المتزامنة وأفضل ممارسات ضغط الاستجابة.