מדוע 1C-Bitrix מאט ללא קישור נכון של Cloudflare
דפים דינמיים ב-1C-Bitrix נבנים מחדש בכל בקשה: קומפוננטות, אימות, סל קניות, בלוקים אישיים. כל עוד הדף לא מוגש מהמטמון, השרת עובר בכל פעם את השרשרת "ניתוב → שאילתה לבסיס הנתונים → בניית תבנית", וזמן התגובה של השרת גדל באופן ליניארי עם מספר המבקרים בו-זמנית.
צוואר הבקבוק של Bitrix אינו הקוד עצמו, אלא בסיס הנתונים: הקטלוג, המחירים, המלאי, מאפייני המוצרים והמדורים מושכים עשרות שאילתות מקושרות לדף אחד.
קישור של Cloudflare מסיר את העומס הזה לפני שהבקשה מגיעה לשרת. קבצים סטטיים וגרסאות "אורח" של דפים מוגשים מהצומת הקרוב, ולבקאנד מגיעות רק הבקשות שבאמת דורשות התאמה אישית: אימות, סל קניות, ביצוע הזמנה. העומס על בסיס הנתונים יורד פי כמה, כי אותו HTML מפסיק להיבנות מחדש עבור כל מבקר.
בעיה נפרדת היא זינוקים בתעבורה. פרסום, דיוור או פרסום בתקשורת מביאים מאות סשנים בו-זמנית, והשרת מתחיל להגיב לאט יותר בדיוק ברגע שבו הקהל הוא הכי משלם. המטמון בפריפריה מנטרל את השיא: הצמתים מקבלים את התעבורה על עצמם, ובסיס הנתונים מקבל זרימה אחידה במקום מפולת.
ישנם גם דקויות שבגללן "פשוט להפעיל מטמון" לא עובד. דפים דינמיים עם התאמה אישית אינם ניתנים לקישור באופן עיוור — אחרת המבקר יראה סל קניות של מישהו אחר או מחיר מיושן.
יש צורך בכללי עקיפת מטמון, עבודה נכונה עם cookie וסשנים, מטמון נפרד למשתמשים מאומתים ולאורחים, ואינוולידציה מדויקת בעת עדכון הקטלוג. בלי זה האתר או מגיש נתונים שגויים, או שהמטמון לא פועל כלל.
אנו מפרקים כיצד זה נסגר: אילו בקשות ניתן להגיש מהפריפריה, כיצד להגדיר עקיפה עבור תרחישים מותאמים אישית, וכיצד לקשר איפוס מטמון עם עדכון תוכן ב-1C-Bitrix.
מה נותנת הגדרה נכונה של מטמון בפריפריה
הפחתת עומס על השרת
מטמון בפריפריה מסיר מהתשתית בקשות חוזרות: סטטיקה, עמודי קטלוג ומדורים הנמסרים מהמטמון אינם מגיעים לשרת האינטרנט ולמסד הנתונים. בפרויקט טיפוסי על 1C-Bitrix זה מסיר את רוב הפניות ל-PHP ול-MySQL — השרת מפסיק להרכיב מחדש את אותו עמוד עבור כל מבקר. העומס יורד עד כדי כך שהמשאבים שהתפנו עוברים לדינמיקה: סל הקניות, ביצוע הזמנה, אזור אישי.
מהירות מסירת העמודים
מסירה מהצומת הקרוב ביותר למשתמש מקצרת את זמן התגובה: הדפדפן מקבל HTML מוכן וסטטיקה ללא המתנה לבקאנד. כותרות מטמון מוגדרות נכון והפרדה בין "ניתן למטמון" ל"אישי" נותנות תגובה יציבה בכל העמודים, למעט אלה שבהם הנתונים תלויים בסשן. עבור קטלוג עם מאות פריטים זה ההבדל בין המתנה לרינדור מיידי.
עמידות בפני שיאים ועמידות בתקלות
בזמן זרימת תנועה חדה — מבצע, תפוצה, פרסום — הבקשות נבלמות בפריפריה, ולא קורסות על המקור. אם שרת האינטרנט או מסד הנתונים אינם זמינים, העמודים שבמטמון ממשיכים להימסר, והמבקר רואה תוכן במקום שגיאה. זה מקטין את סוג התקלות בעת אי-זמינות המקור: האתר שורד תקלות קצרות ועבודות תחזוקה ללא עצירה מלאה.
צפיות מראש תחת עומס
פריפריה מוגדרת מסירה את התלות באופטימיזציות חד-פעמיות של השרת: ההתנהגות תחת עומס הופכת לניתנת לניהול, ולא "איך שיצא". מפרקים כיצד זה מוגדר עבור פרויקט ספציפי.
מצבי מטמון ואפשרויות הפצת סטטיקה
מטמון בפרימטר הוא לא "סימון תיבת סימון", אלא סט חוקים שקובעים מה בכלל ניתן להגיש מהמטמון ומה חייב לעבור לשרת. בביטריקס אותו URL מחזיר תוכן שונה לאורח, למשתמש מאומת ולמנהל, ולכן חוקי המטמון נבנים סביב מאפייני הבקשה: קוקי סשן, כותרות אימות, פרמטרי query וסוג התוכן. להלן — אפשרויות עבודה וגבולות היישום שלהן.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| מטמון עמוד מלא | קטלוג, מאמרים, דפי נחיתה, עמודים ללא פרסונליזציה | אין לאחסן במטמון תגובות עם Set-Cookie וסל קניות; חובה עקיפה עבור משתמשים מאומתים |
| מטמון סטטיקה | JS, CSS, גופנים, תמונות, מדיה | דורש גרסאות בשמות קבצים, אחרת עדכון לא מגיע ללקוח |
| מטמון תגובות API | ספרי עזר, קטלוג, מסננים, מתודות ציבוריות | רק GET אידמפוטנטי; אין לאחסן במטמון POST ופעולות עם סל קניות |
| עקיפת מטמון | אזור אישי, ביצוע הזמנה, ממשק ניהול, רכיבי AJAX | חוקי העקיפה חייבים לפעול לפני חוקי המטמון, אחרת דליפת תוכן של אחר |
חוקי המטמון מוגדרים לפי סדר עדיפויות: תחילה חריגים עבור משתמשים מאומתים ונתיבים שירותיים, לאחר מכן חוקים ממוקדים עבור סטטיקה ו-API, ורק אחר כך חוק כללי עבור עמודים. סדר כזה מונע מצב שבו עותק עמוד לאורח מוגש למשתמש עם סשן פעיל.
בנפרד מוגדר איפוס מטמון: בעת פרסום תוכן או שינוי מוצר המטמון מבוטל לפי תג או נתיב, ולא באופן מלא — אחרת כל פרסום תוכן מאפס את כל הפרימטר והשרת מקבל עומס שיא.
כיצד אנו מיישמים Cloudflare קישור עבור Bitrix
יישום הקישור מתחיל בבדיקת התצורה הנוכחית: אנו בוחנים כיצד בנוי הפרויקט, אילו עמודים דינמיים, היכן נמצאים האימות והסל, כיצד מוגדרים כותרות התגובה וזמן החיים של האובייקטים.
בשלב זה אנו מתעדים מה בכלל ניתן לקשר בפרימטר ומה חייב לעבור לשרת האפליקציה — אחרת הקישור יתחיל להחזיר נתונים מותאמים אישית למשתמשים זרים.
לאחר מכן אנו מתכננים את הסכימה: מפרידים את התוכן לסטטי ודינמי, מגדירים כללים לפי סוגי בקשות, cookie ופרמטרים של URL, קובעים עקיפת קישור עבור הפעלות מאומתות ומדורים שירותיים. הסכימה מתורגמת למערכת כללים ומדיניות, אשר לאחר מכן מועברים לתצורת הפרימטר.
- בדיקת תצורה — ניתוח מבנה האתר, נקודות ההתאמה האישית, הכותרות הנוכחיות והתנהגות שרת האפליקציה.
- תכנון סכימת הקישור — מפת אזורים סטטיים ודינמיים, כללי עקיפה, זמן חיים של אובייקטים.
- הגדרת כללים בפרימטר — הפרדה לפי סוגי תוכן, cookie ופרמטרים, מדיניות נפרדת לניהול ול-API.
- אינטגרציה עם האפליקציה — כותרות תגובה נכונות, איפוס קישור בעת פרסום ושינוי קטלוג.
- בדיקת נכונות — הרצת תרחישים: אורח, משתמש מאומת, סל, ביצוע הזמנה, חיפוש.
- בדיקת עומס — השוואת זמן התגובה ושיעור הבקשות המגיעות לשרת האפליקציה, לפני ואחרי.
- מסירת תקנון — כללי עדכון קישור, סדר פעולות בעת תקלות, נקודות בקרה לצוות.
כל שלב מסתיים בארטיפקט: מפת אזורים, מערכת כללים, רשימת בדיקות. בדיקת הנכונות היא שער חובה: עד שתרחישים עם אימות והזמנה לא עבדו ללא דליפות והחלפת נתונים, הסכימה אינה עוברת לסביבת העבודה.
מדיניות מטמון והחרגות עבור אזורים דינמיים
מטמון ברמת Cloudflare פועל לפי כללים, ולא "על כל האתר": עמוד נכנס למטמון רק אם הבקשה תאמה לתנאי המדיניות. עבור 1C-Bitrix זה קריטי — קטלוג, עמודים סטטיים ואזורי חדשות מוגשים מהמטמון, בעוד הסל, ביצוע ההזמנה, האזור האישי וכל כתובת URL עם סשן תמיד הולכים לשרת.
מה נכנס למטמון ומה מוחרג
הכלל הבסיסי — לבצע מטמון של בקשות GET לאזורים ציבוריים ולא לגעת בכל מה שמשתנה ממשתמש למשתמש. החרגות מוגדרות לפי נתיבים (/personal/, /basket/, /order/, /auth/), לפי פרמטרים (?sessid=, ?login=, ?logout=) ולפי קוקי הרשאה. בנפרד אנו סוגרים את ממשק הניהול וסקריפטים של שירותי החלפה עם 1С.
משתמשים מורשים ונתונים אישיים
הסיכון העיקרי — להגיש עמוד שמור במטמון עם שם, מחיר או מלאי של מישהו אחר. לכן בקשות עם קוקי הרשאה מסומנות כעקיפת מטמון, ובלוקים דינמיים (סל, מועדפים, מחירים אישיים) נבנים בנפרד ואינם נכנסים למטמון הכללי. תגובות עם כותרת Set-Cookie ונתונים פרטיים אינן נשמרות.
ניהול משך חיים ואיפוס
עבור הקטלוג והתוכן הסטטי משך החיים מוגדר עם מרווח, ועבור אזורים עם עדכונים תכופים — קצר יותר, עם איפוס כפוי לפי אירוע: שיניתם מוצר או מחיר — הכלל מאפס את המטמון של כתובת URL ספציפית, ולא של כל האתר. כך המבקר רואה נתונים מעודכנים, והעומס על השרת נשאר נמוך.
מה הלקוח מקבל לאחר הגדרת המטמון
לאחר הגדרת המטמון הלקוח מקבל לא "מטמון מופעל", אלא סט ארטיפקטים שלפיהם המערכת ממשיכה לפעול ולתפקד בלעדינו. כל סעיף הוא מסמך עבודה או קונפיגורציה, ולא תיאור של "מה עשינו".
- קונפיגורציית כללי המטמון — סט כללים בחלוקה לפי סוגי תוכן: סטטי, עמודי קטלוג, תגובות API, בלוקים דינמיים. עבור כל כלל נקבעים זמן החיים במטמון ותנאי האינוולידציה.
- תרשים זרימות בקשות — דיאגרמה המציגה את מסלול הבקשה מהדפדפן ועד לשרת האפליקציה: מה מוגש מהמטמון, מה עובר ישירות, היכן פועל האיפוס. לפיה מהנדס חדש מבין את הארכיטקטורה תוך שעה, ולא תוך שבוע של ניתוח.
- מדיניות חריגים — רשימת נתיבים ופרמטרים שאסור למטמון: סל קניות, ביצוע הזמנה, סשנים מאומתים, עמודים אישיים. בלי הרשימה הזו המטמון מתחיל להגיש נתונים של אחרים — סוג השגיאות היקר ביותר.
- נוהל איפוס המטמון — סדר הפעולות בעת עדכון תוכן, העלאת ריליס ותיקון תבניות: מה מנקים נקודתית, מה במלואו, באיזה סדר, כדי לא להגיש גרסה מיושנת של העמוד.
- תיעוד הקונפיגורציה — היכן נמצאים הכללים, כיצד לשנות אותם, אילו פרמטרים קריטיים, מה יקרה בעת שגיאה בכל אחד מהם. עם הערות על מקומות לא ברורים מאליהם.
- נוהל תחזוקה — תדירות הבדיקות, סט מדדים לניטור (שיעור הפגיעות במטמון, זמן תגובה, שיעור שגיאות), ספים שבהם נדרשת התערבות.
- תוכנית rollback — כיצד להחזיר את ההתנהגות הקודמת אם לאחר שינוי הכללים נפגעה ההגשה או ירדה ההמרה. ה-rollback נבדק לפני המסירה, ולא נכתב "ליתר ביטחון".
ארטיפקטים אלה נמסרים יחד עם הגישות וניתוח קצר עבור הצוות שלכם. בהמשך תיקוני הכללים והתחזוקה השוטפת מתבצעים בכוחות עצמכם — התמיכה שלנו נדרשת רק בשינויי ארכיטקטורה.
במה שונה מטמון בפרימטר ממטמון בשרת האפליקציות?
מטמון בפרימטר הוא העתק של התגובה שמוגש על ידי צומת הרשת הקרוב ביותר למשתמש, מבלי להגיע לשרת שלך.
מטמון בשרת האפליקציות חי בתוך Bitrix עצמו: זהו מטמון מנוהל של קומפוננטות, אינפובלוקים ותבניות, שנוצר כבר לאחר שהבקשה הגיעה לאפליקציה ופעלו הלוגיקה העסקית, הרשאות הגישה וההתאמה האישית.
ההבדל עקרוני: הפרימטר שומר תגובה מוכנה בשלמותה ואינו יודע ממה היא מורכבת, ואילו המטמון בשרת מכיר את מבנה הנתונים ויודע להרכיב מחדש רק את החלק שהשתנה.
גם ההתעדכנות שלהם שונה. הפרימטר נשען על כותרות זמן חיים וכללים לפי סוגי קבצים: סטטיקה ועמודים ציבוריים חיים זמן רב, דינמיקה — שניות או שאינה נשמרת במטמון כלל. המטמון בשרת מבוטל על ידי אירועים — עריכת פריט אינפובלוק, שינוי הגדרות, עדכון קטלוג.
מכאן סוגי בקשות שונים: הפרימטר משרת בביטחון מבקרים אנונימיים וביקורים חוזרים באותן כתובות, המטמון בשרת מחזיק את העומס מתרחישים מאומתים, סל הקניות והאזור האישי, שבהם התגובה תלויה במשתמש מסוים.
בדיוק משום כך רמות המטמון אינן מחליפות זו את זו אלא משלימות זו את זו. אם לשים בפרימטר הכול ללא הבחנה, משתמשים יתחילו לראות סלים של אחרים ומחירים מיושנים; אם להסתפק רק במטמון בשרת, כל ביקור אנונימי בכל זאת יגיע לאפליקציה ויתקע במשאבים שלה.
השילוב נבנה על הפרדה ברורה: הפרימטר לוקח את התעבורה הציבורית והסטטיקה, השרת — עמודים מותאמים אישית ותלויים בנתונים.
הסיכון המרכזי — ביטול תוקף. הפרימטר אינו רואה עריכות במסד הנתונים, לכן לאחר פרסום מוצר או שינוי מחיר יש לאפס במפורש את המטמון בכתובת הנדרשת, אחרת המבקר יקבל גרסה ישנה.
אנחנו מגדירים כללי עקיפת מטמון עבור מדורים שירותיים ומדורי ניהול, מקשרים את האיפוס לאירועי פרסום ושומרים זמן חיים קצר לעמודים שמשתנים לעתים קרובות. אז שתי הרמות פועלות בהרמוניה: הפרימטר מסיר את עיקר העומס, המטמון בשרת מאיץ את הרכבת הדינמיקה, ואי-הסנכרון בנתונים אינו מגיע למשתמש.
מקרה בוחן: כיצד מטמון בפריפריה האיץ חנות אינטרנטית
חנות על 1C-Bitrix עם קטלוג של כמה עשרות אלפי פריטים: עמוד הקטלוג נבנה תוך 1.8–2.4 שניות, כרטיס המוצר — עד 3 שניות, וכמעט כל בקשה הלכה למסד הנתונים, מכיוון שמטמון הרכיבים אופס בעת עדכון מחירים ומלאי.
במהלך מבצע מכירות השרת הגיע לתקרת היכולת: זמן התגובה עלה ל-8–12 שניות, חלק מהסלים וההזמנות נפלו בגלל timeout, ומסד הנתונים נכנס לתור קריאה.
הוצאנו את המטמון לפריפריה דרך Cloudflare: סטטיקה ומדיה הועברו למטמון ארוך טווח, HTML של הקטלוג והכרטיסים — למטמון מנוהל עם ביטול תקין לפי תגיות, ואת הדינמיקה (סל, תשלום, אזור אישי, הפעלות מאומתות) הוצאנו לחלוטין מהמטמון.
הנקודה המרכזית — כללי עקיפת מטמון לבקשות עם cookie של אימות ולנתיבי שירות של החלפה עם 1С, כדי שמחירים ומלאי לא "ייתקעו" על ערכים מיושנים.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| זמן תגובת הקטלוג | 1.8–2.4 ש' | 0.3–0.5 ש' |
| זמן תגובת כרטיס המוצר | עד 3 ש' | 0.4–0.6 ש' |
| שיעור הבקשות מהמטמון | ~0% | 78–85% |
| עומס על מסד הנתונים בשיא | 100%, תור קריאה | 20–30% |
| התנהגות במבצע מכירות | עליית תגובה עד 8–12 ש', נפילות סלים | תגובה יציבה, אין כשלים |
בנפרד הגדרנו ביטול מטמון: בעת שינוי מוצר או מחיר המטמון מתאפס נקודתית לפי תגית, ולא כולו, לכן עדכון הקטלוג לא "שוטף" את כל המטמון ולא מפיל את האתר בבנייה מחדש. את עומס השיא החנות מחזיקה כעת ללא הרחבת השרת — הפריפריה מקבלת על עצמה את עיקר התעבורה.
ספקות טכניים בנוגע להגדרת מטמון
מטמון לאתר דינמי על 1C-Bitrix כמעט תמיד נתקל באותם מקומות: את הדף רואה גם אורח וגם משתמש מחובר, לכל אחד יש סל משלו ובלוקים משלו. להלן ניתוח של הספקות האופייניים שאיתם מגיעים לפני הפעלת מטמון בפרימטר.
כיצד לבצע מטמון לדפים עבור משתמשים מחוברים?
מטמון מלא עבורם לא נמסור — אחרת מבקר אחד יראה את הנתונים של אחר. הסכמה היא כזו: האורח מקבל תגובה מהמטמון, ואילו עבור בקשה עם סשן פעיל המטמון נעקף, והדף נבנה בצד האפליקציה.
פשרה — לבצע מטמון לבלוקים משותפים (קטלוג, קטגוריות, סטטי), ואילו בלוקים אישיים (שם, יתרה, המלצות) לטעון בבקשה נפרדת כבר לאחר מסירת הדף. כך מוסר העומס העיקרי, וההתאמה האישית נשארת תקינה.
מה קורה עם הסל ומסירת ההזמנה?
הסל הוא מצב של סשן, ואסור להכניס אותו למטמון משותף בשום הגדרה. בקשות לסל, להוספת מוצר ולמסירת הזמנה מסמנים כבלתי ניתנות למטמון ותמיד מעבירים לאפליקציה. מבוצע מטמון רק לאותם דפים שבהם אין נתוני משתמש: כרטיס מוצר, רשימה, מדורים אינפורמטיביים. מסירת ההזמנה והתשלום עוברים לגמרי מחוץ למטמון.
כיצד לעדכן את המטמון לאחר עריכות תוכן?
שני מנגנונים יחד. הראשון — ביטול תוקף לפי אירוע: בעת שמירת אלמנט, מדור או מוצר האפליקציה מודיעה על איפוס, והדפים הקשורים נבנים מחדש. השני — זמן חיים קצר עבור בלוקים שמשתנים לעתים קרובות, כדי שהעריכה תגיע גם ללא אירוע מפורש. עבור תמונות וסטטי אנו משתמשים בגרסאות בשם הקובץ: עדכנו — הכתובת השתנתה, המטמון הישן כבר לא מפריע.
כיצד לא לשבור התאמה אישית וגרסאות אזוריות?
ההתאמה האישית נבנית על הפרדה: החלק המשותף של הדף מבוצע במטמון, והאישי מוצב בצד הלקוח או בבקשה נפרדת. גרסאות אזוריות ומטבעות שונים מפרידים לפי מפתח מטמון, כדי שמבקר מעיר אחת לא יקבל את התנאים של אחרת.
לאחר ההפעלה מריצים תרחישים: אורח, מחובר, הוספה לסל, מסירת הזמנה — ובודקים שלא דולפים בשום מקום נתונים של אחרים.
אם לגבי אחד מהסעיפים נותרו ספקות לפרויקט שלכם — תארו את המשימה, נחזור עם הערכה ותוכנית הגדרה.
בואו נדון במשימת הקישור שלכם
כדי לחזור עם הערכה ותוכנית יישום, ולא עם מילים כלליות, אנחנו צריכים פריסה של התצורה הנוכחית שלכם. תארו כיצד בנוי הקישור כעת: מה מחזיר שרת האפליקציה, מה מסיר Cloudflare, אילו עמודים ומדורים מקושרים, כיצד מוגדרות כללי העקיפה למשתמשים מאומתים ולסל הקניות.
בנפרד — היכן בדיוק מתבטאת הבעיה: ירידה בזמן התגובה תחת עומס, תוכן מיושן לאחר עריכות בממשק הניהול, איפוס הקישור בכל פרסום או עלייה בעומס על מסד הנתונים בשעות שיא.
כדאי לצרף את מה שכבר יש בהישג יד: תצורת כללי הקישור והעקיפה, הגדרות TTL לסטטי ולדינמי, כותרות התגובה הנוכחיות, לוגים של שאילתות איטיות, צילומי מסך של מדדים מפאנל Cloudflare לתקופה אופיינית. אם חלק מזה לא נאסף — לא נורא, חלק מהתמונה נשחזר בעצמנו במהלך ביקורת הקישור.
מה אנחנו עושים הלאה:
- מנתחים את סכימת הקישור הנוכחית ומוצאים היכן אובדת השליטה;
- משווים את כללי Cloudflare עם הלוגיקה של 1C-Bitrix: קומפוננטות, מצב קומפוזיט, איפוס לפי אירועים;
- בודקים כיצד מתנהג הקישור בעת אימות, הוספה לסל הקניות וביצוע הזמנה;
- מעריכים את ההשפעה על העומס על שרת האפליקציה ומסד הנתונים;
- מכינים תוכנית יישום: שלבים, סדר השינויים, נקודות שחזור;
- מתאמים איתכם סדרי עדיפויות וסדר העבודות.
פורמט התשובה — הערכת עבודות ותוכנית יישום עם שלבים ברורים, ולא "צריך לבצע אופטימיזציה" מופשט. אם במהלך הניתוח יצופו סיכונים לגרסה הנוכחית, נאמר עליהם ישירות לפני תחילת השינויים.
תארו את המשימה בצורה חופשית: מה הפרויקט, מה העומס, מה כבר ניסיתם ואיזו תוצאה נדרשת. במידת הצורך נחבר מהנדס שמוביל את הקישור וינתח את הניואנסים של התצורה שלכם באופן ממוקד — נדון במשימה ונחזור עם הערכה ותוכנית עבודות.