משתמש לוחץ על 'בצע הזמנה' ורואה ספינר למשך 4 שניות—השרת שולח באופן סינכרוני שלושה אימיילים, מחשב מחדש בונוסים וקורא ל-API של המשלוחים. זמן ההשבתה עולה, ההמרה יורדת. אנו נתקלים בכך בכל פרויקט שני בעומס גבוה.
פונקציות נדחות פותרות את הבעיה: תגובת ה-HTTP חוזרת תוך 200 מ״ש, בעוד שפעולות כבדות מבוצעות ברקע לאחר סגירת החיבור. זה מפחית את העומס על השרת ומשפר את שביעות הרצון של המשתמשים.
אילו בעיות פותרות פונקציות נדחות?
עיבוד סינכרוני של כל הפעולות בבקשה מוביל לזמן המתנה מוגזם עבור הלקוח. פעולות אופייניות שניתן להעביר לעיבוד נדחה: שליחת דואר אלקטרוני/SMS (200–500 ms), רישום ל-ELK או Sentry, ביטול תוקף של מטמון מתויג, קריאות ל-API חיצוני (CRM, שירותי משלוחים).
כל פעולה כזו מגדילה את זמן התגובה, וסכומן יכול להגיע למספר שניות. פונקציות נדחות מבודדות משימות אלו ומחזירות את השליטה למשתמש באופן מיידי.
איך פועלות פונקציות נדחות?
החל מגרסאות ה-PHP הנוכחיות, ליבת Bitrix תומכת ב-register_shutdown_function ובמנגנון משלה דרך Bitrix\Main\Application::getInstance()->addBackgroundJob().
הרעיון: הפונקציה נרשמת ומתבצעת לאחר fastcgi_finish_request() (עבור PHP-FPM) או לאחר שליחת התגובה עבור Apache mod_php דרך register_shutdown_function. ההבדל קריטי: ב-PHP-FPM החיבור נסגר לפני ביצוע המשימה, ב-mod_php הוא אינו נסגר.
use Bitrix\Main\Application;
Application::getInstance()->addBackgroundJob(function () {
// הקוד מתבצע AFTER שליחת התגובה ללקוח
\Bitrix\Main\Mail\Event::send([...]);
// רישום ביומן, קריאת API, חישוב מחדש של נתונים
});
ניואנס קריטי: addBackgroundJob עובד רק אם fastcgi_finish_request זמין. בדיקה: function_exists('fastcgi_finish_request'). ב-Apache mod_php הפונקציה תתבצע לפני שליחת התגובה.
תצורה שלב-אחר-שלב של פונקציות נדחות
- בדיקת הסביבה. יש להריץ
phpinfo()ולמצוא אתfastcgi_finish_requestבקטע PHP-FPM. אם הפונקציה חסרה, יש לעבור ל-PHP-FPM או להשתמש ב-cron. - זיהוי פעולות כבדות. יש לבצע פרופיילינג לדפים באמצעות כלי הפרופיילינג המובנה של Bitrix. יש לזהות בלוקים שלוקחים יותר מ-100 ms: שליחת אימיילים, לוגים, קריאות API.
- עטיפתן ב-
addBackgroundJob. עבור כל מטפל אירועים (למשל,OnSaleOrderSaved), יש להחליף את הקריאה הסינכרונית בקריאה ברקע. - תצורת timeouts. בתצורת מאגר PHP-FPM, יש להגדיר
request_terminate_timeout=300כדי שמשימות רקע לא יופסקו. - בדיקה. יש למדוד את זמן התגובה לפני ואחרי. יש להשוות באמצעות ab או JMeter.
לביצוע מובטח ב-PHP-FPM, יש לבדוק גם את max_execution_time ב-php.ini—הוא צריך להיות לפחות גבוה באותה מידה. מומלץ לנטר לוגים עבור הפסקות מוקדמות.
מדוע פונקציות נדחות טובות יותר מעיבוד סינכרוני?
פונקציות נדחות מפחיתות את זמן התגובה למשתמש פי 3–5. בפרויקט אחד, העברנו שלושה אימיילים ותיעוד מחוץ לזרימה הסינכרונית—זמן ביצוע ההזמנה ירד מ-4.5 שניות ל-0.3 שניות. זה משפיע ישירות על ההמרה: כל עיכוב של 100 מ"ש מפחית את ההמרה ב-1%. החיסכון במשאבי השרת מגיע ל-40%.
| קריטריון | פונקציות נדחות | תור משימות (Bitrix Queue) | Cron |
|---|---|---|---|
| זמן ביצוע | לאחר תגובת הלקוח | אסינכרונית, במקביל | מתוזמן |
| הבטחת ביצוע | לא (קריסת PHP) | כן (ניסיונות חוזרים) | כן (אם מוגדר נכון) |
| מורכבות ההגדרה | נמוכה | בינונית | גבוהה |
| ניטור | לא | מובנה | דרך לוגים |
פונקציות נדחות מנצחות במהירות ההטמעה ובעומס תשתית מינימלי. אם המשימה קריטית—יש להשתמש בתור.
| מדד | לפני | אחרי |
|---|---|---|
| זמן תגובה ממוצע | 4.5 ש' | 0.3 ש' |
| בקשות בשנייה | 10 | 150 |
| שימוש ב-CPU | 80% | 30% |
מתי להשתמש בפונקציות נדחות?
- שליחת דוא"ל/SMS לאחר ביצוע הזמנה—השהיה של 200–500 אלפיות שנייה לכל הודעה
- רישום ליומן לקובץ או לשירות חיצוני (ELK, Sentry)
- ביטול תוקף מטמון מתויג לאחר עדכון קטלוג
- קריאות API חיצוניות: התראת CRM, עדכון שירות מחסן
- אינדוקס מחדש של רכיב לאחר שינוי
טעויות אופייניות בהגדרה
- שימוש בפונקציות נדחות ב-Apache mod_php ללא בדיקת
fastcgi_finish_request—הפונקציה רצה באופן סינכרוני. request_terminate_timeoutקצר מדי—משימות רקע לא מסתיימות.- היעדר טיפול בשגיאות בתוך
addBackgroundJob—חריגים עלולים ליפול מחוץ להקשר ולא להיות מתועדים. - העברת פעולות קריטיות (למשל, פיסקליזציה) ללא גיבוי—אובדן נתונים בעת כשל.
דוגמה מעשית
בפרויקט מסחר אלקטרוני עם 50,000 הזמנות בחודש, העברנו את שליחת האימיילים (3 אימיילים לכל הזמנה), הלוגים וקריאות ה-API של CDEK לפונקציות נדחות. זמן התגובה בעמוד ביצוע ההזמנה ירד מ-4.5 שניות ל-0.3 שניות. העומס על השרת ירד ב-40%, מה שאיפשר לנו לוותר על צומת נוסף. ההטמעה החזירה את ההשקעה תוך פחות משבוע בזכות הפחתת העומס.
מה כלול בהגדרה
- בדיקת תאימות סביבת השרת (PHP-FPM,
fastcgi_finish_request) - העברת מטפלי אירועים כבדים ל-
addBackgroundJob - הגדרת
request_terminate_timeoutב-PHP-FPM - ניטור: תיעוד זמן ביצוע של משימות רקע
- בדיקה: מדידת זמן תגובה לפני ואחרי העברת פעולות לפונקציות נדחות
איך אנחנו עוזרים
יישמנו פונקציות נדחות ביותר מ-30 פרויקטים. המהנדסים שלנו מכירים את כל הדקויות של fastcgi_finish_request ותצורת PHP-FPM. אנו מספקים תיעוד ותמיכה לאחר ההטמעה. קבלו ייעוץ—נעריך את הפרויקט שלכם תוך יום אחד. צרו קשר כדי לגלות אם האתר שלכם מתאים לאופטימיזציה הזו.
על פי התיעוד הרשמי של PHP, fastcgi_finish_request זמין רק בעת שימוש ב-FastCGI Process Manager. fastcgi_finish_request
בנוסף, עיינו בתיעוד של addBackgroundJob בפורטל הרשמי של 1C-Bitrix.