css — Сокращение на стороне сервера приводит к узким местам PHP-процессов на сайте с высоким трафиком. Какие у меня варианты?
В настоящее время передо мной стоит задача найти решение для серьезного узкого места в PHP, которое, очевидно, вызвано минимизацией CSS и JS на стороне сервера, когда наши сайты находятся под высокой нагрузкой.
Я унаследовал веб-приложение, работающее на WordPress и использующее сложное сочетание Doctrine, Memcached и W3 Total Cache для минимизации и кэширования. При большой нагрузке наше приложение начинает быстро замедляться. Пока что мы сузили часть проблемы до процесса минимизации на стороне сервера. Предварительный анализ показал, что число процессов PHP начинает накапливаться под нагрузкой, а при достижении предела в 500 процессов начинает все замедляться. Нечто, что также упоминается автором библиотеки minify.
Pre-минификация
Наиболее логичным решением было бы предварительно минимизировать любой из файлов перед выходом в эфир. К сожалению, наш рабочий процесс требует, чтобы лица, не являющиеся разработчиками, могли редактировать указанные файлы на наших производственных серверах (т.е. после запуска веб-приложения). Следовательно, я считать об этой предварительной обработке не может быть и речи, так как она ограничивает возможность редактирования минимизированных файлов.
Обслуживание незавершенных файлов
75% наших пользователей получают доступ к нашему веб-приложению со своих мобильных устройств, особенно со смартфонов. Unminified JS и CSS составляют 432 КБ и уменьшаются на 60-80% по размеру при минимизации. Следовательно, обслуживание мобильных файлов при решении проблемы с производительностью и редактируемостью для мобильных пользователей исключено.
Я понимаю, что это такая же техническая проблема, как и проблема рабочего процесса, и я полагаю, что мы открыты для работы над обоими, до тех пор, пока у нас не будет лучшей общей производительности.
-
Есть ли разумный компромисс, который решает узкое место PHP
проблема, позволяет не-разработчикам вносить изменения в живой CSS / JS и
по-прежнему обслуживает файлы разумного размера для клиентов. -
Если не существует такого универсального решения, что я могу сделать, чтобы
лучше наш рабочий процесс и / или поведение на стороне сервера?
РЕДАКТИРОВАТЬ: Поскольку были некоторые вопросы / комментарии относительно конфигурации сервера, наши серверы работают под управлением Debian и оснащены 32 ГБ оперативной памяти и 24 ядерными процессорами.
Решение
Вы можете запустить сервис компиляции css / javascript, например: Gulp или же Grunt с помощью Node.js это минимизирует все ваши активы js и css при изменении.
Эта служба может работать в производственном режиме, но это не рекомендуется без некоторой архитектурной настройки (наличие нескольких версионных скомпилированных файлов и автоматическая проверка их через gulp или другое расширение).
Я подчеркиваю, что исправление функций в производстве и непосредственно
редактировать его настоятельно не рекомендуется, так как он может представлять живые проблемы
ваши посетители снижают ваш авторитет.
С помощью Gulp/Grunt потребует, чтобы вы изменили, как вы пишете свои файлы CSS / Javascript.
Другие решения
Я бы решил это с помощью двух решений — во-первых, удалив все операции WP-CRON, которые выполняются каждый раз, когда пользователь запускает приложение, и переместил их в реальный CRON на сервере. Во-вторых, я бы использовал балансировку нагрузки, чтобы один сервер не брал на себя нагрузку. Это ваша реальная проблема, и даже если вы исправите свои проблемы с кодом, вы все равно столкнетесь с проблемой загрузки.
Я не верю, что вам нужно вообще менять рабочий процесс или идти по пути серьезных изменений в существующей системе.
Задачи WP-CRON, которые запускаются при каждой загрузке страницы, вызывают значительную нагрузку и замедление. Вы можете перенести это с пользователей, посещающих этот процесс, на ваш сервер, просто запустив его на уровне сервера. Это уменьшает нагрузку. Скорее всего, эти процессы, скорее всего, замедляют работу сайта.
Смотрите это руководство:
http://www.inmotionhosting.com/support/website/wordpress/disabling-the-wp-cronphp-in-wordpress
Далее — балансировка нагрузки. Наличие одного сервера, обеспечивающего всех ваших пользователей, когда у вас много трафика, — ужасная идея. Вам нужно разделить загрузку веб-серверов.
Я не уверен, где и как вы находитесь, но я бы переместил вещи в AWS. Настройте мой сайт WordPress для балансировки нагрузки @ AWS: http://www.mornin.org/blog/scalable-wordpress-amazon-web-services/
Это будет включать в себя:
- Балансировщик нагрузки
- EC2 Экземпляры с PHP / Apache
- RDS для хранения вашей базы данных для всех экземпляров EC2
- S3 Хранилище для сайтов СМИ
Для пользовательских сессий я советую вам просто установить липкость на балансировщике нагрузки, чтобы пользователи постоянно обслуживались на одном и том же узле, на котором они прибыли.
Вы можете получить подробное руководство о том, как это сделать здесь:
http://www.mornin.org/blog/scalable-wordpress-amazon-web-services/
Или при сбое сервера другой подход:
https://serverfault.com/questions/571658/load-balancing-wordpress-on-amazon-web-services-managing-changes
Здесь предполагается, что, если у вас высокий трафик, вы получаете доход от этого большого трафика, поэтому в любое время, когда ваша служба реагирует медленно, это отвлечет пользователей или, возможно, отговорит их от возврата. Смена программного обеспечения может помочь, но вы лечите симптом, а не болезнь. Болезнь в том, что ваш сервер находится под большой нагрузкой. Это не редкость для WordPress и большого трафика, поэтому вам нужно распределять нагрузку, а не пытаться оптимизировать микро. Разница в том, что оптимизация будет небольшим выигрышем, в то время как балансировка нагрузки и распределение нагрузки фактически решают проблему.
Наконец — рассмотрите возможность использования CDN для обслуживания всех ваших медиа. Это ускоряет загрузку мультимедиа и снимает нагрузку с вашей системы, уменьшая количество запросов к серверу и его вывод клиентам. Он также обеспечивает более быструю последовательную загрузку страниц для людей, откуда бы они ни заходили, предоставляя медиафайлы из ближайших к ним узлов. В AWS это называется CloudFront. WordPress также предлагает эту услугу бесплатно через Jetpack (я полагаю), но она не обрабатывает все средства массовой информации, насколько я понимаю.
Мне нравится идея использования GulpJS. Одна вещь, которую вы могли бы рассмотреть, это иметь wp-cron или просто системный cron, который запускается каждые 5 минут или около того, а затем запускает задачу gulp для минимизации и объединения ваших файлов css и js.
Другой вариант, который не требует планирования, но основан на наблюдении за изменениями файловой системы и последующем запуске сборки Gulp, — это использование incron (inotify cron). Проверьте справочная страница incron. Incron хорош тем, что запускает действия, основанные на событиях файловой системы, таких как изменения файлов. Вы можете использовать это для запуска сборки gulp, когда любой файл CSS изменяется в файловой системе.
Одно из предостережений заключается в том, что это решение для Linux, поэтому, если вы используете Windows, вам, возможно, придется поискать что-то подобное.
Редактировать:
Документация Incron