הגדרת פונקציות דחויות ב-1C-Bitrix

משתמש לוחץ על 'בצע הזמנה' ורואה ספינר במשך 4 שניות—השרת שולח שלושה מיילים באופן סינכרוני, מחשב מחדש בונוסים, וקורא ל-API של המשלוח. זמן ההמתנה גדל, ההמרה יורדת. אנו נתקלים בזה בכל פרויקט שני בעומס גבוה. פונקציות דחויות פותרות את הבעיה: תגובת ה-HTTP
השירותים שאנו מציעים
מציג 1 מתוך 1כל 1626 השירותים
הגדרת פונקציות דחויות ב-1C-Bitrix
פשוט
~1 יום

הכישורים שלנו:

שאלות נפוצות

העבודות האחרונות

  • image_website-b2b-advance_0.webp
    פיתוח אתר חברה B2B ADVANCE
    1460
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    פיתוח אתר לחברת FIXPER
    1019
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    פיתוח מבוסס Bitrix, Bitrix24, 1C לחברה פיתוח ווידג'ט להזמנת תורים אונליין למרכז רפואי
    763
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    פיתוח על בסיס 1C Enterprise עבור MIRSANBEL
    882
  • image_crm_dolbimby_434_0.webp
    פיתוח אתר על CRM Bitrix24 עבור DOLBIMBY
    809
  • image_crm_technotorgcomplex_453_0.webp
    פיתוח על בסיס Bitrix24 עבור חברת TECHNOTORGKOMPLEKS
    1164

משתמש לוחץ על 'ביצוע הזמנה' ורואה ספינר במשך 4 שניות—השרת שולח באופן סינכרוני שלושה מיילים, מחשב מחדש בונוסים, וקורא ל-API של משלוחים. זמן ההמתנה גדל, ההמרה יורדת. אנו נתקלים בזה בכל פרויקט שני בעומס גבוה. פונקציות דחויות פותרות את הבעיה: תגובת ה-HTTP חוזרת תוך 200 אלפיות השנייה, בעוד פעולות כבדות מתבצעות ברקע לאחר סגירת החיבור. זה מפחית את עומס השרת ומשפר את שביעות רצון המשתמשים.

אילו בעיות פונקציות דחויות פותרות?

