מאיצי PHP עבור 1C-Bitrix: הגדרת OPcache, JIT ו-APCu
הפעלתם OPcache, שדרגתם לגרסת PHP העדכנית ביותר, אבל הדפים עדיין נטענים לאט? תרחיש טיפוסי: מטמון bytecode פעיל, אבל Bitrix עדיין מבזבז יותר מדי זמן על חשיבה בכל בקשה. אנחנו נתקלים בזה כמעט בכל פרויקט שני במהלך ביקורות ביצועים. הבעיה היא לרוב הגדרה לא מיושרת של שלושה מנגנונים: OPcache (מטמון bytecode), קומפילציית JIT (PHP 8.0+) ו-APCu (מטמון נתונים בזיכרון). השילוב הנכון מניב שיפור של 20–40% במהירות עיבוד PHP—לפעמים אפילו יותר אם המעבד הוא צוואר הבקבוק.
למה OPcache לבדו לא מספיק
OPcache מאיץ ביצוע חוזר של סקריפטים—ניתוח וקומפילציה מתרחשים רק פעם אחת. אבל Bitrix היא יישום כבד עם אלפי קבצים ולוגיקה מורכבת. אפילו עם OPcache, כל בקשה מבלה זמן באתחול הליבה, טעינת מודולים והתחברות למסד הנתונים. קומפילציית JIT לוקחת את הצעד הבא: היא ממירה bytecode חם לקוד מכונה. השיפור התיאורטי הוא עד פי 5, אבל בפועל, עבור דפי אינטרנט הקשורים לקלט/פלט (מסד נתונים, דיסק), JIT מספק 5–15%. עם זאת, בדפים עם חישובים אינטנסיביים (למשל, הפקת דוחות, עיבוד עגלת קניות), ההשפעה ניכרת.
איך להגדיר JIT כראוי
אנו ממליצים על התצורה הבאה ב-php.ini:
[opcache] opcache.enable = 1 opcache.memory_consumption = 192 opcache.jit = 1255 opcache.jit_buffer_size = 64M הערך [opcache] opcache.enable = 1 opcache.memory_consumption = 192 opcache.jit = 1255 opcache.jit_buffer_size = 64M אינו קסם—זה קוד המציין מצב מעקב ורמת אופטימיזציה. ליציבות, השתמשו ב-1255:
opcache.jit = tracing opcache.jit_buffer_size = 32M מעקב יעיל יותר עבור לולאות, אבל בבקשות קצרות (אופייני ל-Bitrix) הרווח קטן יותר. יש לבחור את המצב בהתאם לפרופיל העומס של הפרויקט הספציפי.
התקנה והגדרה של APCu
APCu מספק חנות מפתח-ערך בזיכרון משותף. Bitrix משתמש בו דרך שכבת המטמון שלו (tracing). התקנה דרך PECL:
pecl install apcu echo "extension=apcu.so" > /etc/php.d/40-apcu.ini תצורה (ב-opcache.jit = tracing opcache.jit_buffer_size = 32M או Bitrix\Main\Data\ManagedCache):
[apcu] apc.enabled = 1 apc.shm_size = 128M apc.ttl = 3600 apc.user_ttl = 3600 apc.gc_ttl = 600 apc.slam_defense = 1 apc.enable_cli = 0 pecl install apcu echo "extension=apcu.so" > /etc/php.d/40-apcu.ini מגן מפני אפקט dog-pile: כאשר ערך מטמון פג, רק תהליך אחד מייצר אותו מחדש; אחרים ממתינים או משתמשים בנתונים מיושנים.
חיבור APCu למטמון Bitrix
בקובץ php.ini, הוסיפו:
define("CACHED_b_file", 3600); define("CACHED_b_agent", 3610); define("CACHED_b_lang", 3600); define("CACHED_b_option", 3600); define("CACHED_b_iblock", 3600); define("BX_CACHE_TYPE", "apc"); define("BX_CACHE_SID", $_SERVER["DOCUMENT_ROOT"] . "/"); לאחר מכן, Bitrix יאחסן מטמון ב-APCu. פסילה מבוססת תגיות—המערכת כותבת תגיות לטבלת /etc/php.d/40-apcu.ini ובודקת אותן בכל בקשה.
השוואת מנגנוני מטמון
| מנגנון | מטרה | רווח אופייני | צריכת זיכרון |
|---|---|---|---|
| OPcache | מטמון bytecode | 30–50% (מעבד) | 128–192 MB |
| JIT | קומפילציית קוד חם | 5–15% | 32–64 MB |
| APCu | מטמון נתונים (תוצאות שאילתות) | 20–40% (מעבד) | 128 MB |
חלק מסובך: מספר אתרים על אותו שרת
APCu חי בזיכרון המשותף של תהליך PHP-FPM. שני אתרים באותו pool חולקים שטח APCu אחד. כדי למנוע מהמטמון של אתר אחד לדרוס את של השני, השתמשו ב-pools נפרדים של PHP-FPM והקצו [apcu] apc.enabled = 1 apc.shm_size = 128M apc.ttl = 3600 apc.user_ttl = 3600 apc.gc_ttl = 600 apc.slam_defense = 1 apc.enable_cli = 0 ייחודי כולל apc.slam_defense = 1 (כמו בדוגמה למעלה).
מה כלול בתצורת מפתח-ביד
- ביקורת על תצורת PHP והשרת הנוכחית
- קביעת פרמטרים אופטימליים של OPcache, JIT ו-APCu בהתבסס על פרופיל העומס
- התקנה והגדרה של הרחבות
- בדיקות ביצועים עם
/bitrix/php_interface/dbconn.phpאו JMeter - הדרכת צוות על יסודות ניטור
- דוח כתוב עם המלצות לאופטימיזציה נוספת
טעויות נפוצות בתצורה
- שכחת השבתת OPcache במצב פיתוח—התוצאה היא קוד "מיושן"
- הגדרת
define("CACHED_b_file", 3600); define("CACHED_b_agent", 3610); define("CACHED_b_lang", 3600); define("CACHED_b_option", 3600); define("CACHED_b_iblock", 3600); define("BX_CACHE_TYPE", "apc"); define("BX_CACHE_SID", $_SERVER["DOCUMENT_ROOT"] . "/");קטן מדי—פינוי מטמון - אי-אימות ש-APCu זמין ב-PHP (
b_cache_tagמחזיר false) - שימוש ב-Swoole או FrankenPHP ללא התאמת קוד—מוביל לדליפות זיכרון וחוסר יציבות
בדיקת התוצאות
מדדו לפני ואחרי עם כלי BX_CACHE_SID:
ab -n 1000 -c 10 http://site.ru/catalog/ | grep "Requests per second" שיפור צפוי בדף קטלוג טיפוסי: 20–40%. אם אין שיפור, צוואר הבקבוק הוא ככל הנראה מסד הנתונים, לא PHP.
הניסיון שלנו: מעל 50 פרויקטי אופטימיזציה של Bitrix עם האצה ממוצעת של 30%. אנו מבטיחים תצורה שקופה והדרכת צוות. צרו קשר להערכה מקדימה—ננתח את התצורה הנוכחית שלכם ונציע תוכנית עבודה.
הערה: לאופטימיזציה עמוקה יותר, שקלו מטמון שרת אינטרנט (nginx fastcgi cache), CDN והגדרת תורים למשימות רקע (Bitrix agents). מידע נוסף על מטמון במסמכי הפיתוח הרשמיים של Bitrix.
רשימת בדיקה לתצורת מאיצים
- [ ] בדיקת גרסת PHP (>=8.0 עבור JIT)
- [ ] התקנת OPcache (מובנה) ו-APCu
- [ ] הגדרת php.ini לפי ההמלצות
- [ ] אימות דרך phpinfo() ש-OPcache ו-APCu פעילים
- [ ] הרצת בדיקות עומס לפני ואחרי







