ביקורת ביצועים בביטריקס: היכן האתר מאבד מהירות
נהוג לייחס אתר איטי בביטריקס לאחסון, ולרוב זהו כיוון חיפוש שגוי. ביקורת ביצועים בביטריקס מתחילה במדידת זמן התגובה של השרת ובניתוח איזה חלק ממנו נאכל על ידי הליבה: שליפות מאינפובלוקים, קריאות חוזרות של קומפוננטות, חיבורים מיותרים של מודולים בכל עמוד.
אחד מצווארי הבקבוק הטיפוסיים של ביצועים הוא הקטלוג. סינון לפי מאפיינים, מיון בהתחשב בהנחות ובחירת הצעות מסחריות יורדים לבסיס הנתונים בשאילתות נפרדות בלי אינדקסים ובלי מטמון תוצאות. כל עוד יש מאות מוצרים זה לא מורגש; בעשרות אלפים העמוד נבנה בשניות בכל פנייה.
השני — מטמון שלכאורה מופעל, אך מתאפס בכל עדכון של מוצר. ייצוא מ-1C מאפס את המדור כולו, ובנייה מחדש של העמודים נופלת על מבקרים חיים. למחיר השניות יש מדד: לפי הערכת Portent, כל שנייה נוספת של טעינה מורידה את ההמרה במספר אחוזים.
השלישי — התדרדרות תחת עומס. מדידה בודדת נותנת תגובה סבירה, אבל בפניות מקבילות לקטלוג הזמן עולה באופן לא ליניארי: משפיעים שאילתות חוזרות לבסיס הנתונים, נעילות בכתיבה ובנייה מחדש של המטמון תחת תנועה.
בהמשך נראה איך זה נסגר — ברמת האינדקסים, סכמת ההטמנה, עמודים מרוכבים והעברת הייצוא לחלון לילי.
מה משתנה אחרי אופטימיזציה: חמישה אפקטים מדידים
אפקט האופטימיזציה נראה לא לפי תחושות אלא לפי מדדים, שאותם בביטריקס מודדים לפני ואחרי על אותה קבוצת עמודים ואותו פרופיל עומס. להלן חמש קבוצות של מדדים שלפיהם מקבלים את העבודה.
מהירות מסירת עמודים והתגובה הראשונה
השרת מתחיל למסור את הסימון מוקדם יותר: נעלמות התורים למטפלים והסנכרון המיותר בתוך הבקשה. המדדים הנצפים — זמן עד הבית הראשון והצגה מלאה בעמודי הקטלוג, שבהם התגובה קודם גדלה יחד עם מספר המוצרים.
עומס על בסיס הנתונים
מטמון לשליפות חוזרות ושאילתות כבדות שנכתבו מחדש מסלקים קריאה מרובה של אותם מאפייני קטלוג. אנחנו בודקים את מספר השאילתות לעמוד, שיעור הקריאות בלי אינדקס וזמן היקרות שבהן — הן מפסיקות להופיע בפרופיל העומס.
יציבות בשיא
שעות השיא מפסיקות להיות מצב נפרד: מגבלות המטפלים והחיבורים הועלו באופן מתואם, פעולות כבדות הוצאו מבקשת המשתמש לרקע. הבדיקה — הרצה של אותה קבוצת עמודים תחת עומס מוגבר פי כמה בלי גידול בזמן התגובה.
עלות זמן ההשבתה וסוגי הכשלים שנפתרו
אנחנו מפרקים את הכשלים לפי סוגים: פסקי זמן בקטלוג, תקלות בייבוא, שגיאות שרת בשיא. קודם כל סוג נתן חלונות אי-זמינות באורך דקות ושעות; אחרי — אי-הזמינות הכוללת בחודש נמדדת בדקות, וחלק מהסוגים בכלל לא משוחזרים.
קיצור זמן ההשבתה בעת שחזור
כשתקלה בכל זאת מתרחשת, חשובה מהירות החזרה: סדר חזרה לאחור מובן, גיבויים סדירים והתראות מקצרים את החלון מהגילוי ועד השחזור. את זה בודקים בתרגולים, לא בהשערות.
מצבי אופטימיזציה: מטמון, שאילתות, תשתית
תחבולה אחת לא סוגרת את הבעיה: מטמון כללי לא מציל משתמשים מזוהים, ושאילתות מאופטמות נתקלות בתקרה של שרת אחד. הטמנה ב-1C-ביטריקס פועלת בכמה רמות — חשוב להבין איזו מהן סוגרת מה.
מה נפתר ברמת האפליקציה
מטמון מרוכב מוסר לאורח עמוד מוכן, תוך דילוג על בנייתו; מטמון קומפוננטות מנוהל ומטמון שאילתות מסלקים פניות חוזרות לבסיס הנתונים. אופטימיזציית שאילתות היא ניתוח של שליפות איטיות: תנאים בתוך לולאה, חיבורי טבלאות מיותרים, אינדקסים חסרים. זמן יצירת העמוד יורד פי כמה, והעומס על בסיס הנתונים מפסיק לגדול יחד עם התנועה.
מה דורש שינויים בתשתית
מצב מסירת העמודים מוגדר בשרת האינטרנט: סטטיקה ומטמון מוכן עוברים ישירות, והמטפל מתחבר רק לדינמיקה. בהמשך — הפרדת תפקידים: בסיס הנתונים על צומת נפרד, מטמון בזיכרון, שרת ייעודי לשיאים. זה מסלק את תור הבקשות, אבל דורש גישה לקונפיגורציה ולנוהל פריסה.
| גישה | מתי מתאימה | מגבלות |
|---|---|---|
| מטמון מרוכב | קטלוג ומאמרים לאורחים | לא מכסה התאמה אישית |
| מטמון קומפוננטות ושאילתות | תוכן מעורב בעמוד | נדרש ביטול מטמון נכון |
| אופטימיזציית שאילתות ואינדקסים | מסננים כבדים בקטלוג | האפקט הולך לאיבוד עם גידול הנתונים |
| מצב מסירה ותפקידי שרתים | תנועה קבועה, קמפיינים בשיא | נדרשת גישה לקונפיגורציה |
איך עוברת הביקורת: שלבי העבודה ההנדסית
ביקורת ביצועים היא רצף של צעדים, שכל אחד מהם נשען על הנתונים של הקודם. אנחנו לא מתחילים בתיקוני קונפיגורציה: קודם מתעדים מצב בסיס, אחרת אי אפשר להבדיל בין אפקט אמיתי לתחושת עבודה.
מדידות ופרופיילינג עומס
- מבצעים מדידות בסיס על סביבת הפרודקשן: זמן התגובה של עמודים מרכזיים, זמן יצירת העמוד, תורי שאילתות לבסיס הנתונים, משך הזמן של סוכנים ורכיבים כבדים בתבנית.
- מפעילים פרופיילינג — מפרקים את זמן התגובה לפי שכבות: שאילתות לבסיס הנתונים, מטמון, מטפלי אירועים, קריאות לשירותים חיצוניים.
- בונים מפת צווארי בקבוק: אילו מודולים, התאמות, אינפובלוקים ופתרונות צד שלישי תורמים את התרומה העיקרית לעומס.
- בודקים את קונפיגורציית הסביבה — כללי הטמנה, הגדרות שרת בסיס הנתונים, משימות מתוזמנות, לוגים ובנייה של סטטיקה.
בדיקת התוצאה על עותק של הפרודקשן
- פורסים עותק של אתר הפרודקשן ומשחזרים עליו עומס — השינויים לא עוברים לפרודקשן עד שלא אושר האפקט.
- משנים השערה אחת בכל פעם וחוזרים על המדידות: רואים איזה צעד נתן שיפור ואיזה לא שינה דבר.
- מוסרים תוכנית עבודה לביצועים עם סדרי עדיפויות, מפת צווארי בקבוק ונוהלי תחזוקה — איתם הצוות משחזר את התוצאה ולא מחזיק אותה אצל הקבלן.
ערכת תיעוד: תרשימים, נוהלים, הרשאות
את החבילה מוסרים למאגר של הלקוח יחד עם ההרשאות: היא לא קשורה אלינו וכל מהנדס שיגיע אחר כך יוכל לקרוא אותה. ההרכב סוגר שלוש שאלות — איפה צר, למה זה מוגדר דווקא כך ומה לעשות עם גידול בעומס.
- מפת צווארי בקבוק — מגבלות עם קישור לעמוד ולסוג העומס: שליפות כבדות מהקטלוג, פניות לא מאונדקסות לבסיס הנתונים, קריאות חיצוניות בזמן רינדור.
- פרופילי הטמנה — אילו שכבות מופעלות, זמן חיים, כללי איפוס לפי אירועי הקטלוג והמלאי, ומה הוחרג במכוון.
- מדיניות הרשאות — תפקידי מנהל תוכן, מנהל מערכת ומהנדס תורן, הרשאות בסביבת הפרודקשן, שמירה וביטול מפתחות.
- נוהל תחזוקה — תדירות הבדיקות, ספי התראה, סדר עדכון מודולים, חלונות עבודה וחזרה לאחור.
- יומן שינויים — מה ולמה תוקן, כדי שהתיקון הבא לא יבטל את הקודם.
דוח עם מדידות לפני ואחרי
את המדידות מבצעים על תרחיש זהה: זמן התגובה של הרשימה והכרטיס, מספר הפניות לבסיס הנתונים, נפח העמוד, שיעור הפגיעות במטמון. השוואה לפי נקודות בקרה מראה איזה תיקון נתן אפקט ואיזה נשאר ניטרלי.
נוהל למקרה של גידול בעומס
מראש מתוארות הפעולות בעת מבצע מכירות והשקת פרסום: מה עובר לסטטיקה, אילו מדורים מקבלים מטמון נפרד, ובאילו ערכים התורן יוזם הרחבה. המסמך נמצא ליד ההרשאות — מהנדס חדש נכנס לסביבה בלי שחזור סיפור ההיסטוריה בעל פה.
מקרה בוחן: האיצנו את הקטלוג וסילקנו כשלים תחת עומס
קטלוג עם 40,000 פריטים החזיק עד 900 סשנים בו-זמנית בשעות המבצעים. המטמון נבנה מחדש כמעט בכל בקשה, והשליפות לפי מסננים עברו על מאפייני משתמש לא מאונדקסים. זמן מסירת הכרטיס הגיע עד 4 שניות, שיעור כשלי השרת — עד 14%, וחלק מהסלים אבדו בעת ביצוע ההזמנה.
מה נעשה שלב אחר שלב
- מדדנו פרופיל עומס על עותק של קטלוג הפרודקשן: מצאנו שליפות איטיות, שאילתות כפולות ותבניות שמשכו את בסיס הנתונים בתוך לולאה.
- כתבנו מחדש את מסנן הקטלוג עבור אינדקסים מורכבים, הסרנו מיון לפי שדות לא מאונדקסים וחיבורי טבלאות מיותרים.
- הפרדנו את ההטמנה לפי רמות: מטמון סטטי של קומפוננטות, שכבה נפרדת לנתונים וביטול מטמון נכון בעת שינוי מוצר.
- הקלנו על ביצוע ההזמנה: בדיקות כבדות של הסל הועברו לפעולות נדחות, והסשנים הועברו לאחסון משותף.
- ביצענו ריצת עומס על הקונפיגורציה היעד ותיעדנו את הספים שמעליהם אנחנו מרחיבים את האפליקציה.
אחרי התיקונים עמוד הקטלוג נמסר תוך 0.6 שניות, שיעור כשלי השרת נשאר בטווח של 0.3%, והסביבה מעבדת באופן יציב עד 1,500 בקשות בשנייה בלי גידול בזמן התגובה. הזמנות שאבדו קודם בשיא מגיעות כעת עד לתשלום — על אותו סטאק של 1C-ביטריקס שחזרנו את סכמת האופטימיזציה בשני פרויקטים נוספים.
מה לעשות אם האתר כבר פעיל ואי אפשר לעצור אותו?
ביקורת ביצועים לא דורשת לעצור את האתר: השינויים נבדקים על עותק, ולסביבה החיה מעבירים אותם בחלקים. מבצעים עותק מלא — קבצים, בסיס נתונים, קונפיגורציית סביבה — ופורסים סביבה נפרדת עם אותן גרסאות של הפלטפורמה והמודולים.
עליה משחזרים את העומס לפי הלוגים: איפה המטמון לא עובד ומה נתקע בבסיס הנתונים. את התיקונים בודקים כאן: טעות על עותק לא עולה דבר.
בהמשך מחלקים את השינויים לפי סיכון. מה שלא משנה את מבנה הנתונים ואת החוזים החיצוניים — הגדרות הטמנה, אינדקסים, הגשת סטטיקה, פרמטרים של הסביבה — מיושם על האתר הפעיל בלי עצירה ומבוטל בפקודה אחת.
שינויים בסכמה מוציאים בשלבים תואמים לאחור: קודם מוסיפים שדה חדש וכותבים לשני המקומות, אחר כך מחליפים את הקריאה, ורק לאחר עבודה יציבה מסירים את הישן.
ההחלפה מתבצעת בחלקים: קודם על חלק מהתנועה, תחת בקרת מדדים. אם זמן התגובה או שיעור השגיאות עולים — מחזירים את הגרסה הקודמת, והמבקרים לא מבחינים בכך.
נשארות פעולות שאי אפשר לבצע במקביל: בנייה מחדש של טבלאות גדולות, החלפת אחסון, עדכון הפלטפורמה. אותן מוציאים לחלון קצר ומתואם — בדרך כלל של דקות, כי ההכנה והבדיקות נעשו מראש על העותק.
הסיכון העיקרי אינו התיקון עצמו אלא תלות שלא הובאה בחשבון: מטמון שלא מתאפס, רפליקה מפגרת, סשנים הקשורים לצומת. לפני ההעלאה מתעדים מדדי בקרה — זמן תגובה, שיעור שגיאות, תורי משימות — ומשווים אליהם כמה ימים. תוכנית החזרה מוכנה מראש.
ספקות בנוגע למדידות, עומס והרשאות
מדידות מדויקות במידה שבה תנאיהן תועדו מראש. להלן תשובות לספקות טכניים שעולים לרוב לפני ההתחלה וקובעים אילו נתונים יידרשו ומה בדיוק מושווה לפני ואחרי התיקונים.
עד כמה המדידות מדויקות אם התנועה אינה קבועה?
מודדים מדדים בשני מצבים: על קבוצת עמודים קבועה ועל תנועה חיה בפרק זמן בר-השוואה. הראשון נותן חזרתיות והערכה של תיקון בודד, השני — התנהגות תחת תורים והתפרצויות.
הפער ביניהם הוא אינדיקציה: ריצה מהירה כשהעמודים האמיתיים איטיים מצביעה על נעילות בבסיס הנתונים או על מטמון שלא מנוצל מחדש.
אילו הרשאות צריך כדי להתחיל?
מספיקות גישה לאזור הניהול, לעותק של בסיס הנתונים וללוגים של שרת האינטרנט. את האבחון מנהלים על העותק — בסביבה החיה לא מבצעים תיקונים, כדי שצווארי הבקבוק ישתחזרו בלי להשפיע על המשתמשים. לוח ניטור מזרז את הניתוח, אבל אינו חובה.
איך להבין מה מאט: בסיס הנתונים או התבנית?
מפרידים לפי פרופיל השאילתות. אם הזמן הולך על שליפות, נעילות וחיבורי טבלאות כבדים — זה בסיס הנתונים, והוא מטופל באינדקסים, בסכמה ובהטמנת שאילתות. אם בסיס הנתונים עונה מהר אבל העמוד נבנה זמן רב — הבעיה בתבנית וברכיבים: קריאות מיותרות, לולאות לא מאופטמות, מטמון שהוסר.
מה לעשות אם האתר יאט שוב?
אופטימיזציה חוזרת היא חלק מהמחזור, לא סימן לכישלון: הקטלוג גדל, מתווספים מודולים, פרופיל התנועה משתנה. לכן הדוח כולל סט של נקודות בקרה ואת סדר המדידה שלהן, כדי שהתדרדרות תתגלה בשלב מוקדם ולא לפי תלונות.
מה נדרש להערכה וממה נתחיל את העבודה
לאסוף את נתוני הפתיחה זה חצי מהביקורת: בלעדיהם ההערכה הופכת לניחושים וההתחלה נתקעת בהבהרות. להלן רשימה שמסירה את רוב אי-הוודאות. שלחו אפילו חלק — נתחיל לעניינים, ואת החסר נשלים בעצמנו במדידות.
- הרשאות: אזור הניהול של ביטריקס, השרת או לוח האחסון, המאגר, גישה לבסיס הנתונים או דאמפ שלו, לוגים של שרת האינטרנט ושל שאילתות איטיות, לוח ניטור אם קיים.
- תסמינים: מה בדיוק מאט — פתיחת הקטלוג, כרטיס המוצר, ביצוע הזמנה, אזור הניהול, סנכרון עם 1C. חשוב לדעת אם זה אצל כולם או אצל חלק מהמשתמשים, באופן קבוע או בגלים.
- תקופות שיא: שעות העומס הגדול ביותר, ימי מבצעים והתפרצויות פרסום, זמני ייצוא מחירונים וסנכרון עם מערכת הנהלת החשבונות.
- היסטוריית שינויים: עדכוני ליבה ומודולים, תבניות חדשות, שינויים בכללי ההטמנה, מעברים ושינויי קונפיגורציה בשרת — במיוחד לפני שהמצב הורע.
- יעדי ביצועים: איזה זמן תגובה נחשב סביר לקטלוג, לכרטיס ולסל; איזה מרווח עומס נדרש; איזו תוצאה נחשבת בלתי קבילה.
- מגבלות: החלון שבו מותר לגעת באתר הפעיל, הסובלנות להפסקות קצרות, דרישות לחזרה לאחור.
בהמשך אנחנו משחזרים את צוואר הבקבוק על פרופיל עומס, משווים למדדים ולקוד וחוזרים עם הערכה ותוכנית עבודה: מה עושים קודם, איזה אפקט זה נותן ואיפה נשארים סיכונים. תארו את המשימה וצרפו את נתוני הפתיחה — נדון ונמסור לוח זמנים.