בדיקת עומסים לאתרי מסחר אלקטרוני מבוססי 1C-Bitrix

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 }, // ramp-up
    { duration: '5m', target: 100 }, // plateau
    { duration: '2m', target: 300 }, // stress
    { duration: '5m', target: 300 }, // hold
    { duration: '2m', target: 0 }, // ramp-down
  ],
};

export default function () {
  // Главная → раздел → фильтрация → карточка товара
  let res = http.get('https://shop.example.com/catalog/electronics/');
  check(res, {
    'catalog 200': (r) => r.status === 200,
  });

  res = http.get('https://shop.example.com/catalog/electronics/?filter_brand=samsung&filter_price_from=10000');
  check(res, {
    'filter 200': (r) => r.status === 200,
  });

  res = http.get('https://shop.example.com/catalog/electronics/samsung-galaxy-s24/');
  check(res, {
    'product 200': (r) => r.status === 200,
  });

  sleep(Math.random() * 3 + 1); // пауза 1-4 сек, имитация реального пользователя
}

Apache JMeter הוא תקן מוכח; הוא דורש Java וצורך יותר RAM, כך שלעומסים גבוהים, ייתכן שיהיה צורך במספר מופעים. ממשק GUI ליצירת תרחישים, הקלטת פרוקסי, תומך בעוגיות ואימות. מתאים לצוותים הרגילים לכלים ויזואליים.

Gatling משתמש ב-Scala DSL, קלט/פלט לא חוסם, דוחות HTML מפורטים עם אחוזונים. יעיל יותר במשאבים מ-JMeter, אבל עם עקומת למידה תלולה יותר.

ארבעה תרחישים לבדיקה

בדיקת עומסים ללא תרחישים ריאליסטיים היא רק יצירת תנועה חסרת משמעות בדף הבית. עבור חנות Bitrix, הקריטיים הם:

• גלישה בקטלוג (60-70% מהתנועה): בית → קטגוריה → סינון → כרטיס מוצר. הסינון הוא החלק הכבד ביותר. רכיב bitrix:catalog.smart.filter מייצר 30-50 שאילתות SQL לכל כניסה.
• חיפוש (10-15% מהתנועה): מודול החיפוש משתמש באינדקסי FULLTEXT, שמתדרדרים באופן לא ליניארי על 100,000+ מוצרים.
• עגלת קניות (5-10% מהתנועה): כל פעולה (הוספה, קופון) מפעילה חישוב מחדש של הנחות דרך RuntimeCache, שלוקח 200-500 ms.
• תשלום (2-5% מהתנועה): התרחיש הקריטי ביותר — 50-100 שאילתות SQL ו-1-3 בקשות HTTP לשירותים חיצוניים.

איך לזהות צווארי בקבוק ב-Bitrix

בדיקת עומסים מראה מה איטי. פרופילינג מסביר למה. אנו מספקים flame graphs מ-xhprof כדי לאתר פונקציות חמות.

