Оптимизация MODX: кэш, БД, PHP-FPM, Nginx

Ускорение MODX: от диагностики до продакшена

MODX Revolution — гибкая CMS, но без правильной настройки кэширования и конфигурации сервера она легко упирается в TTFB 2–4 секунды даже на простых сайтах. TTFB 2–4 секунды — типичная картина для сайтов, где каждый запрос генерирует сотни SQL-запросов из-за парсинга тегов [[*]]/[[+]]. Отсутствие объектного кэша усугубляет ситуацию: файловый кэш не справляется с нагрузкой, дисковые операции stat() добавляют задержки. Мы, команда с 5-летним опытом и 100+ успешных проектов по ускорению MODX, поможем сократить время загрузки до 200 мс и пройти Core Web Vitals. Экономия на ресурсах хостинга после оптимизации обычно достигает 30-50%. Получите консультацию по оптимизации MODX — свяжитесь с нами для бесплатного аудита.

Как определить узкое место MODX?

Первый шаг — понять, что именно тормозит. MODX логирует медленные запросы если включить в core/config/config.inc.php:

define('MODX_CONFIG_KEY', 'config'); // в System Settings: // log_level = 4 (DEBUG) // log_target = FILE 

Более точный инструмент — xDebug + Blackfire или просто EXPLAIN в MySQL/MariaDB для запросов, которые MODX генерирует при рендере страницы. Типичные проблемы:

• modResource читает все поля включая content даже когда нужен только pagetitle
• getResources без limit делает SELECT * по всем дочерним ресурсам
• сниппеты без &cache=1 выполняются на каждый запрос

Опытные инженеры также проверяют настройки PHP-FPM и OPcache — часто проблема не в самом MODX, а в конфигурации окружения. Вложения в оптимизацию обычно окупаются уже через 2-3 месяца за счёт снижения нагрузки на сервер.

Кэширование на уровне MODX

Системный кэш хранится в core/cache/. Для production убедитесь, что директория имеет права 755 и не монтируется через tmpfs без достаточного размера.

Оптимальные настройки в System Settings:

Почему Redis лучше файлового кэша?

Для Redis-кэша устанавливается пакет Redis (modmore или аналог) и в core/config/config.inc.php добавляется:

$config_options = [ 'cache_path' => MODX_CORE_PATH . 'cache/', 'cache_default_handler' => 'xPDORedisCache', 'cache_xpdo_handler' => 'xPDORedisCache', 'redis_host' => '127.0.0.1', 'redis_port' => 6379, 'redis_db' => 0, ]; 

После переключения на Redis TTFB снижается на 30–50% на высоконагруженных сайтах, потому что отпадают дисковые операции на stat() файлов кэша. Сравнение:

Согласно данным Redis, in-memory хранение данных значительно ускоряет операции чтения. На практике это снижает затраты на серверные ресурсы на 30-40%.

Как оптимизировать сниппеты и pdoTools?

Некэшируемые вызовы [[!SnippetName]] — главный источник медлительности. Аудит через поиск по шаблонам и чанкам: команда grep -r '\[\[!' по папке элементов. Правила:

• Если сниппет не зависит от сессии/корзины/пользователя — делаем кэшируемым [[SnippetName? &cache="1" &cacheExpires="3600"]]
• getResources, pdoTools кэшируются через встроенный параметр &cache
• FormIt и Login — всегда некэшируемые, выносить в отдельные чанки

pdoTools вместо getResources — критично для сайтов с большими каталогами. pdoTools использует JOIN вместо множественных запросов. Пример вызова: [[pdoResources? &parents=15 &depth=2 &limit=20 &sortby=publishedon &sortdir=DESC &cache=1 &cacheExpires=1800]]

; /etc/php/8.1/fpm/conf.d/10-opcache.ini opcache.enable=1 opcache.memory_consumption=256 opcache.interned_strings_buffer=16 opcache.max_accelerated_files=10000 opcache.validate_timestamps=0 opcache.revalidate_freq=0 opcache.fast_shutdown=1 ; /etc/php/8.1/fpm/pool.d/modx.conf [modx] pm = dynamic pm.max_children = 20 pm.start_servers = 5 pm.min_spare_servers = 3 pm.max_spare_servers = 8 pm.max_requests = 500 request_terminate_timeout = 30s 

server { location ~* \.(js|css|png|jpg|webp|woff2|ico|svg)$ { expires 1y; add_header Cache-Control "public, immutable"; access_log off; } location ^~ /core/ { deny all; } gzip on; gzip_types text/plain text/css application/json application/javascript image/svg+xml; gzip_min_length 1024; gzip_comp_level 5; } 

ALTER TABLE modx_site_content ADD INDEX idx_parent_published (parent, published), ADD INDEX idx_context_published (context_key, published), ADD INDEX idx_publishedon (publishedon);