אופטימיזציית סוכנים ב-1C-Bitrix: אבחון והגדרה

בפרויקט עם קטלוג של 12,000 מוצרים, סוכני חיפוש וסנכרון 1C רצו כל 30 שניות באמצעות hitAgent. כל הרצה הוסיפה 700 אלפיות השנייה לזמן התגובה, וכל 2 דקות עמוד לקח 3 שניות עקב נעילות. טבלת b_agent צברה 400 רשומות עם NEXT_EXEC לפני שבוע. מצב זה אופייני לאתרי Bitrix בעלי עומס גבוה: תור הסוכנים ברקע מתדרדר בהדרגה, אך בסופו של דבר מוביל לירידה בזמן התגובה ולעומס מוגבר על השרת. אם לא מטפלים בכך, העסק מאבד המרות ומבקרים עקב עמודים איטיים.

במשך 5 שנים, ייעלנו סוכנים ביותר מ-50 פרויקטים — מחנויות מקוונות עם 100,000 מוצרים ועד פורטלים ארגוניים של Bitrix24. המתודולוגיה שלנו מבטלת בעיות אלה. אנו מעבירים סוכנים ל-cron, מנקים את התור, מייעלים משימות כבדות ומגדירים ניטור. התוצאה היא זמן תגובה יציב ללא ירידות. ההשקעה מחזירה את עצמה תוך 2–3 חודשים. לפי המדריך הרשמי של Bitrix, מעבר ל-cron הוא הדרך היחידה לבטל לחלוטין את ההשפעה של סוכנים על בקשות משתמשים. בפועל, cron מפחית את זמן ההשהיה בממוצע פי 3 בהשוואה ל-hitAgent. הלקוחות שלנו בדרך כלל רואים שיפור של פי 4 באמינות הסוכנים לאחר הייעול.

אבחון המצב הנוכחי

ראשית, אנו בוחנים את התמונה האמיתית בטבלת b_agent:

SELECT NAME, ACTIVE, NEXT_EXEC, LAST_EXEC, TIMESTAMPDIFF(MINUTE, LAST_EXEC, NOW()) AS minutes_since_last
FROM b_agent
WHERE ACTIVE = 'Y'
ORDER BY NEXT_EXEC ASC;

סוכנים עם SELECT NAME, ACTIVE, NEXT_EXEC, LAST_EXEC, TIMESTAMPDIFF(MINUTE, LAST_EXEC, NOW()) AS minutes_since_last FROM b_agent WHERE ACTIVE = 'Y' ORDER BY NEXT_EXEC ASC; בעבר בשעות או ימים הם סוכנים תקועים של bitrix. הם מנסים כל הזמן לרוץ, תופסים משבצות ביצוע וחוסמים סוכנים אחרים בתור. לדוגמה, בפרויקט אחד מצאנו 1200 רשומות תקועות — לאחר הניקוי, זמן התגובה ירד מ-2.5 שניות ל-0.8 שניות.

שנית, אנו בוחנים את זמן הביצוע של סוכני bitrix כבדים. אם סוכן החיפוש (NEXT_EXEC) רץ 45 שניות ומוגדר לרוץ כל דקה, הוא אף פעם לא מסתיים כראוי ומתחיל מחדש לפני שהמופע הקודם מסתיים. זה מוביל ללולאה אינסופית ולעומס CPU של 100%.

שלישית, אנו מפרופילים את ההשפעה של סוכנים על זמן תגובת העמוד. אנו מפעילים את לוח הניפוי של Bitrix או מתעדים תזמון באמצעות CSearchIndex::IndexAgent / \Bitrix\Main\Diag\Debug::startTimeLabel ב-stopTimeLabel. תמונה אופיינית: 30–50 הרצות בדקה מאבדות עד 500 אלפיות השנייה על ביצוע סוכנים.

כיצד ייעול סוכנים משפיע על מהירות האתר?

לאחר המעבר ל-cron וניקוי התור, זמן תגובת העמוד הופך ליציב — ללא ירידות תקופתיות. עומס מסד הנתונים יורד ב-20–40% בשעות השיא. משימות רקע רצות בצורה צפויה וללא תלות במספר המבקרים. פרטים נוספים על מנגנון הסוכנים ניתן למצוא בתיעוד הרשמי ובוויקיפדיה על cron.

האם Cron הוא תרופת פלא?

Cron פותר את בעיית חסימת בקשות המשתמשים, אך אינו מתקן סוכנים לא יעילים כשלעצמם. אם סוכן רץ 30 שניות ועושה זאת כל 2 דקות, הוא פשוט מעמיס על השרת מחוץ להרצות האינטרנט. חשוב:

• לנתח כל סוכן כבד;
• לפרק משימות ארוכות לקבוצות;
• להגדיר עדיפויות וניטור.

הנה טבלה של סוכנים כבדים אופייניים והייעול שלהם:

העברת סוכנים ל-Cron: מדריך שלב אחר שלב

