Varnish עבור Bitrix: היכן הקטלוג מאבד מהירות
הקטלוג ב-Bitrix נבנה מחדש בכל בקשה: מאפייני מוצרים, הצעות מסחריות, מחירים עם הנחות, מלאי לפי מחסנים, מדורים וסינון חכם. מטמון המערכת מסייע חלקית — בכתובות עם פרמטרי סינון, עימוד וחישוב מחדש של הנחות הוא או שאינו פועל, או שמתאפס. זמן יצירת עמוד קטלוג בכתובות כאלה נמדד בשניות, וכל מבקר חדש מפעיל בנייה מאפס.
בשיא — תפוצת דיוור, פרסום, מבצע — זה הופך לתור. העומס על שרת הקטלוג גדל באופן לא ליניארי: שאילתות למסד הנתונים נערמות, חלקן ממתינות לשחרור חיבורים, והאפליקציה עסוקה בהרכבת אותם עמודים עבור אנשים שונים. הסימן הראשון הוא פסקי זמן בעומס שיא: חלק מהבקשות נופלות, המבקר רואה עמוד ריק ועוזב.
הפעלה פשוטה של מטמון אינה פותרת את הבעיה. מבקר מחובר, סל קניות, מחירים אישיים ומלאי מעודכן הופכים את העמוד לייחודי, ולכן המטמון מתאפס בכל שינוי של מוצר, וייצוא לילי מנקה אותו כולו.
כאן נכנס Varnish — שכבה לפני האפליקציה, שמוסרת עמוד שכבר נבנה ומעבירה בקשה פנימה רק כאשר אין באמת נתונים.
בהמשך נפרט כיצד זה נסגר: אילו מדורי קטלוג ניתן להגיש מהמטמון, כיצד להגדיר ביטול תוקף לפי אירועים כדי שמחירים ומלאי לא יתיישנו, וכיצד להסיר עומס ממסד הנתונים בשיא.
מה נותן Varnish ב-Bitrix: זמן תגובה ועמידות
Varnish מותקן לפני שרת האינטרנט ומגיש עמודים שנבנו מהזיכרון — האפליקציה ומסד הנתונים אינם משתתפים בבקשה כזו. עבור הקטלוג זהו תרחיש מפתח: רשימות, כרטיסים, סינונים ומדורים נוצרים מחדש בכל הצגה, אף שהם משתנים לעיתים רחוקות.
זמן התגובה של העמוד בבקשות חוזרות יורד פי 10–20: במקום בנייה מלאה עם פנייה למסד הנתונים, הלקוח מקבל תשובה מוכנה מיד. באותו שיעור גדל מספר המבקרים בו-זמנית שהשרת מחזיק — מהאצת הקטלוג נהנים גם הקונה וגם רובוט מנוע החיפוש.
מטמון הקטלוג של Bitrix מפחית את העומס על מסד הנתונים באופן משמעותי: הצגה אחת של רשימה היא עשרות שאילתות עבור מאפיינים, מחירים, מלאי, הנחות והצעות מסחריות, וכאשר יש פגיעה במטמון הן אינן חוזרות. המשאב שהתפנה עובר לחיפוש, לביצוע הזמנות ולסנכרון עם 1C.
עמידות תחת עומס — האפקט השלישי. נעלם סוג התקלות «זינוק בתעבורה → עומס יתר על מסד הנתונים → עלייה בזמן התגובה → שגיאות במקום עמודים»: המטמון מגיש תוכן בזמן שהאפליקציה מתאוששת. עדכון מחירים ומלאי נשאר נשלט — ביטול תוקף לפי אירועי הקטלוג, ולא לפי לוח זמנים.
מצבי מטמון: מטמון עמודים, מטמון בלוקים, מטמון שרת
שכבות מטמון פותרות משימות שונות, והפעלה שלהן «הכול בבת אחת» היא דרך בטוחה לקבל קטלוג עם מחירים ומלאי מיושנים. להלן תנאי היישום והמגבלות של כל מצב, כדי לבחור אותו בהתאם למבנה הקטלוג הספציפי.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| מטמון עמודים | קטלוג ללא התאמה אישית, פלט זהה לאורח | בלוקים אישיים וסל קניות דורשים חריגים, עריכות תכופות בונות את העמוד מחדש כולו |
| מטמון בלוקים של רכיבים | מבנה מגוון: רשימות, סינונים, כרטיסים מפורטים | נדרשות תלויות נכונות, אחרת הבלוק נתקע לאחר שינוי מחיר |
| מטמון שרת (Varnish) | עמודי עזר, תוכן סטטי, שיעור גבוה של תעבורת אורחים | דורש כללי ניקוי לפי תגיות והפרדה לפי קבוצות משתמשים |
| מטמון עם התחשבות בקבוצות משתמשים | מחירי סיטונאות וקמעונאות, תנאים שונים לפי תפקידים | מספר הווריאציות ונפח האחסון גדלים יחד עם מספר הקבוצות |
בחירת המצב נקבעת לפי מבנה הקטלוג, ולא לפי הגדרות ברירת מחדל. ב-1C-Bitrix מטמון עמודים ומטמון בלוקים פועלים באותה שכבה, ולכן יש להפריד בין זמני החיים: אחרת שכבה אחת דורסת את השנייה והעריכות נראות במרווחים אקראיים.
הקריטריון המרכזי — ביטול תוקף המטמון. אם הייצוא מ-1C מקושר לתגיות של בלוקי מידע ומדורים, שינוי מחיר מעדכן כרטיס אחד, ולא את כל הרשימה; איפוס כללי נשאיר לפעולות נדירות כמו בנייה מחדש של מבנה הקטלוג.
סדר ההגדרה: מביקורת ועד מסירת נהלים
סדר העבודה בנוי כך שכל שינוי נשען על מדידה, ולא על הנחה. תחילה מתעדים את מצב הקטלוג הנוכחי, לאחר מכן מתכננים את סכמת המטמון, אחר כך מגדירים את השרת ובודקים את התוצאה תחת עומס הקרוב לזה שבמציאות. מסיימים במסירת נהלים — כדי שעריכות קטלוג עתידיות לא ישברו את מה שכבר הוגדר.
- ביקורת ביצועים. מודדים את זמן התגובה של עמודי הקטלוג הכבדים, מחשבים את שיעור הבקשות שפונות למסד הנתונים, מאתרים מקומות שבהם המטמון אינו פועל: סינונים, עימוד, חיפוש, סל קניות.
- סכמת מטמון. מגדירים מה נשמר במטמון במלואו, מה — בקטעים, איזה זמן אחסון קובעים ולפי אילו אירועים מבטלים תוקף. בלוקים עם נתונים אישיים מוציאים אל מחוץ למטמון.
- הגדרת השרת עבור הקטלוג. מתקינים Varnish לפני שרת האינטרנט, מתארים כללים לתוכן סטטי, לדחיסה ולקוקיז, מגדירים מסלול נפרד למשתמשים מחוברים ולממשק הניהול, ומתאמים את ההתנהגות עם מטמון ברירת המחדל של הפלטפורמה.
- בדיקה תחת עומס. מריצים תרחישים עם בקשות מקבילות למדורי הקטלוג, משווים את זמן התגובה ואת שיעור הפגיעות במטמון לפני ואחרי, ובודקים שהאיפוס אינו מפיל עמודים.
- מסירת נהלים. מוסרים את הסכמה, כללי האיפוס לאחר עריכות קטלוג ומחירים, הוראות לעורכי תוכן ולמהנדסי תורנות, וצ'קליסט לשינויים בתבניות.
לאחר מכן הקטלוג עומד בזרם מבקרים ובמבצעים ללא ירידות ביצועים, והצוות יודע מה ומתי לעדכן.
ערכת קונפיגורציות ותיעוד לאחר ההטמעה
לאחר ההטמעה נשארת בידי הצוות שלכם לא «אוסף קבצים מהקבלן», אלא ערכה עובדת שאפשר לקרוא ולערוך לפיה את הקונפיגורציה בלעדינו: היכן הקטלוג נשמר במטמון, היכן במכוון לא, מה לעשות בעת עדכון CMS וכיצד בפעולה אחת להחזיר את המצב הקודם אם התנהגות האתר תשתנה.
- קונפיגורציית מטמון — קובצי כללים עובדים עם הערות: אילו ענפים אחראים על הקטלוג והקטגוריות, כמה זמן חי המטמון של כל אחד, וכיצד הוא מתאפס בעת עריכות מוצר.
- סכמת ארכיטקטורה — זרימת הבקשה ממאזן העומסים ועד האפליקציה: מי מגיש תשובה מהמטמון, היכן המטמון נעקף, באילו נקודות הוא מתאפס, ומה קורה כאשר ה-backend אינו זמין.
- כללי חריגים — רשימת נתיבים, קוקיז ופרמטרים שאינם נשמרים במטמון: אימות, סל קניות, ביצוע הזמנה, טפסים, מחירים אישיים. עבור כל סעיף — הסיבה, כדי שחריג חדש יתווסף לפי תבנית, ולא באופן אקראי.
- נוהל איפוס מטמון — מתי וכיצד מבוצע ביטול התוקף: ממוקד לפי כתובת, ברשימה בעת ייבוא קטלוג המוני, איפוס מלא בעת החלפת תבנית. בציון מי בצוות יוזם זאת.
- תיעוד תחזוקה — מה לבדוק לאחר עדכון CMS, כיצד להוסיף חריג חדש, וכיצד לוודא לפי כותרות התגובה שהעמוד מוגש מהמטמון ולא נבנה מחדש.
- מערך בדיקות קבלה — בקשות שבאמצעותן מאשרים שקונה מחובר לעולם אינו מקבל מטמון של אחר, ושהקטלוג עבור אורח מוגש באופן מיידי.
- הוראות חזרה לאחור — כיצד להחזיר את הסכמה למצב הקודם במיתוג אחד, אם לאחר העריכות ההתנהגות תעורר שאלות.
את הערכה מוסרים במאגר שלכם ובגישה שאינה קושרת אתכם אלינו: ניתן לפתח את הקונפיגורציות והנהלים בכוחות הצוות שלכם.
מקרה בוחן: הקטלוג תחת עומס לפני ואחרי ההגדרה
לפני: עומס שיא שבר את הקטלוג
הקטלוג נבנה מחדש בכל בקשה: סינונים, מיון ועימוד פנו שוב ושוב למסד הנתונים, ולכן בשיא — מבצע, דיוור, עונת שיא — זמן התגובה של המדור גדל פי עשרות, וחלק מהבקשות הסתיימו בתגובת שגיאה מהשרת.
שיעור התגובות הללו הגיע לכמה אחוזים מהמספר הכולל: באלפי מבקרים בו-זמנית הקטלוג פשוט נראה לא זמין. עם זאת, החומרה לא מוצתה — נתקלו בכך שאותו עמוד חושב מחדש שוב ושוב.
מה שינו
לפני הפלטפורמה 1C-Bitrix הוצב שכבת מטמון: עמודי קטלוג מוכנים ותוכן סטטי מוגשים מהמטמון, ואל שרת האפליקציה עובר רק מה שבאמת אין לו תחליף.
כללי ביטול התוקף קושרו לאירועים — עריכת מחיר, מלאי או פרסום מוצר מסירים את המטמון באופן ממוקד, ולא כולו, ולכן לאחר עדכון הקטלוג החימום אורך דקות, ולא שעות של עבודה ידנית.
מה השתנה באותה תעבורה
- זמן התגובה של הקטלוג בשיא — קצר פי 6–8, החציון לפי מדור — פי ארבעה;
- שיעור תגובות השגיאה מהשרת — מאחוזים לעשיריות האחוז;
- עומס המעבדים — נמוך כמעט פי שניים, הזיכרון הפסיק להגיע לגבול בכל שיא;
- ההמרה בקטלוג עלתה בכרבע בערך — העמודים הפסיקו "לתלות" בהמתנה למשתמש.
עומס שיא אנו מחזיקים ללא האצת חומרה וללא קיצוץ בסינונים: הקטלוג נשאר מלא, וחזרה לכללים הקודמים אורכת הפעלה מחדש אחת, אם ההתנהגות תחת עומס תתגלה כבלתי צפויה.
במה נבדל מטמון שרת ממטמון בדפדפן?
עותק של העמוד חי או בשרת, או בדפדפן של המבקר — אלה שני מעגלי שליטה שונים. מטמון שרת מתמלא פעם אחת ומוגש לכולם: Varnish מחזיק HTML מוכן בזיכרון ומסיר עומס ממסד הנתונים ומ-PHP בבקשות חוזרות לקטלוג. מטמון דפדפן נמצא במכשיר של אדם מסוים וכפוף רק לכותרות המטמון שמגיעות יחד עם התשובה.
| שכבה | היכן נשמרת | מי מנהל | עדכניות הנתונים |
|---|---|---|---|
| מטמון שרת | זיכרון השרת | TTL, ניתוח Cookie, ביטול תוקף לפי תגית | מתאפס ברגע עריכת מוצר או מחיר |
| מטמון דפדפן | מכשיר המבקר | כותרות Cache-Control, Expires, ETag | לא ניתן לאפס — ממתינים לתפוגה או משנים את כתובת המשאב |
| מטמון מורכב של המערכת | שרת, שכבה מעל מסד הנתונים | הגדרות בלוקי מידע ותגיות | מתעדכן בעת שמירת רכיב, חי דקות |
כותרות המטמון הן המנוף היחיד עבור הדפדפן: Cache-Control קובע את זמן החיים, ETag מאפשר להחזיר 304 במקום גוף, Vary: Cookie מפריד בין אורחים למשתמשים מחוברים, כדי שסל הקניות לא יוגש מעותק משותף. עבור Varnish אותן כותרות קובעות את ה-TTL של האובייקט ואת מערך הפרמטרים שלפיהם בקשה נחשבת לייחודית.
עדכניות הנתונים במטמון נפתרת באמצעות ביטול תוקף: עריכת כרטיס מאפסת אובייקטים משויכים לפי תגית, ולא את כל המטמון כולו. שכבות המטמון נבנות לפי עלייה במורכבות האיפוס — מורכב, שרת, דפדפן, — ולכן זמני חיים קצרים נקבעים במקומות שבהם הנתונים משתנים לעיתים קרובות.
שאלות טכניות נפוצות בנושא מטמון קטלוג
בעת אישור סכמת המטמון השאלות חוזרות על עצמן: האם לקונה יוצג סל קניות של אחר, מה יראו משתמשים מחוברים, באיזו מהירות מתעדכנים מחירים ומלאי לאחר סנכרון עם 1C, והאם אפשר להפעיל את כל זה באתר פעיל. להלן תשובות קצרות, והפרטים נפתחים תחת הכותרת.
האם לקונה יוצג סל קניות של אחר?
סל הקניות משויך לסשן של הקונה, ולכן עמודים עם תוכנו עוקפים את המטמון, והבלוק עצמו נטען בבקשה נפרדת כבר לאחר הגשת הקטלוג.
מטמון עבור משתמשים מחוברים
בקשות עם סימן אימות נאספות בנפרד: בלוקים משותפים — קטלוג, כרטיס, תפריט — נלקחים מהמטמון, ומחירים אישיים והנחות מוכנסים על ידי האפליקציה.
כיצד לא להגיש מחירים ומלאי מיושנים?
הנתונים נשמרים במטמון לזמן מוגבל, ובעת שינוי מוצר מתאפס רק הקטע שלו — לפי תגית המדור, ולא כל הקטלוג. הכרטיס עם המלאי החדש מתעדכן לאחר הייצוא.
איפוס מטמון בעת ייצוא מ-1C
עם סיום הסנכרון מופעל ניקוי לפי תגיות של מוצרים ומדורים שהשתנו. אין צורך בניקוי מלא: הוא היה מאפס את המטמון שנצבר ומאלץ את האתר לבנות עמודים מחדש.
האם אפשר להגדיר מטמון בלי לעצור את האתר?
כן. הכללים נאספים ונבדקים על עותק, ואז מופעלים בהדרגה — על מדור בקטלוג או על חלק מהמבקרים. המיתוג מתבצע ללא הפעלה מחדש של השירות, והחנות נשארת זמינה.
נדון במשימה: מה נדרש להערכה מדויקת
כדי לדון במשימה לגופו של עניין, ולא במילים כלליות, עלינו להבין כיצד בנוי הקטלוג שלכם וכיצד המבקרים רואים אותו. סכמת המטמון נבנית סביב נתיבים קונקרטיים: מה מוגש מהמטמון, מה תלוי בסשן ובסל הקניות, והיכן מחירים ומלאי משתנים בתדירות הגבוהה ביותר.
תארו את המשימה — את הפרטים נברר בעצמנו. בהתחלה עוזרים:
- איזה מדור כואב יותר: רשימה, כרטיס מוצר או סינונים;
- התצורה הנוכחית — שרת אינטרנט, היכן מותקן Varnish, כמה אתרים וקטלוגים הוא משרת;
- כיצד מתעדכן התוכן: ייצוא מ-1C, תדירותו ונפחו;
- עמודים שחייבים להישאר אישיים ואינם נכנסים למטמון;
- שיאי עומס ותלונות: באיזה רגע האתר מתחיל להאט ומה רואה הקונה;
- גישות לסביבת בדיקה ולוגים של שרת האינטרנט בתקופת עומס השיא.
לאחר השיחה נשלח הערכה ותוכנית עבודה: סדר השלבים, מה עושים על עותק, כיצד בודקים את כללי איפוס המטמון ומתי יוצאים לסביבת העבודה. תחילת הפרויקט נעשית דרך סביבת בדיקה — החנות הפעילה אינה משתנה עד שהתוצאות יאושרו.
אחריות לתוצאה מתקבעת לפני ההתחלה: מדדים שאנו מחשיבים כהושלמו, ונקודות שבהן נדרש אישור שלכם. אם במהלך העבודה יתגלו צווארי בקבוק מחוץ לתחום המטמון, נאמר זאת ישירות ונציע שלב נפרד, ולא נמתח את לוחות הזמנים.