בדיקת ביצועים לאתרי 1C-Bitrix

דף קטלוג נטען תוך 6 שניות, השרת חזק, האחסון לא מתלונן, אבל הלקוחות עוזבים. ללא כלי אבחון, אנשים מתחילים לנחש: "אולי המטמון לא עובד," "אולי מסד הנתונים איטי." בדיקת הביצועים שלנו מספקת תשובה מדויקת: בדיוק היכן הזמן אובד וכמה ניתן להרוויח. עם ניסיון של למעלה מ-10 שנים ויותר מ-500 בדיקות שבוצעו, בעיות אופייניות חוזרות על עצמן: שאילתות N+1, מטמון מושבת, אינדקסים חסרים. הבדיקה מזהה אותן תוך 3-5 ימים ומספקת תוכנית פעולה קונקרטית.

דמיינו חנות מסחר אלקטרוני על Bitrix עם 10,000 מוצרים; דף קטגוריה נפתח תוך 6 שניות. לקוחות עוזבים, ההמרה יורדת. בדיקות פנימיות לא מגלות דבר—השרת לא עמוס, מסד הנתונים לא איטי. הצעד השיטתי היחיד הוא לבצע בדיקת ביצועים. היא תחשוף את הגורם השורשי לאיטיות ותספק מספרים: כמה שניות ניתן להחזיר בכל שלב. חיסכון ממוצע בזמן טעינה: 40%.

כיצד אנו מאבחנים שאילתות איטיות

BX_DEBUG הוא כלי מובנה של Bitrix. ב-dbconn.php או bitrix/php_interface/init.php:

define('BX_DEBUG', true); 

הוא מציג בתחתית הדף: מספר שאילתות SQL, זמן ביצוע PHP, שימוש בזיכרון, פגיעות מטמון. נורמה: < 50 שאילתות, < 500 אלפיות שנייה זמן PHP לדף קטלוג.

עבור שאילתות כבדות אנו משתמשים ב-EXPLAIN ANALYZE. שאילתות איטיות מתועדות דרך define('BX_DEBUG', true); ב-MySQL או slow_query_log ב-PostgreSQL (סף 200 אלפיות שנייה), ולאחר מכן מנותחת תוכנית הביצוע. זה יעיל פי 5 מאשר לנחש ללא תוכנית. לפי תיעוד MySQL, שימוש ב-EXPLAIN ANALYZE מקצר את זמן ניתוח התוכנית בחצי.

מקרה אמיתי: בפרויקט אחד, הקטלוג היה איטי עקב שאילתות N+1 ברכיב בעבודת יד. לאחר מעבר ל-log_min_duration_statement עם בחירת מאפיינים, הזמן ירד מ-4 שניות ל-1.2 שניות.

מדוע Bitrix מאט בקטלוגים גדולים

N+1 ברכיבים. רשימת מוצרים מבצעת שאילתה אחת לרשימה ושאילתות N למחירים/מאפיינים. עם 50 מוצרים בעמוד, זה 50 שאילתות נוספות ל-GetList. פתרון: b_iblock_element_property עם מאפיינים נדרשים או שליפה בקבוצות.

מטמון מושבת. מפתח כיבה את המטמון במהלך הפיתוח ושכח להפעיל אותו מחדש. בדקו הגדרות רכיב ותצורה גלובלית. הפעלת המטמון יכולה להפחית את זמן התגובה פי 3-5.

חוסר אינדקסים בטבלאות מותאמות אישית. טבלאות משתמש נוצרות ללא אינדקסים, ואז שאילתות עם select גורמות לסריקת טבלה מלאה על מיליוני שורות.

סוכנים כבדים בחוט האינטרנט. WHERE נקרא בכל כניסה אם cron לא מוגדר. סוכנים עם לוגיקה כבדה מאטים כל דף.

כיצד בדיקת ביצועים שונה מבדיקת מהירות רגילה

בדיקה רגילה דרך שירותים מקוונים מציגה רק מדדים חיצוניים: TTFB, זמן טעינת משאבים. בדיקה נכנסת פנימה: מפרופלת קוד PHP, מנתחת שאילתות SQL, בודקת תצורת מטמון והגדרות שרת. ההבדל בדיוק הוא כמו בין מד לחץ דם ל-MRI—האחרון רואה את הבעיה ברמת הקוד והנתונים.

מה אנו בודקים במהלך הבדיקה

הנה דוגמה לתוצאות בדיקה אופייניות:

לפי תיעוד המטמון של 1C-Bitrix, הפעלת מטמון מתויג יכולה להפחית את עומס השרת פי 5.

תהליך העבודה

1. איסוף מדדים — הפעלת BX_DEBUG, slow_query_log, הגדרת Xdebug. פרופיל דפים אופייניים.
2. ניתוח — בחינת תוכניות שאילתות SQL, חיפוש N+1, בדיקת אינדקסים, סוכנים, הגדרות מטמון.
3. דוח — יצירת טבלת צווארי בקבוק עם הערכת השפעה (בשניות) ומאמץ לתיקון.
4. המלצות — תוכנית מסודרת לפי עדיפות: מה לעשות קודם להאצה מקסימלית.
5. תמיכה — במידת הצורך, סיוע ביישום אופטימיזציות (הגדרת cron, תיקוני רכיבים, מיגרציות).

טעויות אופטימיזציה אופייניות

• cron לא מוגדר לסוכנים — כל כניסה מפעילה CAgent::CheckAgents().
• אין אינדקסים על שדות המסוננים תדיר (מחיר, סטטוס, קטגוריה).
• מטמון רכיבים מושבת או מאופס שלא לצורך.
• דחיסת Gzip לקבצים סטטיים לא מופעלת ברמת שרת האינטרנט.

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