הגדרת מטמון מותאם אישית לרכיבי 1C-Bitrix

אנחנו מגדירים מטמון (Caching) לרכיבי 1C-Bitrix מותאמים אישית כבר למעלה מ-5 שנים ביותר מ-200 פרויקטים. בפרויקט מסחר אלקטרוני אחד עם קטלוג של 50,000 מוצרים, מטמון שגוי של תפריט הרכיב גרם להמתנה של 500 אלפיות השנייה לכל כניסה. לאחר כוונון, השגנו 30 אלפיות השנייה — עלייה של 12% בהמרות.

רכיב ללא מטמון משמעותו שאילתת מסד נתונים ישירה בכל צפייה בעמוד. ב-10,000 צפיות ביום, העומס הופך קריטי. מטמון ב-Bitrix אינו כפתור קסם אלא סט של החלטות: מה לשמור במטמון, לכמה זמן, לפי איזה מפתח, וכיצד לפסול אותו כאשר הנתונים משתנים. אנו מבטיחים הפחתה בזמן יצירת העמוד מ-500 אלפיות השנייה ל-20-50 אלפיות השנייה ללא שינוי בלוגיקת האפליקציה. קבלו ייעוץ בנושא הגדרת מטמון — המהנדסים שלנו ינתחו את הפרויקט שלכם ויציעו את הסכימה האופטימלית תוך שעה.

מנגנון המטמון של Bitrix

Bitrix משתמש במטמון קבצים כברירת מחדל. המטמון מאוחסן ב-/bitrix/cache/ (או /upload/cache/ בהתאם לתצורה). כל קובץ מטמון הוא $arResult מסודר (serialized) של הרכיב. במקרה של פגיעת מטמון, נקרא template.php עם הנתונים השמורים — ללא שאילתות מסד נתונים.

שתי רמות מטמון:

1. מטמון תוצאה (StartResultCache / EndResultCache) — שומר $arResult
2. מטמון HTML (מטמון מרוכב, מנגנון נפרד) — שומר את ה-HTML הסופי

עבור רכיבים מותאמים אישית, נעשה שימוש ברמה הראשונה.

מדוע מטמון נכשל לעיתים קרובות עבור רכיבים מותאמים אישית?

הסיבה העיקרית — היווצרות שגויה של cacheId. אם המזהה אינו כולל את כל הפרמטרים המשפיעים, עמוד עם קטגוריית "אלקטרוניקה" עלול להציג מטמון מקטגוריית "ביגוד". אנו תמיד כוללים cacheId, IBLOCK_ID, SECTION_ID, COUNT, וכן SORT_FIELD ו-LANGUAGE_ID עבור פרויקטים רב-לשוניים ורב-אתרים. מחלקת ה-CSS של הבלוק (SITE_ID) אינה משפיעה על הנתונים, ולכן איננו כוללים אותה.

שימוש בסיסי ב-StartResultCache

$cacheId = serialize([
    $arParams['IBLOCK_ID'],
    $arParams['COUNT'],
    $arParams['SECTION_ID'],
    LANGUAGE_ID,
    SITE_ID,
]);
$cacheDir = '/custom/my.component/' . $arParams['IBLOCK_ID'] . '/';
if ($this->StartResultCache($arParams['CACHE_TIME'], $cacheId, $cacheDir)) {
    $this->arResult = $this->getData();
    $this->IncludeComponentTemplate();
    $this->EndResultCache();
}

פרמטרים של $arParams['CSS_CLASS']:

• $cacheId = serialize([ $arParams['IBLOCK_ID'], $arParams['COUNT'], $arParams['SECTION_ID'], LANGUAGE_ID, SITE_ID, ]); $cacheDir = '/custom/my.component/' . $arParams['IBLOCK_ID'] . '/'; if ($this->StartResultCache($arParams['CACHE_TIME'], $cacheId, $cacheDir)) { $this->arResult = $this->getData(); $this->IncludeComponentTemplate(); $this->EndResultCache(); } — TTL בשניות. StartResultCache($cacheTime, $cacheId, $cacheDir) או $cacheTime — המטמון אינו בשימוש. false — מטמון בלתי מוגבל (עד לפסילה ידנית)
• 0 — מזהה ייחודי עבור קבוצת הפרמטרים
• -1 — תיקייה בתוך $cacheId לניקוי קבוצתי

היווצרות נכונה של cacheId

טעות נפוצה: $cacheDir אינו מתחשב בכל הפרמטרים המשפיעים. דוגמה לקבוצה נכונה:

$cacheId = serialize([
    $arParams['IBLOCK_ID'],
    $arParams['SECTION_ID'],
    $arParams['COUNT'],
    $arParams['ELEMENT_SORT_FIELD'],
    LANGUAGE_ID,
    SITE_ID,
]);

