הגדרת query cache MySQL: היכן מתבזבזת המהירות
קטלוג עם מסננים, עגלת קניות ואזור אישי ב-1С-Битрикс פונים למסד הנתונים בכל בקשה: סינון לפי מאפיינים, מלאי, מחירים, הנחות, היסטוריית הזמנות. בקטלוג פעיל מדובר בעשרות שליפות מאותו סוג לעמוד אחד, וכל אחת עוברת מחדש ניתוח שאילתה, בניית תוכנית וקריאה מהדיסק.
כשמספר המבקרים קטן, זמן התגובה נשאר תקין — בשעות עומס זמן התגובה של הקטלוג עולה פי כמה, אף שהנתונים במסד לא השתנו.
חלק מהעומס הזה לא נותן דבר: אותן שאילתות לספריות עזר, להצעות מסחריות ולהגדרות מבוצעות שוב ושוב, והעמודים נבנים מחדש במקום לקבל תוצאה מוכנה. מטמון השאילתות של MySQL נוצר בדיוק עבור חזרות כאלה — תוצאה מוכנה מוחזרת מהזיכרון בלי לפנות לטבלאות.
הגדרת query cache mysql בלי לנתח את תמונת השאילתות לא פותרת את הבעיה. אם הכול נכנס למטמון בלי הבחנה, הוא נעשה מפוצל ומפריע יותר משהוא עוזר, וכל כתיבה לטבלה מאפסת את כל התוצאות השמורות שלה — בקטלוג פעיל זה קורה כל הזמן.
מכאן גם שאילתות איטיות ב-Битрикс: היעדר אינדקסים למסננים מסוימים, שליפות לפי מאפיינים לא מאונדקסים, חיבורי טבלאות כבדים.
העלייה בעומס על מסד הנתונים של האתר כמעט תמיד מורכבת מכמה סיבות בבת אחת, וצריך לטפל בהן יחד. אנו מפרקים כיצד מטפלים בכך: אוספים סטטיסטיקה על שאילתות, מפרידים בין שאילתות חוזרות לכבדות, ומגדירים מטמון ואינדקסים בהתאם לשליפות בפועל.
מה נותן מטמון שאילתות מוגדר: זמן תגובה ועומס
מטמון שאילתות מחזיר תוצאה מוכנה אם הגיעה שאילתה עם אותם פרמטרים — מסד הנתונים לא מנתח את הטקסט מחדש ולא עובר על הטבלאות. ב-1С-Битрикс זה עובד יחד עם מטמון רכיבים ועמודים, ולכן מגדירים את השכבות באופן מתואם: אם אחת מאפסת את השנייה, לא יהיה רווח.
זמן בניית העמוד
קטלוג, כרטיסי מוצר וקטגוריות נבנים מעשרות פניות מאותו סוג למסד הנתונים. כשהן נענות בתוצאה מוכנה, בנייה חוזרת של העמוד מואצת פי כמה, ופיזור זמני התגובה בין הפנייה הראשונה לפניות הבאות מצטמצם — האתר מגיב באופן צפוי, ולא "אחת כן ואחת לא".
שיעור השאילתות שנענות בתוצאה מוכנה
האפקט מדיד: בנפרד מחשבים כמה פניות נענו מהמטמון וכמה עברו לשליפה מהטבלאות. בקטלוג פעיל רוב השאילתות החוזרות לא אמורות להגיע למסד הנתונים — זה מה שנותן הפחתה בעומס על MySQL, ומפנה משאבים למה שאי אפשר למטמון: עגלת הקניות, ביצוע הזמנה, מלאי.
שעות שיא וסוג הכשלים
במבצעים ומכירות מספר המבקרים בו-זמנית עולה בקפיצה, ומטמון לא מוגדר הופך לתור חיבורים. עם מטמון מסד הנתונים מפסיק להיות צוואר בקבוק: סוג שלם של כשלים מוסר — מיצוי חיבורים, פסקי זמן, שגיאות בהחזרת עמודים. עומס השיא של חנות מקוונת מפסיק לדרוש מלאי חומרה כפול ומשולש.
ההגדרה אינה חד-פעמית: כללי איפוס, זמן חיים של רשומות וחימום מטמון לאחר העלאת עדכון נבדקים במדידות לפני ואחרי — אחרת היציבות תחת עומס מחזיקה מעמד עד העדכון הגדול הראשון של הקטלוג.
השוואת גישות למטמון שאילתות ב-MySQL
מטמון שאילתות מתפרש לשלוש שכבות: מנוע מסד הנתונים, מטמון מנוהל עם ביטול תוקף לפי תגיות ומטמון בצד האפליקציה. בחירת השכבה קובעת לא כל כך את מהירות ההחזרה, אלא את הדיוק והמהירות של ביטול התוקף בעת שינוי נתונים, ומזה תלוי אם המבקר יראה מחיר ומלאי מעודכנים.
מטמון השאילתות המובנה של MySQL מחזיר תוצאה בלי לנתח מחדש את התוכנית, אבל מאפס את כל מה שנצבר בכל הטבלה: עריכה של שורה אחת בקטלוג מאפסת את כל המערך.
בענפים עדכניים של MySQL המנגנון הזה הוסר, ולכן בפרויקטים על 1С-Битрикс הוא לא נחשב למצב מטמון עיקרי — הוא נשאר אולי רק במערכות ישנות עם עומס קריאה בעיקרו.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| מטמון מובנה בצד מסד הנתונים | שליפות לקריאה, כתיבות נדירות, שרת אחד | איפוס של כל הטבלה בכל כתיבה; בענפים עדכניים של MySQL אינו קיים |
| מטמון מנוהל עם ביטול תוקף לפי תגיות | רכיבים ובלוקי מידע עם תלויות ברורות: קטלוג, קטגוריות, עמודי מוצר | נדרשת הצבת תגיות נכונה; תגית שגויה גורמת לפספוס ולאיפוס מיותר של קבוצה |
| מטמון בצד האפליקציה | שליפות מחושבות, אגרגטים, חיבורים כבדים, דוחות | אין ביטול תוקף אוטומטי — איפוס לפי אירוע; סיכון להחזיר נתונים מיושנים |
הפתרון העובד הוא שילוב: תגיות מכסות רכיבי תוכן, האפליקציה מטפלת באגרגטים, ומטמון מסד הנתונים המובנה נשאר כמסייע. את ההרכב מתאימים לפי מדידות בפרופיל העומס שלכם.
שלבי הגדרת המטמון: אבחון, סכמה, בדיקה
שינויים בפרמטרי המטמון בלי מדידות מקדימות נותנים תוצאה בלתי צפויה: צוואר הבקבוק נמצא לעתים קרובות בשליפה כבדה אחת של הקטלוג, ולא בגודל החוצץ. לכן אנו עובדים בסדר קבוע — מפרופיל השאילתות לסכמת המטמון, ורק אחר כך לשינויים בתצורה.
- אבחון שאילתות איטיות. מפעילים יומן שאילתות איטיות ומצלמים פרופיל על תעבורה אמיתית: אילו שליפות מחזיקות חיבור, כמה פעמים הן חוזרות, והיכן חסר אינדקס.
- סכמת מטמון. מסמנים מה מכוסה באמצעי הפלטפורמה ברמת רכיבים ובלוקי מידע, ומה — במטמון השרת; קובעים זמן חיים של רשומות ונקודות האיפוס שלהן.
- שינויי תצורה. מגדירים פרמטרים של מטמון שאילתות ואינדקסים חסרים, מכבים מטמון לשליפות שמשתנות בכל פתיחת עמוד.
- חימום מטמון הקטלוג. לאחר הניקוי עוברים על קטגוריות וכרטיסים עם סורק — שליפות כבדות נאספות מראש, ולא בביקור הראשון.
- בדיקת עומס. חוזרים על הפרופיל ומשווים: זמן שאילתות כבדות, מספר הפניות למסד הנתונים לעמוד, זמן תגובת הקטלוג במבקרים בו-זמנית.
- נוהל תחזוקת מטמון. מוסרים מסמך: מה מנטרים, באילו עריכות תוכן מאפסים מטמון, ואיך מחזירים פרמטרים אם זמן התגובה ירד.
תצורות, סכמות מטמון ונוהלים
תיעוד לא נכתב "כדי לצאת ידי חובה" — הוא צריך לעבוד בעוד חצי שנה, כשבצוות הלקוח מתחלף מפתח וצריך להבין למה בלוק מחזיר נתונים מיושנים. לכן תוצאת העבודה היא ערכה שלפיה מהנדס חדש נכנס לפרויקט בלי לחפור בהתכתבויות, והתורן מבין מה לעשות בחריגה.
- קובצי תצורה עם הערכים בפועל: מה מופעל, אילו מגבלות הוגדרו ולמה דווקא כך, אילו פרמטרים נגעו בהם ואיזו השפעה הייתה לכך.
- מפת אזורי מטמון וביטול תוקף: עבור כל בלוק — מה נשמר במטמון, באילו תגיות סומן, איזה אירוע מאפס ובאיזה השהיה.
- סכמת קשרים בין רכיבים: היכן המטמון משותף, היכן מבודד, ואילו בלוקים תלויים באותם נתונים ומבוטלים יחד.
- נוהל חימום מטמון: סדר מעבר על עמודים לאחר פרסום וניקוי, כדי לא להעמיס על מסד הנתונים במכה אחת.
- נוהל ניטור: אילו מדדים בודקים, אילו ערכים נחשבים לתקינים, באילו חריגות מתערבים ומה בודקים קודם.
- תזכיר למפתח: איך מוסיפים בלוק חדש למטמון, אילו תגיות להציב, ואילו מבנים שוברים את ביטול התוקף ולמה.
- סדר מסירה: סקירה עם הצוות שלכם, תשובות לשאלות בכל אזור ונקודות בקרה שבהן רואים שההגדרות התקבעו.
כל זה נמצא לצד הקוד במערכת בקרת גרסאות, ולא בתיקייה נפרדת בדיסק. שינויים בתצורת המטמון עוברים דרך סקירת קוד רגילה — הנוהל לא מתיישן חודש אחרי מסירת הפרויקט.
מקרה בוחן: הקטלוג גדל פי שלושה, זמן התגובה נשאר כשהיה
הקטלוג גדל מכ-10,000 ל-30,000 פריטים בערך, וזמן התגובה של הקטגוריות החל לרדת בכל מעבר: חלק מהעמודים נבנו מחדש, אף שהנתונים בין השאילתות לא השתנו.
לרכיבי הרשימה וכרטיס המוצר לא היו תגיות מטמון תקינות, ולכן כל עדכון מחיר או מלאי איפס את כל השכבה כולה, ושליפות הסינון והמיון עקפו את מטמון השאילתות של MySQL.
את הניתוח התחלנו ביומן השאילתות האיטיות ובתוכניות הביצוע — מצאנו שליפות לפי שדות מיון לא מאונדקסים שבוצעו בכל פנייה.
רשימת המוצרים הועברה לאינדקס מורכב ולתצוגה מדורגת בלי ספירה חוזרת של הכמות הכוללת, והפעלנו מטמון רכיבים עם תגיות נפרדות לבלוק מידע, לקטגוריה ולכרטיס: עריכה של מוצר אחד מאפסת כעת רק צמתים קשורים, ולא את כל הקטלוג.
| מדד | לפני | אחרי |
|---|---|---|
| זמן תגובה חציוני של קטגוריית קטלוג | 2.4 שנ' | 0.7 שנ' |
| שאילתות למסד הנתונים לעמוד קטלוג | 310 | 40 |
| שיעור השאילתות שנכנסו למטמון | 21% | 88% |
| עמודים שהוחזרו בלי בנייה | 12% | 74% |
| חיבורים בו-זמניים למסד הנתונים בשיא | 240 | 90 |
בנפרד הגדרנו זמן חיים של שכבות וחימום ברקע: מנגנון המטמון המתויג של 1С-Битрикс איפשר לאפס רק צמתים שנפגעו, והחימום החזיר עמודים מעודכנים לפני הגעת התעבורה.
עומס השיא הפסיק להיתקל במגבלת מסד הנתונים, וכעת אפשר להרחיב את הקטלוג בלי לבנות מחדש את סכמת המטמון — התנהגות כזו אנו בודקים בכל גרסה.
במה שונה מטמון שאילתות ממטמון עמודים
HTML מוכן של עמוד ותוצאת שליפה בודדת — שתי שכבות מטמון שונות ב-Битрикс. שכבת העמודים מחזירה תשובה שכבר נבנתה, והמבקר לא ממתין להרצת רכיבים.
שכבת השאילתות פועלת נמוך יותר: היא מחזיקה את התוצאה של פנייה מסוימת למסד הנתונים, ולכן אותן שליפות לא מבוצעות שוב, ואסור לבלבל בין המנגנונים בהגדרה.
זמן החיים של המטמון נקבע בנפרד לכל שכבה. תיאורי מוצרים, קטגוריות קטלוג וספריות עזר משתנים לעתים רחוקות — מחזיקים אותם שעות. מחירים ומלאי תלויים במחסנים ומתעדכנים כל הזמן, ולכן עבורם זמן החיים קצר, אחרת הקונה יזמין משהו שכבר אין.
המנוף השני — איפוס מטמון לפי אירוע. לשליפה מצמידים תגיות: מוצר, קטגוריה, מחסן. כשהנתונים משתנים, רשומות מסומנות מתאפסות מיד, בלי להמתין לפקיעת התוקף. זה מסיר את הפשרה העיקרית: אין צורך לבחור בין רעננות למהירות — תוכן נשמר במטמון זמן רב, ובלוקים תלויים מתעדכנים בנפרד.
מטמון השאילתות המובנה של MySQL בענפים עדכניים נחשב למיושן, ולכן תוצאת שליפות כבדות נשמרת באחסון חיצוני, והשכבה המשולבת מחזירה עמודים מוכנים למבקרים אנונימיים. כך עדכניות המחירים והמלאי מובטחת באמצעות אירוע, ולא באמצעות זמן חיים קצר של כל המטמון.
לפני ההגדרה אנו מודדים את התנהגות הקטלוג: כמה שאילתות מתבזבזות ומה קורה בעת עדכון מוצר. לפי המספרים האלה רואים היכן המטמון עוזר והיכן הוא רק מסווה צוואר בקבוק.
שאלות טכניות שנשאלות לפני ההתחלה
לפני תחילת העבודה לקוחות שואלים אותן שאלות טכניות — ואלו שאלות נכונות. אנו עונים עליהן לפני הערכה, כדי שגבולות העבודה יהיו ברורים מראש, ולא יתבררו תוך כדי תנועה.
בנפרד לגבי מסד הנתונים: מטמון השאילתות הסטנדרטי בענפים עדכניים של MySQL מושבת כברירת מחדל, ואין טעם להפעיל אותו מחדש — את הרווח נותנת עבודה עם אינדקסים ושליפות כבדות. צוואר בקבוק נקבע לפי מדידות, לא לפי ניחושים.
המטמון מופעל, והאתר בכל זאת איטי — למה?
מטמון מופעל לא אומר עובד: חלק מהעמודים חיים עם זמן קצר, חלק מתאפסים כמעט בכל פנייה. מחשבים את שיעור הפגיעות ובודקים אילו שאילתות עוברות למסד הנתונים — צוואר הבקבוק נמצא לעתים קרובות בשליפות כבדות של הקטלוג, ולא במטמון עצמו.
איך לא להציג מחירים מיושנים אחרי ייבוא?
איפוס נעשה לפי אירועים: עריכת מחיר או מוצר מסירה רק ענפים קשורים, לא את כל המטמון. זמני החיים מופרדים — מחירים ומלאי מתעדכנים часто, תיאורים ותמונות לעתים רחוקות, ולכן מיושן просто לא מוצג.
האם צריך לתקן קוד של רכיבים?
שינויים בליבה וברכיבים סטנדרטיים יימחקו בעדכון הראשון. אנו עובדים דרך רכיבי ירושה, תבניות ומטפלי אירועים: לוגיקת המטמון נשמרת, עדכוני הפלטפורמה עוברים בשלום, ובהעברה לאתר אחר שום דבר לא הולך לאיבוד.
איך להבין אם מסד הנתונים מאט או התבניות?
מודדים שלושה מקטעים: שאילתות למסד הנתונים, בניית תבניות ופניות חוץ. מסד נתונים מהיר עם בנייה ארוכה — הבעיה בתבניות ובקריאות מיותרות; התמונה ההפוכה — בשאילתות ובאינדקסים. מתקנים את מה שבאמת מאט.
מה קורה למטמון בעת סנכרון עם 1С?
החלפה מתבצעת במנות, אחרי כל אחת הנתונים בקטלוג משתנים: בלי איפוס חלק מהכרטיסים נשארים ישנים. מאפסים את המטמון בסיום ההחלפה, אבל לא לגמרי — אחרת האתר נבנה מחדש אחרי כל מעבר ושומר על עומס באופן תמידי.
נדון במשימה ונחזור עם הערכה ותוכנית
כדי שהשיחה תהיה עניינית, ולא "נסתכל ונאמר", מתחילים בסימפטומים ובהרשאות. תארו מה בדיוק מאט: קטלוג ומסננים, עגלת קניות וביצוע הזמנה, אזור ניהול או החלפה עם 1С — ובאילו שעות ההידרדרות מורגשת ביותר. זה כבר מספיק כדי לשער היכן מטמון השאילתות אינו עובד כלל או מתאפס לעתים קרובות מדי.
מה צריך כדי להתחיל:
- הרשאות: פאנל ניהול אחסון, תצורת שרת אינטרנט, גישה לשרת ולמסד הנתונים, מאגר הפרויקט.
- תמונת מצב נוכחית: פרמטרי מטמון, קובצי תצורה, יומן שאילתות איטיות.
- תיאור סימפטומים: עמודים מסוימים, תרחישים ושעות שבהן האתר מגיב לאט.
- חלון עבודה: זמן מוסכם לשינויים ולהפעלה מחדש של שירותים בלי לאבד הזמנות.
- איש קשר של מהנדס תורן שיאשר פעולות בסביבת הייצור.
בתגובה אנו שולחים תוכנית עבודה למטמון: מה משנים בהגדרות, אילו שאילתות כותבים מחדש, כיצד מפרידים בין שכבות המטמון ומה עושים עם ביטול התוקף בעת עדכון הקטלוג והמחירים. ההערכה מגיעה יחד עם סדר השלבים — מאבחון ועד העלאה, עם נקודת חזרה בכל שלב.
תארו את משימת האצת האתר — נחזור עם הערכה, תוכנית ושינויים צפויים במדדים: זמן תגובה, שיעור השאילתות שנענו מהמטמון, ועומס על הדיסק.