מדוע בלוקי Highload מאטים את הקטלוג ואת ההזמנות
בלוקי Highload ב-1С-Битрикс הם טבלאות ללא תלות באינפובלוקים, שתוכננו לעשרות ומאות אלפי רשומות: מחירים, מלאי, שיוך מוצרים למחסנים, היסטוריית סטטוסים של הזמנות. כל עוד מספר הרשומות קטן, השליפה לפי מאפיין מתבצעת במהירות, ואיש אינו שם לב שמתחת למכסה כבר טומן בחובו מוקש. אופטימיזציה של בלוקי Highload מתחילה בהבנה של מה בדיוק הופך את ההפשטה הנוחה לצוואר בקבוק.
הבעיה מתגלה עם גידול במספר הרשומות. המפתח מוסיף סינון לפי מאפיין מותאם אישית, אך אין עליו אינדקס — ובמקום חיפוש ממוקד, מסד הנתונים קורא את כל הטבלה. שאילתה אחת כזו בכרטיס מוצר הופכת למאות בעת מעבר על הקטלוג, וזמן התגובה מגיע לשניות.
שאילתות איטיות בקטלוג כמעט תמיד מעידות על דבר אחד: שליפת מאפייני בלוק Highload מתבצעת בסריקה מלאה, ולא לפי אינדקס.
העומס על מסד הנתונים גדל באופן לא ליניארי. כל סריקה מיותרת מחזיקה חיבור, מטמון ה-DBMS נדחק, וכבר נפגעים מדורים שכנים — סל הקניות, ביצוע ההזמנה, האזור האישי. שיא תעבורה או סנכרון מלאי משלימים את התמונה: האתר מתחיל להחזיר פסקי זמן בדיוק במקומות שבהם מאבדים מכירות.
בהמשך נבחן כיצד סוגרים זאת: היכן להוסיף אינדקסים מורכבים, כיצד לשכתב את השליפה באמצעות שאילתות מקובצות, מה להעביר למטמון וכיצד לבנות נוהל עבודה כך שגידול במספר הרשומות לא יפיל עוד את הקטלוג.
מה נותנת אופטימיזציה של Highload-блоків
Highload-блоки ב-1С-Битрикс הם טבלאות ללא תלות באינפובלוקים, המחושבות למאות אלפי ומיליוני שורות. כל עוד הקטלוג קטן, ההבדל אינו מורגש.
אך ברגע שהסינון לפי מאפיין, המיון או תת-שאילתה על טבלה מקושרת נכנסים לשאילתה, זמן השליפה גדל באופן לא ליניארי: מה שבבסיס נתונים לבדיקה הגיב באופן מיידי, בבסיס הפרודקשן מתחיל להיתקל בסריקה מלאה של הטבלה. הקטלוג "נתקע" בדיוק ברגעים שבהם מגיע אליו התעבורה העיקרית.
אופטימיזציה של Highload-блоків היא עבודה עם האופן שבו הנתונים מונחים פיזית וכיצד הקוד שולף אותם.
אנו מסדרים את האינדקסים לפי תרחישי הסינון האמיתיים, מסירים שליפות "ישירות" דרך ORM במקומות שבהם נדרשת שאילתה ממוקדת, שומרים במטמון נתוני עזר שאינם משתנים בין שאילתות, ומפזרים פעולות כבדות לאורך זמן.
כתוצאה מכך, מהירות התגובה של הקטלוג מפסיקה להיות תלויה בכמה מוצרים יש בבסיס הנתונים ובכמה מסננים בחר המשתמש.
אפקט נפרד הוא עמידות בפני עומסי שיא. כאשר כל שאילתה לקטלוג מפסיקה לתפוס חיבור לבסיס הנתונים לשניות ארוכות, השרת מחזיק בשלווה פניות בו-זמניות שבעבר הובילו לתור ולחריגות זמן.
הסרת העומס מהשרת אינה הפשטה: המשאבים שהתפנו עוברים להגשת עמודים ולעיבוד הזמנות, ולא להמתנה לתגובה מבסיס הנתונים.
אנו לא מנחשים, אלא מודדים: מודדים את זמן השליפה בתרחישים אמיתיים לפני ואחרי, בודקים אילו שאילתות נותרות כבדות, וסוגרים בדיוק אותן. כך אופטימיזציה של Highload-блоків נותנת תגובה צפויה של הקטלוג ורזרבה לעומס לצמיחת המגוון העתידית.
דרכים להאצה: אינדקסים, מטמון, דנורמליזציה
בלוק Highload — זה טבלה במסד נתונים, ומהירות השליפה ממנה נקבעת על ידי האופן שבו בנויים האינדקסים ועד כמה часто אנחנו פונים למסד הנתונים עבור אותם נתונים. להלן שלוש גישות עובדות שאנו מיישמים בפרויקטים של 1С-Битрикс, והמגבלות שלהן: אין דרך אוניברסלית, והבחירה תלויה בפרופיל העומס.
| גישה | מתי מתאימה | מגבלות |
|---|---|---|
| אינדקסים מורכבים | סינון תכוף לפי 2-3 שדות בו-זמנית, מיון לפי אחד מהם | מאט את הכתיבה; יש לתכנן את האינדקס עבור שאילתות ספציפיות, ולא "ליתר ביטחון" |
| מטמון שליפות | נתוני עזר שנקראים לעתים קרובות ומשתנים לעתים רחוקות | אי-תוקף: בעת עדכון הבלוק יש לאפס את המטמון, אחרת המשתמש רואה נתונים מיושנים |
| דנורמליזציה | JOIN-ים כבדים בין בלוקים, שדות מחושבים חוזרים | שכפול נתונים וסיכון לחוסר סנכרון — נדרשת לוגיקת סנכרון בעת כתיבה |
אינדקס מורכב עובד רק אם סדר השדות בו תואם את סדר התנאים בשאילתה: אינדקס לפי (עיר, תאריך) יאיץ סינון "עיר + תאריך", אך לא יעזור בשליפה לפי תאריך בלבד.
לכן תחילה מוציאים שאילתות אמיתיות מהלוגים, ורק אחר כך מתכננים את האינדקס — אחרת מקבלים עומס מיותר על הכתיבה בלי רווח בקריאה.
מטמון שליפות נותן את האפקט הגדול ביותר על טבלאות עזר: אם הבלוק משתנה פעם ביום ונקרא אלפי פעמים, המטמון מסיר כמעט את כל העומס ממסד הנתונים. דנורמליזציה — זה אמצעי קיצון: היא מסירה את ה-JOIN, אך מעבירה את המורכבות לקוד הכתיבה, ובלי סנכרון מדויק הנתונים מתפצלים.
בפועל משלבים: אינדקסים עבור סינון ממוקד, מטמון עבור קריאות חוזרות, ודנורמליזציה — רק במקום שבו ה-JOIN אכן הפך לצוואר בקבוק.
כיצד אנו מבצעים אופטימיזציה: שלבי העבודה
אופטימיזציה של בלוק Highload היא לא "להפעיל מטמון ולחכות", אלא רצף של צעדים מדידים. כל שלב מסתיים בארטיפקט: דוח, קונפיגורציה ששונתה, או בדיקה שניתן לחזור עליה. להלן כיצד נראית העבודה מהבקשה הראשונה ועד להעברת הנהלים לצוות שלכם.
-
ביקורת שאילתות. אוספים תעבורה אמיתית לבלוק ה-Highload: אילו שליפות מגיעות מהקומפוננטות, אילו פילטרים ומיון לפי מאפיינים משמשים לרוב, והיכן שאילתות משוכפלות באותו עמוד. בפלט — מפה "עמוד → שאילתה → תדירות", שלפיה רואים מה לתעדף באופטימיזציה.
-
פרופיילינג. מודדים את הזמן של כל שליפה ואת מספר הפניות לבסיס הנתונים בתרחישים טיפוסיים: כרטיס, קטלוג, חיפוש, ייצוא. בנפרד בודקים שאילתות שרצות בלולאה — הן בדיוק אלה שנותנות את הירידה העיקרית עם גידול הנתונים.
-
הגדרת אינדקסים. עבור פילטרים ומיון תכופים מוסיפים אינדקסים בבלוק ה-Highload עצמו, מסירים מיותרים ומסדרים מחדש את סדר השדות באינדקסים מורכבים. בודקים שהשליפה עוברת לאינדקס ולא לסריקה מלאה של הטבלה.
-
עיבוד מחדש של שליפות. מסירים שאילתות בלולאה, מאחדים כפולות, מגבילים את סט השדות ומעבירים תרחישים כבדים לטעינה מדורגת. שומרים במטמון רק את מה שבאמת משתנה לעיתים רחוקות — אחרת מקבלים נתונים מיושנים בכרטיסים.
-
בדיקה תחת עומס. מריצים תרחישים על נפח קרוב לזה של סביבת העבודה, ועם מרווח במספר המשתמשים בו-זמנית. בודקים לא רק את זמן התגובה הממוצע, אלא גם את ההתנהגות בשיא: היכן נוצרות תורים וכיצד מתנהל בסיס הנתונים.
-
העברת נהלים. מתעדים את האינדקסים ששונו, את כללי המטמון ואת רשימת השאילתות שאסור להחזיר לקוד. הצוות שלכם מקבל מסמך שלפיו פיתוחים חדשים לא שוברים את המהירות שכבר הושגה.
הסדר הוא בדיוק כזה: אינדקסים ללא ביקורת מוגדרים לעיתים קרובות על שדות לא נכונים, ובדיקה תחת עומס ללא פרופיילינג לא מראה מה הפך לצוואר הבקבוק. תארו את המשימה שלכם — נחזור עם הערכה ותוכנית עבודה לפי שלבים אלה.
מה הלקוח מקבל לידיו
אופטימיזציה של Highload-בלוקים אינה מסתיימת בתיקון קוד — היא מסתיימת בהעברת תצורה עובדת והוראות ברורות ללקוח. להלן מה שנשאר בדיוק בידי הצוות שלכם לאחר הפרויקט: לא "דוח" מופשט, אלא סט ארטיפקטים שלפיהם ניתן להפעיל ולפתח את המערכת בלעדינו.
- סכמת אינדקסים של Highload-בלוקים — אילו שדות מאונדקסים, אינדקסים מורכבים וסדרם, והנמקה לשאילתות ספציפיות. בנפרד מסומנים אינדקסים שניתן להסיר ללא אובדן מהירות, כדי שהמסד לא יגדל "ליתר ביטחון".
- תצורת מטמון — אילו שאילתות נשמרות במטמון, זמן חיים, קישור לתגים ולאירועי איפוס. מצוין מה מתבטל בעת שינוי ישויות ומה נשאר עד לרענון מתוכנן.
- מפת שאילתות כבדות — רשימת הפניות ל-Highload-בלוקים עם מדידת זמן לפני ואחרי, כדי שיהיה נראה היכן בדיוק עזב העומס, ולא "נהיה מהיר יותר באופן כללי".
- נוהל תחזוקה — תדירות בנייה מחדש של אינדקסים, בדיקת גידול טבלאות, בקרת שאילתות איטיות, נקודות לניתוח מתוכנן. עם קישור לאירועים: אכלוס קטלוג, ייבוא, גידול עונתי בתעבורה.
- תיעוד מבנה — תיאור שדות, קשרים ולוגיקת שאילתות: מה ולשם מה נשמר ב-Highload-בלוקים, אילו קשרים קריטיים. מפתח חדש נכנס לפרויקט לפי מסמך, ולא לפי התכתבות.
- הוראות rollback — אילו שינויים הפיכים, היכן נשמרות גרסאות התצורה המקוריות, כיצד להחזיר את ההתנהגות הקודמת ללא אובדן נתונים.
- צ'ק-ליסט בדיקה לאחר שחרור — סט מדידות בקרה שלפיהן הצוות שלכם מאשר בעצמו שהאופטימיזציה מחזיקה תחת עומס.
כל ארטיפקט מקושר לקבצים ולהגדרות אמיתיים של הפרויקט, ולא למדריך כללי. תארו את המשימה שלכם — נחזור עם הערכה ותוכנית, מה מהרשימה הזו נסגור ראשון.
מקרה בוחן: האצנו את שליפת המאפיינים פי 6
קטלוג על 1С-Битрикс עם בלוקים בעומס גבוה: מאפייני המוצרים ישבו ב-HL-block, וכל כרטיס משך אותם בשאילתה נפרדת.
עם 40 אלף פריטים ומסננים לפי 8 מאפיינים, עמוד הקטלוג נבנה ב-4.8 שניות, ותחת עומס של 300 מבקרים בו-זמניים זמן השליפה הגיע ל-9 שניות — חלק מהשאילתות נפלו בגלל timeout, והקטלוג החזיר אריחים ריקים.
מה היה לפני
הבעיה לא הייתה בנפח הנתונים, אלא באופן הגישה. הקוד עבר על המוצרים בלולאה ובכל איטרציה משך מה-HL-block את המאפיינים — N+1 קלאסי. אינדקסים על שדות משתמש לא היו, והמסנן הרכיב תנאים על עמודות לא מאונדקסות, ולכן מסד הנתונים סרק את הטבלה כולה. המטמון לא עזר: הוא בוטל בכל שינוי של מחיר או מלאי, כלומר כמעט כל הזמן.
מה שינינו
את שליפת המאפיינים כתבנו מחדש לשאילתה מקובצת אחת עם סינון לפי מערך מזהים במקום לולאה — במקום מאה פניות למסד הנתונים לכל עמוד נשארה אחת. הוספנו אינדקסים מורכבים לפי צירופי המסננים בפועל, והוצאנו מאפיינים שמשתנים לעיתים רחוקות לשכבת מטמון נפרדת עם זמן חיים ארוך. אגרגטים כבדים למיון חישבנו מראש ומעדכנים באירוע שינוי מוצר, ולא בכל הצגה.
מה נהיה
זמן שליפת המאפיינים בעמוד הקטלוג ירד מ-4.8 ל-0.8 שניות — פי 6. תחת מבחן עומס של 300 מבקרים בו-זמניים זמן התגובה נשמר בטווח של 1.3 שניות, אין timeouts, והקטלוג מחזיר כרטיסים מלאים.
עלויות מסד הנתונים הפסיקו לגדול יחד עם המגוון: הוספת פריטים חדשים כבר לא מאריכה את השליפה באופן ליניארי, כי מספר השאילתות לכל עמוד אינו תלוי בכמות המוצרים.
יציבות הקטלוג אושרה במבחן עומס חוזר לאחר ההעלאה — בשיא המבצע ההתנהגות אינה שונה מסביבת הבדיקות.
במה שונה Highload-בלוק מאינפובלוק?
אינפובלוק ו-Highload-בלוק פותרים משימות שונות, והבלבול ביניהם הוא הסיבה הנפוצה ביותר לירידת ביצועים בביטריקס. אינפובלוק הוא ישות תוכן: יש לו שיוך למדורים, מאפיינים, שיוך לאתר, הרשאות, גרסאות, אינדקס חיפוש וכל השכבה הנלווית.
Highload-בלוק הוא טבלה שטוחה במסד נתונים עם מינימום עטיפה: רק שדות ואינדקסים, בלי מדורים, בלי אינדקס חיפוש, בלי JOIN-ים מיותרים.
ההבדל מתגלה בנפח. כל עוד באינפובלוק יש עשרות או מאות רשומות, בחירת המאגר כמעט אינה משפיעה על זמן התגובה.
כשמדובר במאות אלפים ומיליוני שורות — ספרי ערים, היסטוריית הזמנות, שיוך מוצרים למאפיינים — האינפובלוק מתחיל להאט: השליפה גוררת אחריה טבלאות שירות, והסינון לפי מאפיינים עובר דרך קשרים נפרדים.
Highload-בלוק נקרא ישירות מהטבלה שלו, ושאילתה לפי שדה מאונדקס מתבצעת בזמן צפוי מראש ללא תלות בכמה שורות נמצאות לצדו.
מבנה הנתונים כאן הוא עצמו האופטימיזציה. ב-Highload-בלוק אתם קובעים בעצמכם את סוגי השדות והאינדקסים, ולכן אינדקס מורכב על הצמד «מוצר + מאפיין» או «משתמש + תאריך» מסיר את העומס העיקרי.
באינפובלוק שליטה כזו מוגבלת: חלק מהסינונים עוברים למאפיינים, והם נשמרים בנפרד ומתחברים בכל שאילתה. מכאן התרחיש האופייני: נתוני עזר ומקשרים מועברים ל-Highload-בלוק, ואילו הוויטרינה, המדורים וכל מה שנערך דרך הממשק נשארים באינפובלוק.
גם הטעות ההפוכה יקרה. אם מניחים ב-Highload-בלוק משהו שבמהותו הוא תוכן — מאמרים, עמודים, מוצרים עם מדורים — מאבדים את מנגנוני הפלט התקניים, את הירושה של הרשאות ואת החיפוש, ואחר כך מוסיפים אותם ידנית.
בחירת המאגר נקבעת לא לפי אופנה, אלא לפי האופן שבו הנתונים נקראים: אם נדרשות שליפות המוניות לפי שדות מאונדקסים והנפח גדל — Highload-בלוק; אם נדרש תוכן עם מדורים, הרשאות וממשק עריכה — אינפובלוק.
בפועל מערכות הן כמעט תמיד היברידיות: אינפובלוק אחראי על התוכן, Highload-בלוק — על ספרי עזר וקשרים בין ישויות. אנחנו מנתחים את מבנה הנתונים ואת פרופיל השאילתות לפני שמשנים משהו, — ואז ההעברה נוגעת רק באותן טבלאות שבהן היא באמת מניבה רווח בזמן התגובה.
ספקות טכניים נפוצים
בלוקים של Highload ב-1С-Битрикс הם טבלאות במסד נתונים נפרד לעומס גבוה: השאילתות מתבצעות ישירות, ללא עטיפת ORM, וכל שגיאה באינדקסים או במטמון מתגלה מיד בפרודקשן. להלן מה שלרוב מבררים לפני תחילת עבודות האופטימיזציה.
אילו אינדקסים נדרשים והאם הוספתם תשבור שאילתות קיימות?
אינדקס נבנה עבור תבנית שאילתה ספציפית: הרכב השדות ב-WHERE, סדר המיון, תנאי טווח. הוספת אינדקס אינה משנה את תוצאת השאילתה — המתכנן או מתחיל להשתמש בו, או משאיר את התוכנית הקודמת, ולכן אין רגרסיה בנתונים. הסיכון שונה: אינדקסים מיותרים מאטים הכנסה ועדכון.
לכן תחילה אוספים שאילתות אמיתיות מהלוגים, ולא מוסיפים "ליתר ביטחון", ולאחר בדיקה מסירים את אלו שאינם בשימוש.
האם יהיה צורך לאפס את המטמון בכל עדכון נתונים?
לא, אם מבצעים caching לפי מפתח נכון. אנחנו מצמידים את המטמון לפרמטרי השאילתה ולתגים שמשתנים יחד עם הנתונים: רשומה עודכנה — רק החלק המקושר מתבטל, והשאר ממשיך לחיות. איפוס מלא נדרש נקודתית, בעת שינוי מבנה הבלוק או הרכב השדות. גישה כזו מסירה החמצות מטמון מתמידות ומפחיתה את העומס על מסד הנתונים פי כמה.
האם השינויים תואמים לקוד הקיים ולעדכוני הפלטפורמה?
כן. אנחנו לא נוגעים בליבה ולא מתקנים רכיבים סטנדרטיים — עובדים דרך המטפלים שלנו, הגדרות האינדקסים ותצורת המטמון. עדכוני הפלטפורמה והמודולים עוברים כסדרם, מכיוון שהשינויים נמצאים מחוץ לקבצים המתעדכנים. לפני העלאה מריצים תרחישי מפתח על עותק ומשווים את הפלט לפני ואחרי.
כיצד לבצע rollback אם משהו ישתבש?
כל שלב הוא תיקון נפרד עם נקודת חזרה: אינדקסים מוסרים בפקודה אחת, הגדרות המטמון חוזרות לערכים הקודמים, שינויים בקוד — דרך מערכת בקרת גרסאות. מעלים בשלבים, עם מדידת זמן תגובה בכל שלב, ולכן ה-rollback אורך דקות ואינו דורש עצירת האתר.
בואו נדון במשימת האופטימיזציה שלכם
כדי לחזור עם הערכה ותוכנית, ולא עם מילים כלליות, אנחנו צריכים מינימום של נתוני פתיחה על התצורה שלכם.
אופטימיזציה של בלוקים ב-highload כמעט תמיד נתקלת באופן שבו בנויים האינדקסים, אילו שאילתות מתבצעות עם פילטרים ומיון, ובאיזו תדירות הנתונים משתנים — מזה תלוי מה יניב אפקט: בנייה מחדש של אינדקסים, מטמון (קשינג) של שאילתות או העברת חלק מהלוגיקה לשכבה נפרדת.
שלחו את מה שיש בהישג יד — משם אנחנו כבר נבין מה חסר:
- תיאור המשימה: היכן בדיוק יש האטה — קטלוג, פילטר, אזור אישי, ייצוא, אינטגרציה עם 1С;
- מבנה בלוקי ה-highload: אילו שדות, אילו קשרים, נפח רשומות משוער וקצב הגדילה;
- דוגמאות לשאילתות כבדות או ייצוא מיומן השאילתות האיטיות;
- כיצד בנויים כיום המטמון (קשינג) ועדכון הנתונים — לפי לוח זמנים, לפי אירוע, ידנית;
- גישות לסביבת בדיקה או קונטור בדיקה שבו אפשר לשחזר עומס בלי סיכון לאתר הפעיל;
- מגבלות: חלון הזמן שבו מותר לבצע עבודות, ומה אסור לגעת בו בלוגיקה הנוכחית.
אם אין נתונים מדויקים — לא נורא: תארו במילים מה קורה ומתי זה התחיל. נשאל שאלות הבהרה לגבי אינדקסים, שאילתות מורכבות והחיבור ל-1С, ואחרי האודיט נחזור עם תוכנית עבודה, לוחות זמנים ומה השיפור בזמן התגובה שהיא נותנת. תארו את המשימה — נדון בפרטים ונציע פתרון.