אין לכלול ב-/bitrix/cache/ דברים שאינם משפיעים על הנתונים — אחרת המטמון לא יהיה בשימוש. יש ליישם פרמטרי תצוגה (מחלקת CSS) ישירות ב-$cacheId.

כיצד להגדיר מטמון תוך התחשבות בקבוצות משתמשים?

אם הרכיב מציג תוכן שונה למשתמשים מורשים ולאורחים, המטמון צריך להיות נפרד. אפשרות 1: השבתת מטמון עבור משתמשים מורשים. אפשרות 2: הוספת קבוצות משתמשים ל-$cacheId = serialize([ $arParams['IBLOCK_ID'], $arParams['SECTION_ID'], $arParams['COUNT'], $arParams['ELEMENT_SORT_FIELD'], LANGUAGE_ID, SITE_ID, ]); (ידנית או דרך cacheId). דוגמה:

global $USER;
$cacheTime = $USER->IsAuthorized() ? false : $arParams['CACHE_TIME'];
// Если нужен раздельный кеш по группам:
if ($arParams['CACHE_GROUPS'] === 'Y') {
    $userGroups = CSaleUser::GetUserGroups();
    sort($userGroups);
    $cacheId = serialize([$baseParams, $userGroups]);
}

כיצד לפסול מטמון כראוי בעת עדכון נתונים?

מטמון TTL אינו מדויק: פריט ששונה בשעה 10:00 הופך גלוי רק לאחר שעה (אם template.php). עבור נתונים עדכניים, השתמשו בפסילה מבוססת אירועים. מטפלים (Handlers) cacheId עם CACHE_GROUPS מנקים רק את המטמון של בלוק המידע הדרוש.

תיעוד רשמי של 1C-Bitrix: dev.1c-bitrix.ru

מטמון מתויג: פסילה מדויקת

אם רכיב משתמש בנתונים ממספר בלוקי מידע, ניקוי מלא הוא בזבזני. מטמון מתויג רושם תגים ומנקה רק אותם. מטמון מתויג מדויק פי 3 ממטמון TTL: הוא מנקה רק בלוקים שנתוניהם השתנו, ומפחית בקשות חוזרות ב-40% בהשוואה לניקוי מלא.

use Bitrix\Main\Data\TaggedCache;

$taggedCache = new TaggedCache();
$taggedCache->startTagCache('/custom/my.component/');

if ($this->StartResultCache($cacheTime, $cacheId, $cacheDir)) {
    $taggedCache->registerTag('iblock_id_' . $arParams['IBLOCK_ID']);
    $taggedCache->registerTag('iblock_element_' . $elementId);
    $this->arResult = $this->getData();
    $this->IncludeComponentTemplate();
    $taggedCache->endTagCache();
    $this->EndResultCache();
} else {
    $taggedCache->abortTagCache();
}

פסילה לפי תג כאשר פריט משתנה:

$taggedCache = new TaggedCache(); $taggedCache->clearByTag('iblock_element_' . $arFields['ID']); 

ניפוי באגים במטמון

ניתן להשבית מטמון עבור רכיב ספציפי במצב פיתוח על ידי הגדרת global $USER; $cacheTime = $USER->IsAuthorized() ? false : $arParams['CACHE_TIME']; // Если нужен раздельный кеш по группам: if ($arParams['CACHE_GROUPS'] === 'Y') { $userGroups = CSaleUser::GetUserGroups(); sort($userGroups); $cacheId = serialize([$baseParams, $userGroups]); } . צפייה במטמון: קבצים ב-CACHE_TIME=3600 הם קבצי PHP עם נתונים מסודרים (serialized). זמן יצירת הקובץ הוא זמן החימום האחרון.

מה כלול בעבודה

• ביקורת על המטמון הנוכחי עבור כל הרכיבים המותאמים אישית עם דוח מסופק
• פיתוח סכימת מטמון (בלוקי מידע, HL-blocks, נתוני משתמש)
• יישום: שילוב StartResultCache, הגדרת cacheId, פסילת מטמון מבוססת אירועים או מתויגת
• בדיקות עומס (מדידת זמן יצירה ומספר שאילתות מסד נתונים)
• תיעוד ומסירת פרויקט

לוחות זמנים להגדרה

מטמון הוא אחד מהאופטימיזציות הבודדות שמספקות תוצאות מיידיות וניתנות למדידה. אנו מבטיחים הפחתה בזמן יצירת העמוד מ-500 אלפיות השנייה ל-20–50 אלפיות השנייה ללא שינוי בלוגיקת האפליקציה.

לייעוץ בנושא הגדרת מטמון לרכיבים שלכם, צרו קשר — ננתח את הפרויקט שלכם ונציע את הפתרון האופטימלי.