אופטימיזציה לביצועי ביטריקס: העברת סוכנים ל-Cron למהירות

מדוע מצב Hit-Mode הוא צוואר בקבוק

תארו לעצמכם: חנות מקוונת לחומרי בניין עם קטלוג של 200,000 מוצרים. בשעות השפל, דפים נטענים תוך שנייה, אבל במהלך היום, 10% מהבקשות מואטות ל-8 שניות. הסיבה: סוכני Bitrix הפועלים ב'מצב Hit'. כל בקשת HTTP בודקת את טבלת b_agent, ואם זמן הביצוע הגיע, הסוכן רץ באופן סינכרוני, וגורם למשתמש להמתין. בעומס שיא (100+ משתמשים במקביל), זה יכול לגרום לאפקט 'האטה מדורגת': זמן התגובה גדל באופן אקספוננציאלי, ועומס השרת גדל פי 2-3. "לאחר ההעברה, מהירות האתר שלנו השתפרה פי 10" — ציין לקוח אחד.

אנחנו עוזרים להעביר סוכני 1C-Bitrix ל-cron — זה מעביר משימות רקע מבקשות HTTP לתהליך מתוזמן נפרד. התוצאה: מהירות אתר יציבה ללא קשר לתנועה וחיסכון במשאבי שרת (עד 30% הפחתת CPU, שווה ערך ל-$100–$200 לחודש על VPS טיפוסי). צרו קשר לאבחון המצב הנוכחי — נעריך את המצב תוך יום אחד.

שלוש בעיות של פעולת Hit-Mode

1. חוסר יכולת חיזוי. סוכן עם תקופה של 300 שניות רץ רק כשהמבקר הבא מגיע. בלילה, עם תנועה נמוכה, הביצוע יכול להתעכב שעות. זה קריטי במיוחד עבור סנכרון 1C ומשימות התראות.
2. האטות בעמוד. סוכן כבד (סנכרון 1C, שליחת מיילים) מתבצע במהלך הבקשה, ומגדיל את זמן התגובה למשתמש ספציפי. התוצאה: עד 7% אובדן המרות לכל שנייה של עיכוב.
3. מגבלת זמן. max_execution_time (בדרך כלל 30-60 שניות) יכול להפריע לסוכן, ולהשאיר את המשימה לא שלמה. זה מוביל לשכפול נתונים ושגיאות.

יתרונות Cron: טבלת השוואה

Cron יעיל עד פי 10 יותר ממצב Hit עבור סוכנים כבדים.

איך להעביר סוכנים ל-Cron בצורה נכונה

שלב 1. בדיקת המצב הנוכחי

בפאנל הניהול: "הגדרות → הגדרות מודול → מודול ראשי". הפרמטר "שימוש בסוכנים" — אם מוגדר ל"מצב Hit", יש צורך בהעברה. כמו כן, הריצו SQL: SELECT NAME, LAST_EXEC, NEXT_EXEC FROM b_agent WHERE ACTIVE='Y' ORDER BY LAST_EXEC DESC LIMIT 20; — אם NEXT_EXEC מפגר אחרי LAST_EXEC ביותר משעה, זה סימן עקיף לבעיה.

שלב 2. הגדרת Crontab

התחברו דרך SSH ופתחו את crontab:

crontab -e -u bitrix 

הוסיפו שורות:

# Агенты Битрикс — каждую минуту
* * * * * /usr/bin/php -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php > /dev/null 2>&1
# Очередь почтовых событий — каждые 5 минут
*/5 * * * * /usr/bin/php -f /home/bitrix/www/bitrix/modules/main/tools/event_exec.php > /dev/null 2>&1

בדקו את נתיב PHP עם crontab -e -u bitrix . כדי להגן מפני תהליכים מקבילים, הוסיפו # Агенты Битрикс — каждую минуту * * * * * /usr/bin/php -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php > /dev/null 2>&1 # Очередь почтовых событий — каждые 5 минут */5 * * * * /usr/bin/php -f /home/bitrix/www/bitrix/modules/main/tools/event_exec.php > /dev/null 2>&1 :

* * * * * /usr/bin/flock -n /tmp/bitrix_cron.lock /usr/bin/php -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php > /dev/null 2>&1 

שלב 3. החלפת מצב ב-Bitrix

לאחר הגדרת cron ובדיקה (הריצו סקריפט ידנית: which php), החליפו את האפשרות ל"דרך Cron" ושמרו. נקו את מטמון הפלטפורמה. מומלץ לבדוק על עותק staging תחילה.

שלב 4. אימות ביצוע

הריצו SQL:

SELECT NAME, LAST_EXEC, NEXT_EXEC FROM b_agent WHERE ACTIVE='Y' ORDER BY LAST_EXEC DESC LIMIT 20; 

flock צריך להתעדכן כל דקה. אם לא, בדקו את יומן cron של המערכת (* * * * * /usr/bin/flock -n /tmp/bitrix_cron.lock /usr/bin/php -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php > /dev/null 2>&1 ) ופלט שגיאות PHP. כמו כן, הגדירו ניטור — למשל, שליחת התראת Telegram אם סוכן לא רץ יותר מ-5 דקות.

למה Cron חוסך במשאבי שרת?

במצב Hit, כל בקשה מעמיסה על השרת על ידי קריאה ל-/usr/bin/php -f /path/to/cron_events.php. בתצורות חלשות (1-2 ליבות), זה יכול לקחת עד 200-300 אלפיות השנייה לבקשה. ב-1000 בקשות לשעה, זה 50-80 שניות נוספות של זמן CPU לשעה. Cron מסיר לחלוטין את העומס הזה, והתהליך ברקע רץ 1-2 שניות לדקה.