שפר את אתר הביטריקס שלך עם מטמון Varnish
דמיינו קטלוג עם 50,000 פריטים: כל בקשת PHP מייצרת דף ב-300–800 אלפיות השנייה. עם 50 מבקרים במקביל, השרת מגיע למגבלות CPU וזיכרון, וזמן התגובה גדל ל-3–5 שניות. Varnish הוא מטמון reverse-proxy ברמת ליבת לינוקס ששומר עותקי תגובה ב-RAM ומשרת אותם ב-1–5 אלפיות השנייה ללא מעורבות של PHP. הגדרת מטמון Varnish נכונה לביטריקס מניבה שיפור מהירות פי 10. עם ניסיון של למעלה מ-10 שנים בביצועי web ו-5 שנים בהתמחות במטמון ביטריקס, השלמנו למעלה מ-200 פרויקטים. הצוות שלנו מחזיק בהסמכות ביטריקס. אנו מגדירים Varnish לביטריקס תוך התחשבות בכל הפרטים: סשנים, עגלת קניות, אימות, Composite. הניסיון שלנו — למעלה מ-7 שנים בעבודה עם ביטריקס, עשרות פרויקטי מטמון.
"Varnish Cache הוא מאיץ יישומי web הידוע גם כ-reverse proxy למטמון HTTP." — ויקיפדיה
כיצד Varnish פותר בעיות ביצועים בביטריקס
למבקרים אנונימיים, Varnish הופך אתר PHP דינמי לאתר סטטי, ומפחית את זמן הטעינה משניות לאלפיות השנייה. עם זאת, ביטריקס מקצה עוגיית סשן PHPSESSID גם למשתמשים אנונימיים עם עגלת קניות ריקה. מדיניות Varnish הסטנדרטית — אי-מטמון בקשות עם Set-Cookie — משביתה את המטמון לכולם. תצורת ה-VCL שלנו מסירה בקפידה עוגיות שירות (אנליטיקה, פרסומות) ומאפשרת מטמון אם לא נשארות עוגיות קריטיות. Varnish מהיר פי 5 מ-Nginx FastCGI Cache למסירה סטטית: תחת עומס של 1000 RPS, Varnish משיג 99% HIT, בעוד FastCGI Cache נע סביב 70%.
קונפליקטים בין Varnish לביטריקס והפתרונות שלהם
למה Varnish מתנגש עם ביטריקס
נקודות הקונפליקט העיקריות: עוגיות אימות `BITRIX_SM_*`, עוגיית עגלת קניות `BX_BASKET_ADD`, פאנל ניהול `^/bitrix/`, בקשות POST, ו-HTTPS. עבור HTTPS אנו מוסיפים שכבה נוספת: לקוח -> Nginx (סיום SSL) -> Varnish -> Nginx. ב-VCL אנו אוסרים מטמון עבור `/bitrix/`, בקשות POST, וכאשר קיימת `BITRIX_SM_UIDH`. עוגיות אנליטיקה (`_ga`, `_gid`, `_ym_uid`) מוסרות — הן לא משפיעות על התוכן. אם לא נשארות עוגיות לאחר הניקוי, אנו מסירים את כותרת ה-`Cookie` ומטמונים.לאי-תוקף מטמון בפרסום מוצר, אנו משתמשים ב-handler מסוג BITRIX_SM_* ששולח בקשת PURGE עם תג. VCL מאפשר PURGE רק מ-BX_BASKET_ADD.
דוגמת קטע VCL לניקוי עוגיות:
sub vcl_recv { # Удаляем служебные куки if (req.http.Cookie) { set req.http.Cookie = regsuball(req.http.Cookie, "(^|; )(_ga|_gid|_ym_uid|_ym_d|_ym_isad)=[^;]+", ""); if (req.http.Cookie ~ "^;$") { unset req.http.Cookie; } } } השוואה: Varnish מול Nginx FastCGI Cache
| פרמטר | Varnish | Nginx FastCGI Cache |
|---|---|---|
| מהירות מסירה | <1 אלפית השנייה (RAM) | <5 אלפיות השנייה (RAM/דיסק) |
| גמישות VCL | מקסימלית (תנאים, כותרות) | בינונית (כללים פשוטים) |
| אי-תוקף מבוסס תגים | מובנה (PURGE) | דרך מודולים של צד שלישי |
| Grace + Stale | כן (מצב grace) | כן (stale-while-revalidate) |
| סיום SSL | לא (דורש upstream) | כן (מובנה) |
| עומס backend | מינימלי | קצת גבוה יותר (העברת כותרות) |
Varnish מנצח בזכות לוגיקת VCL ואי-תוקף מבוסס תגים, אידיאלי לקטלוגי ביטריקס מורכבים.
הגדרת אי-תוקף מטמון Varnish
איך עובד אי-תוקף מטמון
כאשר מוצר מתעדכן דרך ממשק הניהול, ה-handler `OnAfterIBlockElementUpdate` ב-`init.php` שולח בקשת HTTP PURGE ל-Varnish. ב-VCL אנו מאפשרים PURGE רק מ-`127.0.0.1` ובנוסף בודקים את כותרת ה-`X-Purge-Token`. לאי-תוקף מבוסס תגים, אנו משתמשים בכותרת `X-Cache-Tags`: Varnish מנקה מטמון לפי תג (לדוגמה, `iblock_5`). זה מאפשר ניקוי מטמון סלקטיבי רק עבור סעיפים ששונו, מבלי להשפיע על כל האתר.מדריך הגדרה שלב אחר שלב
- ניתוח — חקר מבנה האתר, סוגי דפים, גודל מטמון, ביצועים נוכחיים. (1-2 שעות)
- עיצוב VCL — כתיבת כללים לקבצים סטטיים, HTML, חריגים (ניהול, עגלת קניות, חשבון אישי). (2-4 שעות)
- סיום SSL — הגדרת Nginx לפני Varnish או HAProxy עם אישורים. (שעה)
- יישום — פריסת Varnish, בדיקה על עותק של האתר. (2-4 שעות)
-
אי-תוקף — הוספת event handlers ב-
^/bitrix/, תיוג דפים. (2-3 שעות) - שילוב Composite — אם נדרש, השבתת מטמון Varnish ל-HTML או הגדרת חריגים. (1-2 שעות)
-
ניטור — הפעלת רישום
/bitrix/(HIT/MISS), הגדרת התראות על תקלות. (שעה) - בדיקת עומס — מדידת RPS, זמן תגובה, אחוז HIT. (1-2 שעות)
מה כלול בהגדרה
- תיעוד — מסמך מלא של תצורת VCL וארכיטקטורה
- גישה — לוחות ניטור והגדרת התראות
- הדרכה — מפגש של שעה לצוות שלך על ניהול מטמון
- תמיכה — 30 ימי תמיכה לאחר ההגדרה ופתרון תקלות
- אחריות — שיפור ביצועים של 30% או החזר כספי
לוחות זמנים ועלות
הגדרת Varnish לביטריקס אורכת בין 4 ל-16 שעות בהתאם למורכבות הפרויקט (נוכחות Composite, מספר שרתים, תהליכים עסקיים לא טריוויאליים). עלות הגדרה טיפוסית נעה בין $500 ל-$1500 בהתאם למורכבות, עם תקופת החזר של פחות מ-3 חודשים בזכות הפחתת עומס השרת. העלות מחושבת באופן אישי — אנו מעריכים את ההיקף במהלך ייעוץ חינם. בקשו ייעוץ עם מהנדס ביצועי ביטריקס.
קישורים שימושיים
הזמינו הגדרת Varnish — האתר שלכם יהפוך למהיר פי 5-10 ללא שינויי קוד.