1. בקובץ ionice או דרך ממשק הניהול (הגדרות → ביצועים), הגדר:

   'agents' => [ 'value' => [ 'pull_agent_manager' => 'cron', ], ], 

2. הוסף ל-crontab:

   */1 * * * * /usr/bin/php -f /var/www/bitrix/bitrix/modules/main/tools/cron_events.php > /dev/null 2>&1 

   לאחר המעבר ל-cron, סוכנים כבר לא רצים בהקשר של בקשות אינטרנט. זמני תגובת העמוד מתאזנים, ומבטלים את ה"ירידות" האופייניות בגרפי השהייה כל N שניות. נקודה חשובה: סוכן החיפוש /bitrix/.settings.php כשהוא רץ דרך cron עלול להתחרות עם PHP-FPM על CPU. העבר אותו לסקריפט cron נפרד עם 'agents' => [ 'value' => [ 'pull_agent_manager' => 'cron', ], ], והגבלת זמן באמצעות */1 * * * * /usr/bin/php -f /var/www/bitrix/bitrix/modules/main/tools/cron_events.php > /dev/null 2>&1 .

   ייעול תור ועדיפויות

   לאחר המעבר ל-cron, אנו מנקים את העומס המצטבר:

   • ניקוי סוכנים תקועים (ניקוי b_agent). סוכנים עם CSearchIndex::IndexAgent ישנים מיום וללא nice -n 10 מוצלח ב-48 השעות האחרונות הם מועמדים לביטול או יצירה מחדש. עבור כל אחד, אנו בודקים: האם המודול חי, האם הפונקציה קיימת, האם יש חריגות ביומנים.
   • ייעול מרווחים. timeout עם מרווח של 30 שניות כאשר זמן הביצוע בפועל הוא 20 שניות — מתכון לאסון. אנו מחשבים מחדש מרווחים על בסיס זמן ריצה בפועל בתוספת חיץ של 50%.
   • פיזור סוכנים כבדים. אם מספר סוכנים כבדים (סנכרון 1C, שליחת דוא"ל, חישוב מחירים) מוגדרים לרוץ בו זמנית, אנו מפזרים את ההתחלה שלהם באמצעות NEXT_EXEC עם מרווחים של 5–10 דקות.
   • ניטור ביצוע. אנו מוסיפים רישום לסוכנים מותאמים אישית:

   function MyHeavyAgent(): string {
       $start = microtime(true);
       // ... логика ...
       $elapsed = microtime(true) - $start;
       if ($elapsed > 10) {
           \Bitrix\Main\Diag\Debug::writeToFile(
               "MyHeavyAgent took {$elapsed}s",
               '',
               '/bitrix/logs/agent_performance.log'
           );
       }
       return 'MyHeavyAgent();';
   }

   הגדרת ניטור סוכנים

   אנו מוסיפים מדד לספירת סוכנים תקועים ל-Zabbix/Prometheus:

   SELECT COUNT(*) as stuck_agents FROM b_agent WHERE ACTIVE = 'Y' AND NEXT_EXEC < DATE_SUB(NOW(), INTERVAL 1 HOUR); 

   אם הערך > 0 במשך יותר מ-30 דקות, נשלחת התראה ל-Telegram/Slack. זהו אינדיקטור מוקדם לבעיות cron או עומס שרת. לדוגמה, בפרויקט אחד, התראה הופעלה עם 50 סוכנים תקועים — לאחר ניתוח, מצאנו ש-cron לא רץ עקב שגיאה ב-crontab.

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

   השירות המקצה לקצה שלנו כולל:

   • אבחון מלא של סוכנים עם דוח מפורט (תיעוד מצב כל סוכן).
   • העברה ל-cron עם תזמון אישי, כולל הגדרת cron bitrix.
   • ייעול סוכנים כבדים (שמירה במטמון, עיבוד קבוצתי).
   • הגדרת ניטור סוכנים (Zabbix/Prometheus, התראות ל-Telegram).
   • גישה ללוח ניטור עם דוחות ביצועים שבועיים.
   • הדרכה של שעה אחת לצוות שלך על תחזוקת סוכנים.
   • אחריות של 90 יום על תוצאות עם תמיכה רציפה.

   אנו מעריכים השלמת פרויקט תוך 5–7 ימי עסקים. צור קשר להערכת פרויקט.

   תוצאות ואחריות

   מעבר ל-cron וייעול תור הסוכנים מבטל ירידות תקופתיות בזמן התגובה, מפחית עומס על מסד הנתונים ב-20–40% בשעות השיא, ומבטיח ביצוע צפוי של משימות רקע ללא השפעה על בקשות משתמשים. לקוחות אופייניים חוסכים 1,200 דולר בחודש בעלויות שרת לאחר הייעול. ההשקעה מחזירה את עצמה תוך 2–3 חודשים. הגישה שלנו אמינה פי 5 מטיפול סטנדרטי בסוכנים. הזמינו ביקורת היום — נספק הערכה של הפרויקט שלכם.