Недавно поступила просьба о помощи в настройке выделенного сервера для работы интернет-магазина на 1С-Битрикс. Причина обращения - медленная работа сайта.
Посмотрели на сайт - действительно, некоторые страницы грузятся больше минуты!!!. Первое что пришло в голову глядя на сайт - это неоптимальная работа компонент, разработанных другим разработчиком. Но не на столько же..
Исходные данные: Сервер на Xeon - 2Гб памяти, RAID. ОС - FreeBSD. БУС - Бизнес.
Чтож, попробуем хоть как-то исправить ситуацию...
Сразу оговорюсь, что данная статья не инструкция по работе с модулем, просто реальный случай из жизни применения модуля. Может кому будет полезной.
[spoiler]
После аудита выявлены следующие основные проблемы:
1. На сервер необходимо установить PHP-акселлератор
2. На старнице /price/ большие проблемы у компонента «nvisions:menu.sections» - генерируется запрос к базе который обрабатывается почти минуту – это основная причина долгой загрузки страницы, а также большая нагрузка на сервер.
3. Медленно работает БД (687 запросов на запись в сек – это очень мало) проблема может быть в конфигурации сервера. Необходимо перевести таблицы в InnoDB и сконфигурировать InnoDB
4. Файловая система не очень быстрая, это могут быть аппаратные особенности сервера (например RAID), но в принципе с такой скоростью сайт должен работать неплохо
5. Проблема в шаблоне сайта (присутствует не существующие ссылки(а)) необходимо ее убрать – это занимает много ресурсов.
6. Необходимо настроить двухуровневую архитектуру на сервере (статическое содержимое отдавать через nginx), это значительно уменьшит нагрузку на сервер Apache, стабилизирует расход памяти на нагрузках, следовательно ускорит работу и повысит надежность проекта в целом.
Проанализируем информацию модуля производительности 1С-Битрикс:
Из рисунка явно видны проблемы с сервером БД, скорее всего не оптимальность настроек, т.к. сервер выделенный.
Также подозрительно низкое число файловых операций.
Явные проблемы с кодом или компонентами на странице /price/index.php
Подозрительно большое время генерации /bitrix/urlrewrite.php – смотрим дальше:
Ага вот он - источник проблем: в шаблоне присутствует ссылка на несуществующую картинку, это генерирует 404 ошибку, и заставляет Apache обрабатывать эту ошибку и генерировать полноценную страницу.
Эта же проблема влияет на все страницы сайта, связанные с проблемным шаблоном:
А вот и проблемные компоненты на странице:
У компонента меню отключено кэширование.
Итог страницы:
Ну вот краткий анализ. Как удобно модуль производительности подсказывает "где находяться проблемы". Приступим к устранению проблем:
Добавили картинку на которую была ссылка, именно добавили картинку, а не удалили ссылки, т.к. ссылок было много, в том числе и в компонентах сторонних разработчиков. Также на этой страницы отключили проблемную компоненту стороннего разработчика (nsvision:menu.sections), т.к. назначение ее не понятно. (после отключения, внешне ничего не изменилось)
Результат:
Urlrewrite.php теперь невызывается на каждом хите
Как видим скорость работы увеличилась в 2 раза(!).
Едем дальше:
Устанавливаем eaccelerator. Здесь не описываю как устанавливается акселлератор, т.к. эту информацию, при необходимости, всегда можно найти на просторах Интернета.
Результат после установки eAccelerator: Еще двух кратный прирост производительности.
Едем дальше: Оптимизируем Базу данных (переводим на InnoDB и оптимизируем настройки)
Как видно из теста модуля производительности скорость работы БД значительно увеличилась
В целом общая производительность после оптимизации БД осталась не изменой, возможно из-за медленной работы файловой системы.
UPDATE:
Рекомендации Модуля Производительности.
Прислушаясь рекомендациям модуля отключаем параметр "open_basedir", т.к. сервер выделен только под наш проект, подразумеваем, что безопасность в целом не нарушиться.
Результат:
Результ как говориться, НАЛИЦО
Осталось переписать "кривоватые" компонеты и проект будет летать.
Также установили и настроили nginx как прокси-сервер для Apache. Картинки не привожу, т.к. цифры практически не изменились. Но по субективной оценки страницы стали грузится еще в пару раз быстрее.
Шаблон все равно генерируется достаточно долго (время генерации практически как у ядра системы) – видимо, не оптимально написан код предыдущим разработчиком. Разбирать чужой код, нет ни времени, ни бюджета, ни желания. Проще, быстрее и дешевле написать свой код с нуля.
Вообщем: Модуль Производительности - очень полезный и удобный инструмент отладки работы проекта и сервера. За что спасибо его разработчикам.
P.S. Лично имею небольшой опыт по работе с Linux. С FreeBSD тесно познакомился в-первые. Удивило, то что после установки некоторого ПО конфг.файлы вообще пустые (например MySQL). Порадовала легкость установки ПО из "портов".
Посмотрели на сайт - действительно, некоторые страницы грузятся больше минуты!!!. Первое что пришло в голову глядя на сайт - это неоптимальная работа компонент, разработанных другим разработчиком. Но не на столько же..
Исходные данные: Сервер на Xeon - 2Гб памяти, RAID. ОС - FreeBSD. БУС - Бизнес.
Чтож, попробуем хоть как-то исправить ситуацию...
Сразу оговорюсь, что данная статья не инструкция по работе с модулем, просто реальный случай из жизни применения модуля. Может кому будет полезной.
[spoiler]
После аудита выявлены следующие основные проблемы:
1. На сервер необходимо установить PHP-акселлератор
2. На старнице /price/ большие проблемы у компонента «nvisions:menu.sections» - генерируется запрос к базе который обрабатывается почти минуту – это основная причина долгой загрузки страницы, а также большая нагрузка на сервер.
3. Медленно работает БД (687 запросов на запись в сек – это очень мало) проблема может быть в конфигурации сервера. Необходимо перевести таблицы в InnoDB и сконфигурировать InnoDB
4. Файловая система не очень быстрая, это могут быть аппаратные особенности сервера (например RAID), но в принципе с такой скоростью сайт должен работать неплохо
5. Проблема в шаблоне сайта (присутствует не существующие ссылки(а)) необходимо ее убрать – это занимает много ресурсов.
6. Необходимо настроить двухуровневую архитектуру на сервере (статическое содержимое отдавать через nginx), это значительно уменьшит нагрузку на сервер Apache, стабилизирует расход памяти на нагрузках, следовательно ускорит работу и повысит надежность проекта в целом.
Проанализируем информацию модуля производительности 1С-Битрикс:
Из рисунка явно видны проблемы с сервером БД, скорее всего не оптимальность настроек, т.к. сервер выделенный.
Также подозрительно низкое число файловых операций.
Явные проблемы с кодом или компонентами на странице /price/index.php
Подозрительно большое время генерации /bitrix/urlrewrite.php – смотрим дальше:
Ага вот он - источник проблем: в шаблоне присутствует ссылка на несуществующую картинку, это генерирует 404 ошибку, и заставляет Apache обрабатывать эту ошибку и генерировать полноценную страницу.
Эта же проблема влияет на все страницы сайта, связанные с проблемным шаблоном:
А вот и проблемные компоненты на странице:
У компонента меню отключено кэширование.
Итог страницы:
Ну вот краткий анализ. Как удобно модуль производительности подсказывает "где находяться проблемы". Приступим к устранению проблем:
Добавили картинку на которую была ссылка, именно добавили картинку, а не удалили ссылки, т.к. ссылок было много, в том числе и в компонентах сторонних разработчиков. Также на этой страницы отключили проблемную компоненту стороннего разработчика (nsvision:menu.sections), т.к. назначение ее не понятно. (после отключения, внешне ничего не изменилось)
Результат:
Urlrewrite.php теперь невызывается на каждом хите
Как видим скорость работы увеличилась в 2 раза(!).
Едем дальше:
Устанавливаем eaccelerator. Здесь не описываю как устанавливается акселлератор, т.к. эту информацию, при необходимости, всегда можно найти на просторах Интернета.
Результат после установки eAccelerator: Еще двух кратный прирост производительности.
Едем дальше: Оптимизируем Базу данных (переводим на InnoDB и оптимизируем настройки)
Как видно из теста модуля производительности скорость работы БД значительно увеличилась
В целом общая производительность после оптимизации БД осталась не изменой, возможно из-за медленной работы файловой системы.
UPDATE:
Рекомендации Модуля Производительности.
Прислушаясь рекомендациям модуля отключаем параметр "open_basedir", т.к. сервер выделен только под наш проект, подразумеваем, что безопасность в целом не нарушиться.
Результат:
Результ как говориться, НАЛИЦО
Осталось переписать "кривоватые" компонеты и проект будет летать.
Также установили и настроили nginx как прокси-сервер для Apache. Картинки не привожу, т.к. цифры практически не изменились. Но по субективной оценки страницы стали грузится еще в пару раз быстрее.
Шаблон все равно генерируется достаточно долго (время генерации практически как у ядра системы) – видимо, не оптимально написан код предыдущим разработчиком. Разбирать чужой код, нет ни времени, ни бюджета, ни желания. Проще, быстрее и дешевле написать свой код с нуля.
Вообщем: Модуль Производительности - очень полезный и удобный инструмент отладки работы проекта и сервера. За что спасибо его разработчикам.
P.S. Лично имею небольшой опыт по работе с Linux. С FreeBSD тесно познакомился в-первые. Удивило, то что после установки некоторого ПО конфг.файлы вообще пустые (например MySQL). Порадовала легкость установки ПО из "портов".