جزء من سلسلة 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 TeamTechnical Writing
The ECOSIRE technical writing team covers Odoo ERP, Shopify eCommerce, AI agents, Power BI analytics, GoHighLevel automation, and enterprise software best practices. Our guides help businesses make informed technology decisions.
ECOSIRE
قم بتنمية أعمالك مع ECOSIRE
حلول المؤسسات عبر تخطيط موارد المؤسسات (ERP) والتجارة الإلكترونية والذكاء الاصطناعي والتحليلات والأتمتة.
مقالات ذات صلة
إجراءات GitHub CI/CD لمشاريع Monorepo
دليل GitHub Actions CI/CD الكامل لـ Turborepo monorepos: الإصدارات المتأثرة فقط، والوظائف الموازية، واستراتيجيات التخزين المؤقت، وعمليات النشر القائمة على البيئة، وأفضل الممارسات الأمنية.
اختبار التحميل k6: اختبار الضغط على واجهات برمجة التطبيقات الخاصة بك قبل الإطلاق
اختبار التحميل الرئيسي لـ k6 لواجهات برمجة تطبيقات Node.js. يغطي عمليات تكثيف المستخدم الافتراضي، والعتبات، والسيناريوهات، وHTTP/2، واختبار WebSocket، ولوحات معلومات Grafana، وأنماط تكامل CI.
ضبط أداء Odoo: تحسين PostgreSQL والخادم
دليل الخبراء لضبط أداء Odoo 19. يغطي تكوين PostgreSQL، والفهرسة، وتحسين الاستعلام، والتخزين المؤقت لـ Nginx، وحجم الخادم لعمليات النشر المؤسسية.
المزيد من Performance & Scalability
تصحيح أخطاء Webhook ومراقبتها: الدليل الكامل لاستكشاف الأخطاء وإصلاحها
أتقن تصحيح أخطاء خطاف الويب باستخدام هذا الدليل الكامل الذي يغطي أنماط الفشل وأدوات تصحيح الأخطاء وإستراتيجيات إعادة المحاولة ومراقبة لوحات المعلومات وأفضل ممارسات الأمان.
اختبار التحميل k6: اختبار الضغط على واجهات برمجة التطبيقات الخاصة بك قبل الإطلاق
اختبار التحميل الرئيسي لـ k6 لواجهات برمجة تطبيقات Node.js. يغطي عمليات تكثيف المستخدم الافتراضي، والعتبات، والسيناريوهات، وHTTP/2، واختبار WebSocket، ولوحات معلومات Grafana، وأنماط تكامل CI.
تكوين إنتاج Nginx: SSL والتخزين المؤقت والأمان
دليل تكوين إنتاج Nginx: إنهاء SSL، HTTP/2، رؤوس التخزين المؤقت، رؤوس الأمان، تحديد المعدل، إعداد الوكيل العكسي، وأنماط تكامل Cloudflare.
ضبط أداء Odoo: تحسين PostgreSQL والخادم
دليل الخبراء لضبط أداء Odoo 19. يغطي تكوين PostgreSQL، والفهرسة، وتحسين الاستعلام، والتخزين المؤقت لـ Nginx، وحجم الخادم لعمليات النشر المؤسسية.
Odoo vs Acumatica: Cloud ERP للشركات المتنامية
مقارنة بين Odoo وAcumatica لعام 2026: نماذج تسعير فريدة، وقابلية التوسع، وعمق التصنيع، وأي نظام تخطيط موارد المؤسسات (ERP) السحابي يناسب مسار النمو الخاص بك.
اختبار ومراقبة وكلاء الذكاء الاصطناعي في الإنتاج
دليل كامل لاختبار ومراقبة عوامل الذكاء الاصطناعي في بيئات الإنتاج. يغطي أطر التقييم، وإمكانية الملاحظة، والكشف عن الانجراف، والاستجابة للحوادث لعمليات نشر OpenClaw.