אבחון ביצועים של Bitrix: היכן אובדת המהירות
אתר Bitrix איטי רק לעתים רחוקות נועץ בסיבה אחת. המהירות אובדת בכמה מקומות בו-זמנית: הקטלוג מרכיב כרטיס מוצר בעשרה פניות נפרדות למסד הנתונים, התבנית מושכת את אותם נתונים שוב, והסביבה נותרה כפי שהייתה כשהפרויקט הושק. המשתמש רואה דבר אחד — הדף נפתח לאט, והוא עוזב לפני שהספיק לבחור משהו.
הצוואר הראשון בבקבוק מבחינת ביצועים — הקטלוג. מסננים, מחירים, מלאי, הצעות מסחריות ומאפיינים נאספים בשאילתות נפרדות, אף שחלק מהם נפתר במעבר אחד. ככל ששאילתת הבחירה רחבה יותר ויותר מאפיינים מוצגים ברשימה, כך בולט יותר הפער בין תוצאות קרות למחוממות.
השני — קריאות עודפות. התבנית פונה לאותם נתונים כמה פעמים, שירותים חיצוניים נבדקים בכל פתיחת דף, המטמון מתאפס לעתים קרובות יותר ממה שהתוכן משתנה. בסך הכול זו עבודה מיותרת שהשרת מבצע לשווא.
השלישי — סביבה לא מוגדרת. מטמון, דחיסה, הגשת קבצים סטטיים, פרמטרים של מסד הנתונים ותורי משימות מוגדרים לפרויקט מסוים, ולא לפי ברירת מחדל. בלי זה אפילו קוד מדויק נתקל במשאבי השרת, ולא בלוגיקה של עצמו.
אבחון מהירות האתר מראה כיצד גורמים אלה מצטברים בתקופות שיא: מגיעה פרסום או מתחיל מבצע מכירות, זמן התגובה עולה באופן לא ליניארי, וחלק מההזמנות הולכות לאיבוד סתם כך.
אבחון ביצועים של Bitrix מפרק את התמונה למקטעים מדידים ועונה על השאלה המרכזית — מה נסגר בהגדרה, ומה דורש עבודה מחדש על הקוד.
מה נותנת האופטימיזציה: אפקטים מדידים לאתר
אופטימיזציה של ביצועי אתר על 1C-Bitrix נמדדת לא במילה "מהיר יותר", אלא במספרים לפני ואחרי. נקודות הבקרה — חציון ואחוזון 95 של זמן תגובת הדפים, שיעור השאילתות שנכנסו לתקציב, וזמן ההתאוששות לאחר תקלה. אנחנו לוקחים אותם בסביבת הייצור תחת עומס, ולא בסביבת בדיקה שבה התעבורה לא דומה לזו האמיתית.
האפקט הראשון — זמן תגובת הדפים. מטמון רכיבים ומצב קומפוזיט, סקירה של שאילתות כבדות למסד הנתונים, אינדקסים לבחירות בקטלוג והעברת ייצוא למשימות רקע מאיצים את התגובה פי כמה: שיעור הדפים שנכנסים לתקציב הזמן עולה מחצי לתשעה מתוך עשרה.
השני — עמידות בעומס שיא. חימום מטמון לפני מבצע, הגבלת דוחות מקבילים ותור למשימות כבדות מאפשרים להחזיק שיא גבוה פי 3-5 מהתעבורה הרגילה: התגובה עולה בצורה חלקה, בלי קטיעה והמתנה בתור אצל המשתמש.
השלישי — הפחתת זמן ההשבתה. ניטור תרחישים מרכזיים, נוהל חזרה לאחור מכוון ותמונות מצב של התצורה שצולמו מראש מעבירים את ההתאוששות משעות של חיפוש סיבה לדקות לפי תרחיש ברור.
הרביעי, היקר ביותר בסופו של דבר: נעלם סוג שלם של כשלים — פסקי זמן בחיבורים למסד הנתונים, קריסות בגלל זיכרון בייבוא, נעילות בעת סנכרון עם מערכת הנהלת חשבונות. תקלות נראות לפי מדד לפני שהן נראות לפי שיחת טלפון מהלקוח.
פורמטים של עבודה: אבחון חד-פעמי, הטמעה, ליווי
הפורמטים נבדלים לא בעומק הדוח, אלא במה שקורה אחריו: האבחון נשאר מסמך או הופך לשינויים בסביבת הבדיקה. אנחנו בוחרים אפשרות לפי מצב הפרויקט — אם האתר צונח בשיא, בדרך כלל מספיק אבחון חד-פעמי; אם גרסאות יוצאות כל שבוע, מדידות חד-פעמיות כמעט לא מועילות.
| פורמט | מתי מתאים | מגבלות |
|---|---|---|
| אבחון חד-פעמי בלי תיקונים | צריך להבין את סיבת ההידרדרות ולהעריך את היקף העבודה לפני ההתחלה | מסתיים בדוח: צווארי הבקבוק נשארים במקום, והשינויים ייעשו בשלב נפרד |
| אבחון עם הטמעה | הסיבה ברורה, צריך תוצאה במסגרת משימה אחת | דורש חלון לפריסה, רגרסיה ומדידות חוזרות על אותו פרופיל תעבורה |
| ליווי ביצועים קבוע | גרסאות יוצאות לעתים קרובות, העומס גדל באופן בלתי צפוי | צריך הרשאות לשרת ולניטור, ואת ספי ההתראות יהיה צורך לתחזק |
| ניתוח לפני מעבר סביבה | מתוכננת החלפת פלטפורמה, גרסת פלטפורמה או סכמת מטמון | התחזית נכונה בדיוק במידה שבה פרופיל העומס תואם את התעבורה האמיתית |
בדיקות עומס אנחנו מפעילים באופן נקודתי — כשצריך להפריד בין בעיה בקוד לבין חוסר במשאבי הפלטפורמה. הפורמט הנבחר לא חוסם את האחרים: אבחון חד-פעמי גדל בקלות להטמעה, וזו — לבקרת עומס קבועה.
שלבי העבודה: מנטילת מדידות עד מסירת נהלים
כל שלב נשען על המספרים של השלב הקודם — אופטימיזציה עיוורת אינה באה בחשבון. להלן שלבי האופטימיזציה של אתר על 1C-Bitrix ותוכנית העבודה: מנטילת מדידות עד קבלת התוצאות.
- איסוף הרשאות ומיפוי מלאי. מקבלים גישה לשרת, לפאנל הניהול, למאגר ולגיבויים, מתעדים את תצורת הסביבה והרכב המודולים. בלי זה כל תיקון — ניחוש.
- נטילת מדידות. קו בסיס: זמן תגובת השרת, מהירות יצירת דפים, מספר השאילתות למסד הנתונים בדף טיפוסי, שיעור הפגיעות במטמון, משקל וכמות הסטטיקה. תרחיש העומס חוזר על עצמו בלי שינויים — אחרת אין מה להשוות.
- חיפוש צווארי בקבוק. עורכים פרופיל לדפים כבדים: שאילתות איטיות, בחירות בלי אינדקסים, רכיבים מיותרים, סוכנים שרצים בכל פנייה.
- סכמת תיקונים. מתאמים מה משנים בקוד, מה בתצורת השרת, מה במטמון, עם הערכת סיכון וסדר חזרה לאחור לכל סעיף.
- הטמעה. הולכים מהאפקט הגדול ביותר בסיכון הנמוך ביותר: קודם מטמון ושאילתות, אחר כך רכיבים והגדרות סביבה. כל בלוק נבדק בנפרד.
- מדידות בקרה. חוזרים על אותו תרחיש ומשווים לקו הבסיס — כך רואים את התרומה של כל שינוי, ולא מספר ממוצע לפרויקט.
- קבלת התוצאות. מתעדים מדדים סופיים ומוסרים נהלים: מפת צווארי בקבוק, רשימת שינויים, הגדרות מטמון וניטור, כדי שההידרדרות לא תחזור עם העדכון הקרוב.
מה נשאר אצלכם: תצורות, סכמות, נהלים
לאבחון יש משמעות רק כאשר ניתן להשתמש בתוצאותיו בלי אנחנו. לכן כל מסקנה מתועדת בארטיפקט שהצוות שלכם או קבלן אחר מיישם ישירות — בלי לשחזר את ההקשר מהתכתבות. חבילת המסמכים נאספת במהלך העבודה ומועברת כולה בקבלה.
- תיעוד האופטימיזציה: מה שונה בקוד ובהגדרות, אילו צווארי בקבוק נסגרו, אילו נשארו ובאיזה סדר לגשת אליהם.
- סכמת התשתית: שרתים, איזון עומסים, מטמון, תורים, שירותים חיצוניים — עם סימון הנתיב הקריטי של הבקשה.
- נוהל תחזוקה: תדירות הגיבוי, סדר עדכון הליבה והמודולים, בדיקת העתקה בשחזור, בקרת יומנים ומקום בדיסק.
- מפת צווארי בקבוק עם עדיפויות: חלק מזמן התגובה בכל מקטע והאפקט הצפוי מכל תיקון.
- פרופילי ניטור מוגדרים: ספים לזמן תגובה, תדירות שגיאות ועומס, כללי התראה לאחראים.
- תוכנית חזרה לאחור: אילו שינויים הפיכים, מאיזו נקודה לשחזר וכמה זה לוקח.
- מסירת הרשאות: פאנל האחסון, פאנל הניהול, המאגר, הניטור והגיבויים — רשומים על חשבונות שלכם, ולא על שלנו.
הקבלה מתנהלת לפי אותה רשימה: אתם בודקים שכל סעיף משוחזר בצד שלכם, ורק אחר כך סוגרים את השלב. הלאה אפשר להמשיך ליווי בכוחות עצמכם או למסור לקבלן אחר — מצב המערכת מתועד, ולא נשמר בראשים.
כיצד גדלו ביצועי הקטלוג: לפני ואחרי
קטלוג עם עשרות אלפי פריטים על 1C-Bitrix בשיאים עונתיים הפסיק להגיב: המדור נבנה במשך כמה שניות, המסננים עברו לפסק זמן, וחלק מהתעבורה אבדה בכשלים. מפרקים מקרה של אופטימיזציית Bitrix עם מדדים לפני ואחרי.
מה היה צוואר הבקבוק
הכאב העיקרי ישב בתבנית המדור: בחירת המוצרים נעשתה בשאילתה אחת לכל פריט, מאפיינים ומחירים נמשכו בתוך הלולאה, והמטמון אופס בכל סנכרון עם 1C ולא חולק לפי עמודי עימוד. העומס על מסד הנתונים גדל ליניארית עם מספר המוצרים, וכל שינוי מחיר איפס את כל המדור במטמון.
מדדים לפני ואחרי
התיקונים חולקו לשכבות: שאילתות באצווה במקום בחירה לפי פריט בודד, אינדקסים מורכבים למסננים, מטמון נפרד עם קישור לעמוד ואינוולידציה נכונה לפי אירוע סנכרון. להלן גידול בביצועי הקטלוג לפי מדידות בקרה על אותו פרופיל עומס.
- זמן תגובת עמוד המדור: מכ-4.5 שניות ל-0.8 שניות;
- שיעור השאילתות למסד הנתונים לעמוד קטלוג אחד: הצטמצם בערך פי 7;
- כשלים בשעות שיא: מ-6–8% לרמת שגיאה סטטיסטית;
- בנייה מחדש של המטמון אחרי סנכרון עם 1C: מדקות לשניות.
כעבור חודש חזרו על המדידות בתעבורה אמיתית — המדדים נשמרו, והייבוא הפסיק "להקפיא" את הקטלוג. זה בדיוק ההבדל בין תיקון "בעין" לאבחון, שבו כל השערה מאושרת במדידה לפני ואחרי.
מה לעשות אם צוואר הבקבוק לא בקוד אלא בסביבה?
אפשר להפריד בין "קוד או שרת" רק באמצעות מדידות, ולא באמצעות ניחושים. אנחנו לוקחים פרופיל בסביבת הייצור ברגע ההידרדרות ומפרקים את זמן הביצוע למקטעים: חישובים באפליקציה, שאילתות למסד הנתונים, המתנה לתת-מערכת הדיסקים, קריאות רשת לשירותים חיצוניים, הגשת סטטיקה. אם החלק העיקרי הוא המתנה ולא חישובים, צוואר הבקבוק בתשתית — ואופטימיזציה של הקוד תיתן אפקט קוסמטי.
בהמשך בודקים את ההשערה על ידי השוואת סביבות. פורסים את אותה גרסה ואת העתקת נתוני הייצור בסביבת ייחוס עם תצורה אחרת ומריצים אותם תרחישים — מילוי הקטלוג, ביצוע הזמנה, ייצוא, סנכרון עם מערכת הנהלת החשבונות.
אם בסביבה אחרת אותם דפים נבנים מהר פי כמה עם אותו קוד, השאלה סגורה: הסיבה בהגדרת הסביבה, ולא באפליקציה.
בסביבה עצמה בודקים מקומות קונקרטיים. מטמון הפלטפורמה 1C-Bitrix ומטמון התגובות בצד שרת האינטרנט: האם המטמון מתאפס בכל בקשה, האם הוא כבוי בגלל הרשאות או סוכנים. מגבלות זיכרון ומספר תהליכים במקביל, שבגללם בקשות עומדות בתור.
מאגר החיבורים למסד הנתונים והפרמטרים שלו: חסרים תהליכי עבודה, נעילות מפריעות, בחירות כבדות עוברות למיון קבצים. מצב הדיסק: תור קלט-פלט, כתיבות סינכרוניות ליומנים.
ולוח הזמנים: משימות מתוזמנות, גיבוי, סריקת אינדקס, רוטציה של יומנים — אם הם נופלים לשיא, תמונת ההידרדרות חוזרת לפי שעות.
סדר העבודה חשוב: קודם מאשרים היכן בדיוק הגבול, ורק אחר כך מתקנים. אחרת מקטע שנכתב מחדש לא משנה את התמונה, ויש להחזיר רגרסיה לאחור.
כל תיקון בסביבה נבדק על העתקת נתוני הייצור לפי אותם תרחישים ומשווים מדידות לפני ואחרי — אז רואים מה בדיוק נתן את ההאצה והאם צוואר הבקבוק לא יחזור בשיא העומס הבא.
ספקות לגבי הרשאות, לוחות זמנים ותיקונים באתר חי
אבחון ביצועים של 1C-Bitrix לא דורש עצירת האתר: מדידות נלקחות בסביבת הייצור בשעות עומס נמוך, ושינויים בקוד ובהגדרות מכינים על העתקה. הרשאות ניתנות בחשבון נפרד לקריאה בלבד — הגדרות, יומני אירועים, העתקת מסד נתונים. הרשאות כתיבה למסד הנתונים הפעיל ולקבצי האתר לא נדרשות לנו, ולאחר העבודה הגישה נשללת.
איזה היקף הרשאות נדרש לאבחון?
צפייה בהגדרות וביומן האירועים בפאנל הניהול, קריאת התצורה והיומנים בשרת, העתקת מסד הנתונים. סיסמאות מועברות בערוץ מאובטח ונשמרות עד סוף העבודה. אם גישה חיצונית אסורה לפי מדיניות, מנתחים ייצוא יחד עם המהנדס שלכם.
האם אפשר לתקן את האתר בלי לעצור את הפעילות?
שינויים נבדקים תחילה על העתקה ומשווים מדדים לפני ואחרי. לייצור מעבירים בלוק אחד בכל פעם: תבניות ותצורות תחת בקרת גרסאות, לכן חזרה לאחור היא מעבר למצב הקודם, ולא תיקון ידני.
איך מתבצעים התיקונים וכמה זמן אורכים לוחות הזמנים של האופטימיזציה?
תחילה אבחון: צווארי בקבוק מדורגים לפי תרומתם לזמן התגובה הכולל. התיקונים מתבצעים באיטרציות מהמקטע הכבד ביותר, כל צעד מדיד. איפוס מטמון ובנייה מחדש של אינדקסים — פעולה מבוקרת: מטמון מנקים נקודתית לפי רכיבים, אינדקסים בונים מחדש ברקע, חימום נעשה על העתקה.
מה יקרה עם גידול בעומס?
בודקים כיצד התצורה מתנהגת בתעבורת שיא, ומתעדים את הסף שמעבר לו נדרשת הפרדה בין שרתים. זה חלק מהדוח, ולא הפתעה ביום המבצע.
נדון במשימה שלכם: מה לשלוח להערכה
כדי לחזור עם הערכה ותוכנית עבודה, ולא עם משאלות כלליות "להאיץ את האתר", אנחנו צריכים עובדות על הסביבה שלכם. להלן נתוני פתיחה שלרוב קובעים היכן בדיוק מתבזבז זמן התגובה; שלחו את מה שיש בהישג יד, את השאר נאסוף יחד בשיחה.
- כתובת האתר וכתובת סביבת הבדיקה, אם יש בה העתקה עדכנית של מסד הנתונים;
- גרסת ליבת הפלטפורמה ורשימת המודולים המחוברים, כולל מודולים בכתיבה עצמית ושל צד שלישי;
- סכמת פריסה: היכן פועלת חלק הווב, היכן יושב מסד הנתונים, וכיצד הם קשורים זה לזה;
- דוחות ניטור ויומני שאילתות איטיות בשבוע רגיל ובתקופת שיא;
- תיאור שיאי העומס — מבצעי מכירות, דיוורים, גידול עונתי — עם תאריכים ואופי הפעילות;
- מה כבר ניסו לשנות: מטמון, אינדקסים, כתיבה מחדש של התבנית — ומה יצא מזה;
- איש קשר של המנהל והרשאות לפאנל הניהול, לגיבויים ולהגדרות הסביבה.
היעדרם של חצי מהסעיפים לא מעכב את השיחה: חלק מהתמונה המהנדסים שלנו לוקחים בעצמם מהאתר הפעיל, וחלק — משחזרים לפי סימנים עקיפים.
בסיכום הדיון תקבלו רשימת צווארי בקבוק עם עדיפויות, תוכנית עבודה לפי שלבים עם הערכת מאמץ לכל אחד והבנה אילו תיקונים בטוח להכניס בלי לעצור את האתר. תארו את משימת האופטימיזציה בצורה נוחה — נחזור עם הערכה ותוכנית.