בדיקות עומס ב-Bitrix: היכן האתר נשבר
בדיקות עומס ב-Bitrix מתחילות לא בהפעלת מחולל תעבורה, אלא במענה לשאלה: איזה תרחיש בדיוק אנחנו שוברים. בחנות מקוונת על «Bitrix» צווארי הבקבוק נמצאים כמעט תמיד בארבעה מקומות — מטמון, חיפוש, סל קניות וסנכרון עם 1С. כל עוד האתר עובד עם עשרה מבקרים בו-זמנית, כל הארבעה נראים בריאים. בעומס שיא — מבצע מכירות, השקת קמפיין, תעבורת ערב — הם מתגלים בו-זמנית ומגבירים זה את זה.
המטמון מתדרדר ראשון. רכיבים עם CACHE_TYPE => A וזמן חיים אגרסיבי מחזירים מחירים ומלאי מיושנים, ובאיפוס מטמון לפי אירוע (שינוי מוצר, ייבוא מ-1С) מאות בקשות יוצאות בו-זמנית למסד הנתונים — פסק זמן של חיבור, מסך לבן במקום קטלוג.
מטמון כפוי בקבצים על תת-מערכת דיסקים משותפת מוסיף נעילות קריאה-כתיבה, וזמן התגובה גדל באופן לא ליניארי: כאשר מספר המבקרים מוכפל, זמן התגובה עשוי לגדול פי שלושה.
החיפוש — צוואר הבקבוק השני. החיפוש הסטנדרטי לפי אינדקס בקטלוגים גדולים מבצע שליפות כבדות, ומורפולוגיה והשלמות מוסיפות שאילתות על כל הקשה במקלדת. בעומס שיא שאילתות החיפוש אוכלות את החיבורים למסד הנתונים, וכבר לא מגיע התור לכרטיס המוצר.
הסל והשלמת ההזמנה מחזיקים את הסשן והטרנזקציות. בהוספה המונית של מוצרים לסל גדלות הנעילות על טבלאות ההזמנות, והאינטגרציה עם 1С באמצעות סנכרון לפי לוח זמנים מפעילה ייצוא כבד בדיוק ברגע שבו מתרחש שיא המכירות. הסנכרון והחזית מתחילים להתחרות על אותם משאבים — הזמנות הולכות לאיבוד, סטטוסים לא מסתנכרנים.
בדיוק משום כך אנחנו בונים בדיקות עומס ב-Bitrix כחיפוש אחר צווארי בקבוק, ולא כדוח על «עמד ב-N בקשות בשנייה». תחילה מסירים פרופיל של תעבורה אמיתית, לאחר מכן משחזרים תרחיש שיא ובודקים מה מתדרדר ראשון — מטמון, חיפוש, סל או סנכרון. בהמשך מנתחים כיצד זה נסגר.
מה נותן הבדיקה: תוצאות מדידות
בדיקות עומס ל-Битрикс מעבירות את השיחה על ביצועים מתחום התחושות לתחום המספרים. לפני ההרצות יש לצוות תלונות («נתקע בצהריים», «הסל קורס במבצע»), ואחריהן — פרופיל עומס: כמה בקשות בשנייה מחזיק הקטלוג, באיזו מקביליות מתחיל לגדול זמן התגובה, והיכן בדיוק נתקע ה-worker. מאותו רגע ההחלטות מתקבלות לפי המספרים האלה, ולא לפי אינטואיציה.
תפוקה וזמן תגובה נמדדים בנפרד, משום שהם מתנהגים באופן שונה. המערכת יכולה לקלוט זרם בקשות ביציבות ובמקביל להחזיר עמוד קטלוג תוך שניות — עבור המבקר זה כשל, למרות שמונה הבקשות נראה תקין. ההרצה מראה את נקודת המפנה: עד אליה התגובה נשמרת בטווח היעד, אחריה — גדלה באופן לא ליניארי. את הגבול הזה מגנים באמצעות מטמון, אינדקסים והעברת פעולות כבדות החוצה.
עמידות בפני כשלים נבדקת בנפרד מעומס שיא. התרחיש מוציא צומת אחד מהקבוצה — מסד נתונים, חיפוש, תור — ובוחן אם המערכת מתדרדרת בהדרגה או קורסת כולה. לעתים קרובות מתברר שעמידות בפני כשלים מוצהרת בקונפיגורציה, אך לא נבדקה: המעבר לא מתבצע, סשנים הולכים לאיבוד, משימות רקע משוכפלות. הרצות כאלה זולות מאירוע בתצורת הפרודקשן.
אפקט נפרד — צפיות של שחרורים. כשיש פרופיל עומס בסיסי, כל שיפור מורץ מולו, ורגרסיה בזמן התגובה נראית עוד לפני העלאה לפרודקשן. הצוות מקבל לא דוח חד-פעמי, אלא רף מדיד ש-Bשחרור לא עובר מתחתיו.
גישות להרצות עומס: השוואה
ניתן לארגן הרצת עומס בארבע דרכים שונות מהותית, והבחירה ביניהן נקבעת לא לפי התקציב, אלא לפי אילו צווארי בקבוק אתם רוצים לראות. הרצה ידנית על ידי צוות עם מספר דפדפנים נותנת משוב מהיר על היענות הממשק, אך אינה משחזרת את פרופיל הסשנים האמיתיים: משתמשים מאומתים, סל קניות, סנכרון עם 1С.
הרצה מבוססת סקריפט על Bitrix באמצעות מנגנון מובנה או מחולל חיצוני נותנת חזרתיות ומטריקות, אך דורשת תרחיש תקין — אחרת אתם מודדים לא את העומס האמיתי, אלא את פעולת סקריפט הבדיקה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| הרצה ידנית | בדיקת היענות לאחר שחרור, תרחישים בודדים | אין חזרתיות, אינה משחזרת סשנים במקביל |
| מבוססת סקריפט על עותק | בדיקות שגרתיות לפני העלאה, רגרסיה בזמן תגובה | העותק חייב לשחזר את תצורת סביבת הייצור, אחרת הנתונים אינם רלוונטיים |
| עומס מבוזר | בדיקת סקיילינג אופקי, עמידות לתקלות של האשכול | דורש סנכרון מחוללים ואגרגציה תקינה של מטריקות |
| על עותק של סביבת הייצור | קבלה סופית לפני מבצע בעומס גבוה | יקר בהכנה, יש לסנכרן את העותק באופן קבוע עם סביבת הייצור |
המגבלות של כל גישה הן ייחודיות, וחשוב להציג אותן לפני ההתחלה. בדיקה על עותק לא תראה ירידה בביצועים מתעבורה אמיתית, אם העותק מפגר בנתונים ובתצורת המטמון. עומס מבוזר נותן תמונה אמיתית רק עם נקודת איסוף מטריקות אחידה — אחרת צוואר הבקבוק "ילך לאיבוד" בין המחוללים. הרצה ידנית אינה מחליפה את המבוססת סקריפט, אלא משלימה אותה: היא תופסת את מה שלא נכלל בתרחיש.
איך מתנהל הפרויקט: שלבי העבודה
העבודה מתבצעת באיטרציות: תחילה מתעדים את המצב הקיים ואת המטרות, לאחר מכן משחזרים את העומס, ורק אחרי כן משנים את התצורה. סדר זה מונע "אופטימיזציה עיוורת", שבה שינויים נעשים לפי אינטואיציה ואינם מניבים אפקט מדיד.
- ביקורת תצורה. משרטטים מפת סביבה: פרמטרים של שרת האינטרנט ו-PHP, הגדרות מטמון, אינדקסים ושאילתות איטיות במסד הנתונים, הרכב הרכיבים והמודולים, אינטגרציות חיצוניות. התוצר — רשימת צווארי בקבוק עם הערכה איזה מהם יגביל את המערכת ראשון.
- איסוף דרישות עומס. מדייקים את פרופיל המשתמשים: אילו עמודים פותחים, כיצד מתחברים, מה מכניסים לסל, באיזו תדירות ניגשים לאזורים אישיים. מכאן נגזרים יעדי ביצועים — כמה סשנים במקביל ואיזה זמן תגובה נחשב acceptable.
- הכנת תרחישי עומס. מתארים מסלולים אמיתיים ולא בקשות בודדות: התחברות, קטלוג, ביצוע הזמנה, אזור אישי. התרחישים מותאמים בפרמטרים — משתמשים שונים, מוצרים שונים, זמני "חשיבה" שונים, אחרת הבדיקה מציגה תמונה אידיאלית שלא קיימת במציאות.
- סביבת בדיקה ונתונים. פורסים העתק של תצורת הייצור וממלאים אותו בנפח נתונים הדומה לזה שבסביבת הייצור. בדיקה על מסד נתונים ריק היא חסרת משמעות: השאילתות עפות, אך בנפחים אמיתיים הן מדרדרות.
- הרצה ופרופיילינג. מזרימים עומס בשלבים, תוך תיעוד היכן בדיוק מתחיל גידול בזמן התגובה ובשגיאות. במקביל אוספים מדדים של השרת, מסד הנתונים והאפליקציה — זה מאפשר להבחין בין חוסר במשאבים לבין קוד לא יעיל.
- אופטימיזציה והרצה חוזרת. מתקנים את מה שנמצא: מטמון, אינדקסים, שליפות כבדות, הגדרות חיבורים. לאחר כל תיקון חוזרים על אותו תרחיש — השוואת "לפני/אחרי" מציגה את השיפור האמיתי, ולא את הצפוי.
- מסירת התוצאות. מוסרים דוח עם גרפים וצווארי בקבוק, נוהל להרצת בדיקות והמלצות לניטור, כדי שהצוות יוכל לחזור על הבדיקה לפני שחרורים גדולים ומבצעי מכירות.
העיקרון המרכזי — בדיקת התוצאות בכל שלב, ולא רק בסיום. תארו את המשימה שלכם: פרופיל עומס, תקופות שיא, תסמינים נוכחיים — נחזור עם הערכה ותוכנית שלבים.
תוצרי פלט: מה נשאר אצל המזמין
בסיום בדיקות העומס המזמין מקבל לא מצגת עם גרפים, אלא ערכה עובדת שלפיה צוות התפעול יוכל לחזור על ההרצות בעצמו — בלעדינו וללא הסברים בעל פה. הכול נאסף למאגר לצד הפרויקט, מנוהל בגרסאות ומתעדכן עם שינוי בארכיטקטורה.
- תרחישי עומס — פרופילים של התנהגות משתמשים: אימות, קטלוג, ביצוע הזמנה, פעולות ניהול. כל תרחיש עם מספר יעד של סשנים במקביל, חלוקה לפי תפקידים ונקודות מדידה.
- תצורות של סביבת הבדיקה והמחוללים — פרמטרים של הסביבה שבה נלקחו התוצאות: הרכב השירותים, הגדרות מטמון, מגבלות חיבורים. בלעדיהם המספרים בדוח אינם ניתנים לשחזור.
- דוח בדיקות עומס — גרפים של זמן תגובה ותפוקה לפי שלבי התרחיש, שיעור שגיאות ופסקי זמן, צווארי בקבוק עם הצמדה לרכיב מסוים והערכת מרווח עד לירידת ביצועים.
- נוהל הרצות — מתי ומה להריץ: לפני שחרור, לאחר שינוי תצורה, בעת גידול בתעבורה. עם קריטריונים של «עבר / לא עבר» וספים שמעבר להם השחרור נחסם.
- המלצות לתיקון — רשימה מתועדפת: מה לשנות בקוד, מה בהגדרות השרת, מה בסכימת המטמון. עם האפקט הצפוי לכל סעיף.
- סקריפטים ותשתית תומכת — קבצי התרחישים עצמם וסקריפטי עזר להרצה, כדי שההרצה תחזור על עצמה בפקודה אחת.
- תיעוד — תיאור קצר של סביבת הבדיקה, תרשים זרימת בקשות והוראות למהנדס שפותח את הערכה בפעם הראשונה.
את הערכה מעבירים עם הסבר: מראים כיצד לקרוא את הדוח, היכן לשנות את פרופיל העומס לקראת שיא עונתי חדש וכיצד להבחין בין ירידת ביצועים לבין התפרצות חד-פעמית. מכאן והלאה אתם או מריצים בעצמכם, או חוזרים אלינו לסבב נוסף — בשני המקרים נקודת המוצא והיסטוריית המדידות נשארות אצלכם.
מקרה בוחן: מניעת כשלים בעומסי שיא
מה היה לפני
הפרויקט — חנות מקוונת על 1С-Битрикс עם קטלוג של כמה עשרות אלפי פריטים וסנכרון עם 1С לפי לוח זמנים.
במצב רגיל האתר הגיב תוך 300–500 מ"ש, אך במהלך מבצעי מכירות וסנכרון הקטלוג החלו כשלים: שיעור שגיאות 5xx הגיע עד 12%, חלק מההזמנות לא עברו, והסל איבד פריטים בשליחה חוזרת של הטופס. הניטור תיעד גידול בתור לעיבוד בקשות ופגיעה בתקרת החיבורים למסד הנתונים.
מה שינו
תחילה הפיקו פרופיל תחת עומס המדמה שיאים אמיתיים: כניסה בו-זמנית, חיפוש בקטלוג, הוספה לסל וביצוע הזמנה. הבדיקה שיחזרה גידול פי 5 מהממוצע היומי והחזקת שיא במשך 20 דקות — בדיוק כמה שנמשכת גל מכירות.
לפי התוצאות עיבדו מחדש את צווארי הבקבוק: הוציאו את מטמון הקטלוג והמחירים לשכבה נפרדת, כדי שהסנכרון עם 1С לא יאפס אותו כולו, הפרידו בין קריאה לכתיבה במסד הנתונים, הוסיפו אינדקסים לסינונים כבדים והגבילו משימות סנכרון מקבילות. ביצוע ההזמנה הועבר לעיבוד אידמפוטנטי — שליחה חוזרת אינה יוצרת עוד כפילויות.
מה נהיה
| מדד | לפני | אחרי |
|---|---|---|
| זמן תגובה תחת שיא | 4–6 ש' | 0,8–1,2 ש' |
| שיעור שגיאות 5xx | עד 12% | מתחת ל-0,3% |
| החזקת שיא | כשלים לאחר 3–5 דק' | 20 דק' ללא דרדור |
| הזמנות שאבדו | בודדות בכל גל | אין |
גלי השיא האתר עובר כעת ללא התערבות ידנית, והסנכרון עם 1С מתבצע במקביל לתעבורה ואינו מפיל את חלון הראווה. הבדיקה נשארה ברגרסיה — לפני כל שחרור מריצים את אותו תרחיש ומשווים את המדדים לערך הייחוס, כדי שדרדור יתפס לפני העלאה לאוויר, ולא ביום המכירה.
במה שונה בדיקת עומס מבדיקת לחץ?
בדיקת עומס בודקת את התנהגות המערכת בעומס מחושב — זה שנקבע בדרישות ואושר על ידי פרופיל הפניות אמיתיות. אנו משחזרים תרחיש טיפוסי: שיעור המשתמשים המאומתים, יחס הקריאה והכתיבה, שיאי פעילות בשעות העבודה, התנהגות סל הקניות והשלמת ההזמנה.
המטרה — לוודא שבזרימה שגרתית זמן התגובה נשאר בגבולות המותרים, והשרתים אינם עוברים לעומס יתר. התוצאה — אישור שהמערכת תעמוד בתעבורה הצפויה, ורזרבה במשאבים לצמיחה.
בדיקת לחץ פותרת את המשימה ההפוכה: אנו מעלים בכוונה את העומס מעל לעומס המחושב ומחפשים את נקודת הכשל — הרגע שבו זמן התגובה יוצא מגבולות המותרים, גדל תור הבקשות או שמתרחש כשל בצומת מסוים.
כאן חשוב לא גרף יפה, אלא ההבנה מה בדיוק נשבר ראשון: בסיס הנתונים, המטמון, שכבת האינטרנט או אינטגרציה חיצונית. זה מראה היכן עובר גבול היציבות וכיצד המערכת מדרדרת — באופן הדרגתי או בקריסה.
ההבדל בגישה לתוצאה. בדיקת עומס עונה על השאלה "האם נעמוד בצפוי", בדיקת לחץ — "מה יקרה אם נחרוג מהצפוי פי כמה". הראשונה מאשרת מוכנות להפעלה ולצמיחה המתוכננת, השנייה — יציבות בפני אנומליות: מבצע מכירות, תעבורה ויראלית, כשל של שירות סמוך. שני התרחישים נבנים על אותה מערכת כלים ואותו פרופיל משתמשים, אך המטרות וקריטריוני הקבלה שלהם שונים.
בפועל אנו מריצים אותם ברצף. תחילה פרופיל העומס מאשר שהעומס המחושב מעובד באופן שגרתי, לאחר מכן אנו מעלים את הזרימה בשלבים עד לכשל ומתעדים את הסף.
כך הלקוח מקבל לא "האתר מהיר" מופשט, אלא קונקרטיקה: באיזה מספר משתמשים בו-זמניים המערכת מחזיקה מעמד, היכן מתחילה הדרדרות ואילו צמתים דורשים רזרבה.
ספקות טכניים נפוצים
בדיקות עומס ל-Bitrix כמעט תמיד נתקלות בשלוש שאלות הנדסיות: האם הריצה תפיל את האתר החי, מאיפה לקחת נתונים, ובאיזו תדירות לחזור על זה. להלן התשובות שנדרשות לרוב למזמין הטכני לפני ההתחלה.
בודקים על האתר החי או מרימים עותק?
ריצה על הפרודקשן היא רעיון גרוע: מחולל העומס עצמו הופך למקור לכשלים, וחלק מהבקשות מגיעות להזמנות ולתשלומים אמיתיים. הסכמה העובדת היא עותק של קווי המתאר החיים עם בסיס נתונים מנוטרל מזהים, עם אותו הרכב רכיבים והגדרות מטמון.
אם לא ניתן להרים עותק, מסתפקים בפרופיל עדין על הפרודקשן בחלון של תעבורה נמוכה, ובהכרח מחריגים אינטגרציות תשלום ודואר.
כיצד להכין נתונים כדי שהתוצאות יהיו הוגנות?
בסיס נתונים ריק משקר: הבקשות עפות, המטמון מתחמם באופן מיידי, וצווארי הבקבוק אינם מתגלים. יש צורך בנפח הדומה לזה של הפרודקשן — לפי מספר המוצרים, המדורים, המשתמשים וההזמנות, עם אותו מבנה של בלוקי מידע ומאפיינים. בנפרד מחממים את המטמון לפני המדידה, אחרת הריצה הראשונה תציג לא את הביצועים אלא את זמן ההתנעה הקרה.
באיזו תדירות יש לחזור על הריצות?
בדיקה חד-פעמית עונה רק על השאלה הנוכחית. בהמשך הגיוני לקשור את הריצה לשינויים: שחרור גדול, שינוי בתצורת השרת, גידול הקטלוג, מבצע עונתי. אז ההשוואה נעשית מול המדידה הקודמת, והדגרדציה נראית מיד, ולא ביום העומס השיאי.
מה לעשות אם צוואר הבקבוק אינו השרת?
לעיתים קרובות העיכוב מתגלה בבסיס הנתונים, ב-API חיצוני או בבקשה איטית של רכיב, ולא בחומרה. לכן לדוח נכנסים לא רק גרפים, אלא גם פרופיל של הבקשות הכבדות והדפים היקרים ביותר — לפיהם רואים מה לייעל בראש ובראשונה.
תארו את קווי המתאר שלכם ואת תרחיש השיא — נחזור עם תוכנית ריצות, הכנת נתונים והערכה.
נדון במשימה שלך לבדיקות עומס
כדי לחזור עם הערכה ותוכנית, ולא עם מילים כלליות, אנחנו צריכים להבין את פרופיל העומס ואת גבולות המערכת.
ספרו מה כבר ידוע: איזה שיא תעבורה אתם מצפים, אילו תרחישים קריטיים (ביצוע הזמנה, כניסה לאזור האישי, סנכרון עם 1С, ייצוא קטלוג), האם יש עליות עונתיות ואיך מתנהג כעת הפרוד תחת עומס. זה מספיק כדי להציע סכמת בדיקה ולהעריך את היקף העבודה.
בהמשך מחדדים את התשתית הטכנית — ממנה תלויים גם המתודולוגיה וגם לוחות הזמנים:
- תצורה נוכחית: שרתי אינטרנט, בסיס נתונים, מטמון, מאזן עומסים, שירותים ייעודיים;
- כיצד בנוי הסנכרון עם 1С ומערכות חיצוניות — לפי לוח זמנים או בזמן אמת;
- היכן לפרוס את קווי המתאר לבדיקות: האם יש אתר דומה לפרוד במשאבים;
- אילו נתונים ניתן להשתמש — עותק אנונימי של בסיס הנתונים או סינתטיקה;
- הרשאות גישה וחלונות זמן שבהם מותר להעמיס על המערכת בלי סיכון למשתמשים פעילים;
- מדדי יעד: זמן תגובה של עמודים מרכזיים, שיעור שגיאות מותר, סף ירידת ביצועים.
לסיכום השיחה אנחנו מתעדים תרחישים, מדדי קבלה ושלבים: הכנת קווי מתאר, נטילת קו בסיס, סדרת ריצות עומס עם עלייה בעצימות, ניתוח צווארי בקבוק, דוח עם המלצות לאופטימיזציה.
אתם מקבלים לא רק מספרים, אלא רשימה של נקודות צמיחה קונקרטיות — מה לשנות בתצורה, במטמון ובשאילתות כדי שהמערכת תעמוד בשיא.
תארו את המשימה בפורמט נוח — נחזור עם הערכה לבדיקות עומס ותוכנית עבודה. אם צריך, מהנדס יצטרף לדיון ויעזור לנסח תרחישים עוד לפני ההתחלה.