У меня есть сайт на Drupal, у которого, кажется, бесконечные проблемы с производительностью. Примерно 5 месяцев назад это было очень медленно. Я пригласил нескольких ребят, которые установили nginx для анонимных посетителей, адаптировали несколько запросов, чтобы они не запускались во время загрузки страницы, и помог мне найти несколько узких мест в коде.
Примерно в течение месяца сайт работал значительно быстрее, хотя и не «быстро» во всех смыслах. Между тем, я сейчас выкладываю Slicehost 400 долларов в месяц на хостинг сайта, который получает менее 5000 уникальных посетителей в день. Да, вы правильно прочитали. Перейти на Drupal.
Недавно сайт снова начал вылетать и снова стал медленным. Я не могу позволить себе нанимать людей, которые будут изучать мой код сверху вниз и вносить изменения, которые могут помочь, а могут и не помочь. И я не могу позволить себе использовать больше оборудования для решения этой проблемы.
Поэтому мне нужно самому разобраться, в чем проблема. Вопросы:
При сбое apache можно ли узнать, что вызвало его сбой? Должен же быть способ, правда? Если да, то как я могу это сделать? Есть ли программное обеспечение, которое я могу использовать, чтобы узнать, какой процесс стал причиной смерти моего сервера? (например, «Apache разбился, потому что кто-то посетил страницу X» или «Apache разбился, потому что вы импортировали слишком много элементов RSS из канала X»). Должен же быть способ узнать это, верно?
Какой хороший, удобный для новичков способ контролировать мою текущую производительность apache? Мои друзья-разработчики говорят мне «просто использовать Top, чувак», но Top показывает мне кучу чисел без какого-либо контекста. Я понятия не имею, что считается плохим числом или хорошим числом в Top, или какие процессы уместны, а какие нет. Есть ли какие-нибудь удобные для новичков инструменты для мониторинга серверов? В идеале у меня могла бы быть страница, которая давала бы мне цветной индикатор того, как работает apache, а затем показывала бы мне список процессов или страниц, которые сейчас отстойны. Таким образом, я мог знать, когда производительность плохая, а затем почему она становится такой плохой.
Почему память PHP имеет значение? У меня, по-видимому, 30 МБ памяти. Будет ли он работать быстрее, если я уменьшу это число?
Спасибо за любой совет. Я потратил год или около того, пытаясь увеличить свой доход от рекламы, чтобы нанять подрядчика, чтобы решить свои проблемы с производительностью. Я не хотел изучать всю эту сисадминскую вуду. Теперь я смирился с тем, что у меня может не быть выбора.
Вы действительно не предоставили много технической информации, но одна из самых простых и эффективных оптимизаций для Drupal (и других крупных PHP-приложений) - это использование APC, memcache или чего-то подобного.
Сама по себе APC действительно проста в настройке и очень эффективна. Вот мои настройки, которые, кажется, хорошо работают с Drupal (в файле php.ini):
extension=apc.so
apc.apc.stat = 0
apc.include_once_override = 1
apc.shm_size = 90
realpath_cache_size = 256K
realpath_cache_ttl = 180
Размер apc.shm_size является наиболее важным (максимальный МБ памяти сервера, используемый для файлового кеша .php). Обычно достаточно меньшего размера, но если этот кеш слишком мал, кеш будет почти бесполезен. Для большинства установок Drupal достаточно «50». Однако, если у вас есть несколько активных установок Drupal на одном сервере, которые НЕ являются мультисайтами, вам нужно установить это еще выше.
Если вы используете APC, вам нужно убедиться, что Zend Optimizer выключен, они не работают вместе. Только APC может увеличить скорость загрузки страницы на 30-40%. Если shm установлен слишком низко, скорость загрузки страницы не увеличивается.
Кроме того, мне интересно, действительно ли ребята, выполняющие начальную оптимизацию, знали Drupal и выполняли оптимизацию Drupal или просто общие серверные вещи. Вероятно, они у вас есть, но чтобы убедиться, что вы правильно настроили admin/settings/performance . То есть:
Caching mode: normal
Page compression: enabled
Optimize CSS files: enabled
Optimize JavaScript files: enabled
Все это очень эффективно.
Вы также, вероятно, используете представления, которые можно оптимизировать разными способами, но каждое представление также может иметь свой внутренний кеш и время жизни кеша. Если вы все равно кешируете свои страницы, а пользователи в основном анонимны, это не будет иметь большого эффекта.
Есть еще много способов оптимизации (и вам, вероятно, все же стоит изучить основы администрирования). Если журнал Drupal по адресу admin/reports/dblog не показывает ошибки, которые вы ищете, например, большинство фатальных ошибок, а «ошибки белого экрана» никогда не появляются.
locate error.log или locate php.log и использовать местоположение для просмотра последних сообщений журнала: sudo tail -n 100 /var/log/apache2/error.log <- пример пути с моего сервера. Когда найдете ошибку, погуглите.
Мониторинг apache "top" не очень удобен для пользователя, но он быстрый и работает практически на всех UNIX-машинах. Я обычно использую его, чтобы увидеть, не задыхаются ли apache2 или mysql.
Использование памяти. Если модуль «devel» сообщает, что загрузка страницы занимает около 30 МБ, это вполне нормально для модуля Drupal с большим количеством модулей. У меня есть некоторые установки, использующие больше (например, 40M), но многие также используют меньше. В моем текущем проекте на обычный просмотр страницы используется около 20 миллионов. Отключение ненужных модулей (или переключение на более эффективные) - один из способов уменьшить использование памяти.
Находясь в php.ini, также убедитесь, что memory_limit не слишком мало. Drupal действительно использует много памяти, и, например, все операции масштабирования изображений занимают очень много памяти. По умолчанию очень низкий. Теоретически установка может работать с 35M, но я бы установил как минимум двойной, чтобы все операции работали. Некоторые могут не согласиться, но у меня обычно больше 100 миллионов.
Если вы хотите провести настоящую хардкорную оптимизацию Drupal, есть много руководств, но этот сайт, вероятно, самый подробный: http://2bits.com/articles/drupal-performance-tuning-and-optimization-for-large-web-sites.html
И да, если вы платите столько в месяц за хостинг, у вас будет возможность нанять эксперта на час или около того :).
Drupal действительно хорошо масштабируется; поговорите с некоторыми веб-мастерами в их сообществе, и вы найдете людей, которые регулярно превышают эти цифры, поэтому я не могу сказать, что это неотъемлемая проблема Drupal. Однако на ум приходит пара вещей: включено ли кеширование? Вы уверены, что это не ваша база данных (MySQL / Postgres и т. Д.)? на каком оборудовании работает ваш сайт? Есть ли на нем другие сайты? Пожалуйста, предоставьте более подробную информацию; сейчас слишком много неизвестных переменных.