לעתים קרובות אנו רואים: אתר Bitrix עם עדכוני מחירים ומלאי ידניים — שגיאות, עיכובים, אובדן מכירות. לקוח אחד הגיע אלינו עם קטלוג של 15,000 פריטים: המחירים עודכנו פעם בשבוע ידנית דרך Excel. תוך חודש, ההפסדים ממבצעים שפגו תוקפם הגיעו ל-8% מהמחזור. ניתוח חד-פעמי לא פותר את הבעיה — צריך ביצוע אוטומטי מתוזמן. הגדרת מנתח על לוח זמנים (cron) עבור 1C-Bitrix היא משימה מרכזית באוטומציה של עדכוני נתונים. אנו בוחרים את המנגנון (סוכני Bitrix לעומת cron מערכתי), מיישמים נעילת ריצה מקבילה, מגדירים רישום (logging) והתראות. התוצאה: נתונים מתעדכנים אוטומטית, ללא התערבות אנושית.
כיצד cron מערכתי פותר את בעיית עדכון הנתונים?
סוכנים (b_agent) הם המנגנון המובנה של Bitrix. הם מופעלים רק כאשר מבקר נכנס לאתר ו-CAgent::CheckAgents() רץ. עם תעבורה נמוכה, הסוכנים רצים באיחור. מצב ההפעלה המדויק דרך cron פותר את הבעיה אך דורש הגדרת cron מערכתי. הניסיון שלנו מראה: עבור מנתחים שמתעדכנים כל 30 דקות, cron מערכתי אמין יותר.
cron מערכתי קורא ישירות ל-PHP-CLI. אין תלות בשרת האינטרנט:
*/30 * * * * /usr/bin/php -f /var/www/site/local/scripts/parser_run.php >> /var/log/parser.log 2>&1 עבור מנתחים כבדים (10,000+ פריטים), cron מערכתי עדיף — אין מגבלות זמן ביצוע של PHP-FPM. אנו מבטיחים ביצוע יציב בכל זמן, גם כשהאתר לא פעיל.
מדוע אנו ממליצים על cron מערכתי עבור מנתחים כבדים?
בפרויקט עם 50,000 מוצרים שמתעדכנים כל 30 דקות, הסוכנים התקשו: עם 200 מבקרים ביום, הביצוע נדחה ב-10-15 דקות. המעבר ל-cron מערכתי ביטל את העיכובים — העדכונים הפכו מדויקים עד השנייה. עלויות התמיכה ירדו ב-30% בזכות האוטומציה.
כיצד להגן על המנתח מפני ריצות מקבילות?
המנתח רץ במשך 25 דקות, cron מפעיל את הבא אחרי 30 — שני מופעים לא יחפפו. אבל מה אם הסקריפט נתקע ל-35 דקות? צריך הגנה. אנו משתמשים בנעילה מבוססת קבצים או Redis:
$lockFile = '/tmp/parser_' . md5($parserName) . '.lock';
if (file_exists($lockFile) && (time() - filemtime($lockFile)) < 3600) {
exit('Already running');
}
touch($lockFile);
// ... работа парсера ...
unlink($lockFile);עבור מערכות מבוזרות (מספר שרתים) — נעילת Redis: */30 * * * * /usr/bin/php -f /var/www/site/local/scripts/parser_run.php >> /var/log/parser.log 2>&1 . המחיר של שגיאת ריצה מקבילה: נתונים כפולים ועומס על השרת. אנו מתחשבים בכך בכל פרויקט.
סוכנים או cron: מה לבחור? השוואה
| קריטריון | סוכני Bitrix ($lockFile = '/tmp/parser_' . md5($parserName) . '.lock'; if (file_exists($lockFile) && (time() - filemtime($lockFile)) < 3600) { exit('Already running'); } touch($lockFile); // ... работа парсера ... unlink($lockFile); ) |
cron מערכתי |
|---|---|---|
| תלות בתעבורה | כן | לא |
| מגבלת זמן ביצוע | מוגבל על ידי PHP-FPM (בדרך כלל 300 שניות) | אין מגבלה (PHP-CLI) |
| דיוק ההפעלה | ± כמה דקות בעומס נמוך | ± שנייה |
| מורכבות ההגדרה | מובנה, אין צורך בגישה לשרת | דורש SSH והרשאות |
| מתאים למנתחים כבדים | בתנאי | כן |
| תמיכה ברישום | דרך שיטות סוכן | מוגדר בנפרד |
הגדרת cron שלב אחר שלב עבור מנתח
- קבע את פקודת ההפעלה — נתיב מלא ל-PHP ולסקריפט. בדוק גרסה:
SET lock:parser NX EX 3600. - הגדר רישום — הפנה stdout ו-stderr לקובץ לוג עם תאריך.
- הוסף את המשימה ל-crontab —
b_agent, ציין לוח זמנים ופקודה. - יישם נעילה — קובץ נעילה או Redis.
- בדוק — הרץ את הפקודה ידנית, בדוק את הלוגים.
- הגדר התראות — שלח הודעות על שגיאות.
אנו מיישמים אלגוריתם זה בכל פרויקט — זה מקצר את זמן הדיבוג ב-40%.
הגדרת סוכני Bitrix לניתוח
אם עדיין משתמשים בסוכנים — רשום דרך which php:
CAgent::AddAgent(
'MyParserAgent::Run();', // функция-агент
'mymodule', // модуль
'N', // не точный
3600, // интервал в секундах
'', // дата первого запуска
'Y', // активный
date('d.m.Y H:i:s', time() + 3600) // следующий запуск
);הסוכן חייב להיות רשום ב-crontab -e של המודול או ב-CAgent::AddAgent(). עבור סביבת ייצור, אנו ממליצים לשלב עם cron מערכתי דרך תיעוד 1C-Bitrix. זה נותן גמישות ודיוק מקסימליים.
מה מספק רישום מובנה?
מנתח ללא לוגים הוא קופסה שחורה. סכמה מינימלית:
file_put_contents($logFile, date('[Y-m-d H:i:s] ') . $message . PHP_EOL, FILE_APPEND); עבור סביבת ייצור — לוגים מובנים עם רמות (info/warning/error) ורוטציה דרך CAgent::AddAgent( 'MyParserAgent::Run();', // функция-агент 'mymodule', // модуль 'N', // не точный 3600, // интервал в секундах '', // дата первого запуска 'Y', // активный date('d.m.Y H:i:s', time() + 3600) // следующий запуск ); . התראה על שגיאה: אם הלוג של הריצה האחרונה מכיל include.php שורות — שלח אימייל דרך init.php. זה מקצר את זמן התגובה לתקלות ומחצית את עלויות התמיכה. לפי המלצות Bitrix, ניטור כזה הוא חובה עבור עדכונים קריטיים.
מה כלול בעבודה
- ביקורת על המנתח הקיים או כתיבת אחד חדש
- בחירה והגדרה של מנגנון ההפעלה (cron/סוכנים)
- יישום נעילת ריצה מקבילה
- הגדרת רישום והתראות
- בדיקת לוח זמנים ובדיקת תרחישי שגיאה
- תיעוד על גישה ותפעול המנתח
- אחריות ליציבות למשך שבוע לאחר ההשקה
לוח זמנים
| שלב | משך |
|---|---|
| הגדרת cron מערכתי או סוכן Bitrix | 1–2 שעות |
| יישום נעילת ריצה מקבילה | 1–2 שעות |
| הגדרת רישום והתראות | 2–4 שעות |
| בדיקת לוח זמנים | 2–4 שעות |
סה"כ: 6–12 שעות. המחיר מחושב באופן אישי — נבחן את הפרויקט שלך תוך יום עסקים אחד.
קבל ייעוץ על הגדרת מנתח — כתוב לנו, נמצא את הפתרון הטוב ביותר לתקציב שלך. השאר בקשה — נספר לך כיצד לאוטומט עדכוני נתונים בפרויקט שלך. צור קשר כדי להתחיל באוטומציה היום.

