אופטימיזציית ביצועים מקצה לקצה עבור Magento 2

נתקלנו בתרחיש הזה: דף Magento 2 נטען תוך 8 שניות, כל בקשה מפעילה 300 שאילתות SQL ו-60 פעולות קבצים. לקוחות עוזבים, ההמרה יורדת. הפתרון אינו רק הפעלת מטמון—אלא בניית התשתית הנכונה: CDN → Varnish → Nginx → PHP-FPM 8.2 → MySQL 8.0, כל שכבה מכווננת לפלטפורמה. תוך 6–10 ימי עסקים אנו מורידים את TTFB ל-200–500 אלפיות השנייה. מאמר זה מכסה שיטות ותצורות מוכחות שאנו משתמשים בהן בפרויקטים מסחריים.

מקרה אחרון: חנות עם קטלוג של 50,000 פריטים (SKU) על אירוח משותף—דפים נטענו תוך 12 שניות, LCP 8 שניות. ביקורת חשפה שתוסף "Featured Products" ביצע 150 שאילתות SQL לכל דף. לאחר הגדרת Varnish ותיקון N+1, TTFB ירד ל-0.3 שניות, LCP ל-1.2 שניות. השוואה: Varnish עולה על המטמון המובנה של Magento פי 10 ב-TTFB, ו-Redis מפחית את זמן יצירת הבלוקים מ-50 אלפיות השנייה ל-1–2 אלפיות השנייה.

מדוע Magento 2 איטי

התקנה ברירת מחדל מבצעת 200–400 שאילתות SQL ו-50–100 פעולות קבצים לכל דף. סיבות אופייניות:

• בעיות N+1 — תוספים של afterLoad, אוספים ללא addAttributeToSelect, טעינת מוצרים אחד אחד.
• אין Varnish — תוכן דינמי נוצר מחדש בכל בקשה.
• MySQL לא מכוונן — ברירת מחדל של buffer 128 MB, redo log 48 MB.
• PHP ללא OPcache/JIT — קוד מפורש בכל בקשה.
• חיפוש MySQL — LIKE '%query%' לקטלוג של 10,000+ פריטים נותן תגובה של 2–5 שניות.

כיצד אנו מגדירים את התשתית

Varnish

Varnish הוא מטמון פרוקסי הפוך המאחסן תגובות HTTP מלאות. עבור משתמשים אנונימיים, שיעור הפגיעה מגיע ל-85–95%. תצורת VCL מתחשבת בארכיטקטורת Magento: אנו מדלגים על סשנים, סל קניות, תשלום, ומטמונים כל השאר.

Redis

Redis משמש למטמון (config, layout, block HTML, full page cache) ואחסון סשנים. זה מבטל קלט/פלט דיסק ומפחית את עומס MySQL. ההתקנה כוללת מופעים נפרדים לסוגי נתונים שונים.

PHP 8.2 + OPcache + JIT

שדרוג ל-PHP 8.2 מניב שיפור של 15–25% בפעולות תלויות CPU. OPcache עם זיכרון של 512 MB ו-JIT במצב tracing מאיץ את ביצוע הסקריפטים בעד 20%.

; /etc/php/8.2/fpm/conf.d/opcache.ini
opcache.enable=1
opcache.memory_consumption=512
opcache.interned_strings_buffer=64
opcache.max_accelerated_files=60000
opcache.validate_timestamps=0
opcache.revalidate_freq=0
opcache.fast_shutdown=1
opcache.enable_cli=1
; JIT
opcache.jit=tracing
opcache.jit_buffer_size=256M

[magento]
user = www-data
group = www-data
listen = /run/php/php8.2-fpm-magento.sock
listen.backlog = 65535
pm = dynamic
pm.max_children = 40
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 2000
php_admin_value[memory_limit] = 768M
php_admin_value[max_execution_time] = 600
php_admin_value[opcache.file_cache] = /tmp/opcache

MySQL

InnoDB buffer pool — 70% מזיכרון השרת. Redo log 1 GB, שיטת flush O_DIRECT, מטמון שאילתות מושבת (mutex הורג מקביליות). להלן תצורה אופיינית לשרת עם 16 GB RAM.

[mysqld]
innodb_buffer_pool_size = 8G
innodb_buffer_pool_instances = 8
innodb_log_file_size = 1G
innodb_log_buffer_size = 64M
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
innodb_read_io_threads = 16
innodb_write_io_threads = 16
innodb_thread_concurrency = 0
query_cache_type = 0
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1

Elasticsearch

אנו מחליפים את חיפוש MySQL ב-Elasticsearch — חיפוש טקסט מלא עם רלוונטיות, השלמה אוטומטית, סינון לפי פנים. לאחר אינדוקס מחדש, דף חיפוש עם 50,000 מוצרים מגיב תוך 50–150 אלפיות השנייה במקום 2–5 שניות.

מה לעשות בנוגע לשאילתות N+1