Xhprof / Tideways הם תוספי פרופילינג ל-PHP עם תקורה של 5-15%. הפעל אותם בייצור תחת עומס כדי ליצור גרף קריאות. ממצא טיפוסי: import http from 'k6/http'; import { check, sleep } from 'k6'; export const options = { stages: [ { duration: '2m', target: 100 }, // ramp-up { duration: '5m', target: 100 }, // plateau { duration: '2m', target: 300 }, // stress { duration: '5m', target: 300 }, // hold { duration: '2m', target: 0 }, // ramp-down ], }; export default function () { // Главная → раздел → фильтрация → карточка товара let res = http.get('https://shop.example.com/catalog/electronics/'); check(res, { 'catalog 200': (r) => r.status === 200 }); res = http.get('https://shop.example.com/catalog/electronics/?filter_brand=samsung&filter_price_from=10000'); check(res, { 'filter 200': (r) => r.status === 200 }); res = http.get('https://shop.example.com/catalog/electronics/samsung-galaxy-s24/'); check(res, { 'product 200': (r) => r.status === 200 }); sleep(Math.random() * 3 + 1); // пауза 1-4 сек, имитация реального пользователя } נקרא 47 פעמים בדף קטלוג יחיד.

יומן שאילתות איטיות הוא חובה במהלך הבדיקה. עבור MySQL: slow_query_log = 1, long_query_time = 0.3. ממצא טיפוסי — שאילתת סינון עם חמישה JOINs על טבלאות מאפיינים הסורקת 2.3 מיליון שורות ב-4.2 שניות.

צווארי בקבוק נפוצים ב-Bitrix

• רכיבים ללא מטמון: bitrix:catalog.section עם CACHE_TIME = 0 — כל כניסה מייצרת שאילתות בלוק מידע ומחירים. פתרון — מטמון מתויג (CACHE_TIME = 3600).
• מאפייני בלוק מידע מרובים: כל מאפיין מאוחסן כשורה נפרדת, סינון על שלושה מאפיינים מוסיף שלושה JOINs נוספים. אינדקס פאקטלי פותר זאת.
• ללא OPcache: בלעדיו, Bitrix מהדר אלפי קבצי PHP בכל בקשה. הגדר opcache.memory_consumption = 256, max_accelerated_files = 20000. עם OPcache, ביצוע PHP מהיר פי 3-5.
• סשנים מבוססי קבצים: עם 500+ משתמשים בו-זמנית, ext4 מאט. השתמש ב-Redis: session.save_handler = redis. שימוש ב-Redis במקום סשנים מבוססי קבצים משפר את ביצועי ניהול הסשנים פי 5.
• סוכנים על כניסות: הגדר BX_CRONTAB_SUPPORT = true והעבר סוכנים ל-cron.

מדדים מרכזיים

• RPS — בקשות בשנייה ללא התדרדרות (לחנות ממוצעת: 100-300).
• TTFB — עד 200 ms לדפים במטמון, עד 500 ms לדפים דינמיים.
• זמן תגובה P95 — זמן עבור 95% מהבקשות. אם P95 > 4 שניות, אחד מעשרים מבקרים ממתין יותר מדי.
• שיעור שגיאות — אחוז של 5xx ו-timeouts. הוא עולה בחדות כשהקיבולת נחצית.

מה לעשות עם התוצאות

מתי לבדוק

בדיקת עומסים אינה משימה חד-פעמית. הפעל אותה לפני מבצעים (Black Friday, 11.11), אחרי העברת שרתים, אחרי עדכון ליבת Bitrix, אחרי ייבוא מוצרים המוני. k6 ב-CI/CD מאפשר בדיקת עשן בסיסית בכל פריסה.

איך לבצע בדיקת עומסים ב-5 שלבים

1. אסוף פרופיל עומסים: תרחישים טיפוסיים, תדירות בקשות, תנועת שיא.
2. הגדר סביבה: סביבת staging עם ניטור ופרופילינג מופעלים.
3. פתח תרחישים: סקריפטים של k6 המדמים קטלוג, חיפוש, תשלום.
4. בצע ונטר: הגדל עומס בהדרגה, רשום RPS, TTFB, P95, שיעור שגיאות.
5. נתח ובצע אופטימיזציה: בדוק יומן שאילתות איטיות, פרופילר, יישם שינויים, ובדוק שוב.

מה כלול בעבודה שלנו

אנו מספקים שירות בדיקת עומסים מלא הנתמך בניסיון של למעלה מ-10 שנים והסמכת 1C-Bitrix. אנו מבטיחים דוח מקיף עם המלצות מעשיות:

• ניתוח ארכיטקטורת החנות ופרופיל העומסים שלך.
• פיתוח תרחישים ריאליסטיים (קטלוג, חיפוש, עגלה, תשלום).
• ביצוע בדיקות על staging או ייצור (באישורך).
• איסוף מדדים ופרופילינג (xhprof, שאילתות איטיות, OPcache).
• דוח מפורט עם מדדים, צווארי בקבוק והמלצות.
• תוכנית אופטימיזציה עם הערכות מאמץ.
• ייעוץ מהנדס על התוצאות.

צור קשר לייעוץ — נבחן את הפרויקט שלך תוך 1-2 ימים. הזמן בדיקות לפני מבצעים כדי למנוע אובדן הכנסות.