עיבוד סינכרוני של כל הפעולות בבקשה מוביל לזמן המתנה מופרז עבור הלקוח. פעולות טיפוסיות שניתן להעביר לרקע: שליחת מייל/SMS (200–500 אלפיות השנייה), רישום לוגים ל-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 () { // Код выполнится ПОСЛЕ отправки ответа клиенту \Bitrix\Main\Mail\Event::send([...]); // Логирование, вызов API, пересчёт данных }); 

ניואנס קריטי: use Bitrix\Main\Application; Application::getInstance()->addBackgroundJob(function () { // Код выполнится ПОСЛЕ отправки ответа клиенту \Bitrix\Main\Mail\Event::send([...]); // Логирование, вызов API, пересчёт данных }); עובד רק אם addBackgroundJob זמין. בדיקה: fastcgi_finish_request. ב-Apache mod_php הפונקציה תתבצע לפני שליחת התגובה.

תצורה שלב אחר שלב של פונקציות דחויות

  1. בדיקת הסביבה. הרץ function_exists('fastcgi_finish_request') ומצא phpinfo() בקטע PHP-FPM. אם הפונקציה חסרה, עבור ל-PHP-FPM או השתמש ב-cron.
  2. זהה פעולות כבדות. נתח דפים באמצעות הפרופילר המובנה של Bitrix. זהה בלוקים שלוקחים יותר מ-100 אלפיות השנייה: שליחת מיילים, רישום לוגים, קריאות API.
  3. עטוף אותם ב-fastcgi_finish_request. עבור כל מטפל אירועים (לדוגמה, addBackgroundJob), החלף את הקריאה הסינכרונית בקריאת רקע.
  4. הגדר timeouts. בתצורת מאגר PHP-FPM, הגדר OnSaleOrderSaved כך שמשימות רקע לא יופסקו.
  5. בדוק. מדוד את זמן התגובה לפני ואחרי. השווה באמצעות ab או JMeter.

לביצוע מובטח ב-PHP-FPM, בדוק גם request_terminate_timeout=300 ב-php.ini—הוא צריך להיות לפחות באותו גובה. מומלץ לנטר לוגים להפסקות מוקדמות.

מדוע פונקציות דחויות עדיפות על עיבוד סינכרוני?

פונקציות דחויות מפחיתות את זמן תגובת המשתמש פי 3–5. בפרויקט אחד, העברנו שלושה מיילים ורישום לוגים מחוץ לזרימה הסינכרונית—זמן ביצוע ההזמנה ירד מ-4.5 שניות ל-0.3 שניות. זה משפיע ישירות על ההמרה: כל עיכוב של 100 אלפיות השנייה מפחית את ההמרה ב-1%. חיסכון במשאבי שרת מגיע ל-40%.

קריטריון פונקציות דחויות תור משימות (Bitrix Queue) Cron
זמן ביצוע לאחר תגובת הלקוח באופן אסינכרוני, במקביל מתוזמן
הבטחת ביצוע לא (קריסת PHP) כן (ניסיונות חוזרים) כן (אם מוגדר נכון)
מורכבות הגדרה נמוכה בינונית גבוהה
ניטור לא מובנה דרך לוגים

פונקציות דחויות מנצחות במהירות היישום ובעומס תשתית מינימלי. אם המשימה קריטית—השתמש בתור.

מדד לפני אחרי
זמן תגובה ממוצע 4.5 שניות 0.3 שניות
בקשות בשנייה 10 150
שימוש במעבד 80% 30%

מתי להשתמש בפונקציות דחויות?

  • שליחת מייל/SMS לאחר ביצוע הזמנה—עיכוב של 200–500 אלפיות השנייה לכל הודעה
  • רישום לוגים לקובץ או לשירות חיצוני (ELK, Sentry)
  • ביטול מטמון מתויג לאחר עדכון קטלוג
  • קריאות API חיצוניות: הודעת CRM, עדכון שירות מחסן
  • אינדוקס מחדש של פריט לאחר שינוי

טעויות הגדרה טיפוסיות

  • שימוש בפונקציות דחויות על Apache mod_php ללא בדיקת max_execution_time—הפונקציה רצה באופן סינכרוני.
  • fastcgi_finish_request קצר מדי—משימות רקע לא מסתיימות.
  • חוסר בטיפול בשגיאות בתוך request_terminate_timeout—חריגות עלולות ליפול מחוץ להקשר ולא להירשם בלוגים.
  • העברת פעולות קריטיות (לדוגמה, פיסקליזציה) ללא fallback—אובדן נתונים במקרה של כשל.

דוגמה מעשית

בפרויקט מסחר אלקטרוני עם 50,000 הזמנות בחודש, העברנו שליחת מיילים (3 מיילים להזמנה), רישום לוגים וקריאות API של CDEK לפונקציות דחויות. זמן התגובה בדף ביצוע ההזמנה ירד מ-4.5 שניות ל-0.3 שניות. עומס השרת ירד ב-40%, מה שאיפשר לנו להוריד צומת נוסף. היישום החזיר את ההשקעה בפחות משבוע בזכות הפחתת העומס.

מה כלול בהגדרה

  • בדיקת תאימות סביבת השרת (PHP-FPM, addBackgroundJob)
  • העברת מטפלי אירועים כבדים ל-fastcgi_finish_request
  • הגדרת addBackgroundJob ב-PHP-FPM
  • ניטור: רישום זמן ביצוע של משימות רקע
  • בדיקות: מדידת זמן תגובה לפני ואחרי העברת פעולות לפונקציות דחויות

כיצד אנו עוזרים

יישמנו פונקציות דחויות ביותר מ-30 פרויקטים. המהנדסים שלנו מכירים את כל הניואנסים של request_terminate_timeout ותצורת PHP-FPM. אנו מספקים תיעוד ותמיכה לאחר היישום. קבל ייעוץ—נעריך את הפרויקט שלך תוך יום אחד. צור קשר כדי לגלות אם האתר שלך מתאים לאופטימיזציה זו.

לפי התיעוד הרשמי של PHP, fastcgi_finish_request זמין רק בעת שימוש ב-FastCGI Process Manager. fastcgi_finish_request

בנוסף, עיין בתיעוד עבור fastcgi_finish_request בפורטל הרשמי של 1C-Bitrix.