Хочу поделится с вами моим опытом работы с модулем производительности его плюсами и минусами.
Преамбула.
Я занимаюсь развитием одного крупного проекта который сейчас набирает обороты. Уже на портале зарегистрировано более 18 000 пользователей, в день на портале получаем около 3 000 хостов и более 25 000 хитов.
Увы на хостинге (хостера называть не буду) начались проблемы. Проект начал загружать нереально базу, что приводило к зависанию базы.
С хостером ругались долго пытаясь понять кто виноват, пытались найти проблему в портале но даже Автоматическое кеширование увы не помогало.
Решили перейти на выделенный сервер. НО со стандартными настройками увы проблемы продолжились.
Отмечу, что текущий размер базы данных ~1.6 Гб.
Чтобы не потерять популярность проекта пришлось в срочном порядке просить помощи от разработчиков 1С-Битрикс. И они дали для анализа производительности этот модуль.
Модуль производительности.
Первое знакомство с модулем. Да ранее мы его видели но у нас не было реальной надобности в его использовании.
Краткость сестра таланта (С).
Минимум настроек. Не надо ломать голову как настроить модуль.
Пара галочек и режим включения мониторинга.
База данных
Начал анализ базы с настроек базы данных.
Как вы видите параметры базы приводят к большим потеря в производительности. И это при том, что на сервере софт собран в оптимальной конфигурации
Nginx + Apache
PHP + ZendOptimizer + eAccelerator
Но главное упущение мое была не оптимальная конфигурация базы. Используя мощный сервер я совсем забыл про настройку базы.
Я начал подбирать оптимальную конфигурацию для базы.
Многих настроек у меня не было или значения стаяли маленькие.
Меняя параметры настроек базы я смотрел результаты работы в модуле.
Позволило уменьшить время затрачиваемое на оптимизацию базы.
Листинг получившейся конфигурации:
И вот, что у меня получилось:
Как видите прирост производительности базы на лицо.
Мне понравилась работа по оптимизации базы. Я мог редактировать настройки и тут-же видеть результаты.
Хиты и Хиты с группировкой
Закончив с оптимизацией настроек базы я перешел к проверке нагрузке уже на уровне кода.
Тут мне удалось найти какие именно страницы на портале отнимают больше всего памяти и какие открывались дольше всего... где кеширование обязательно, а где можно выключить.
Запросы
Аналогично анализам хитов но уже на уровне SQL запросов.
(Сами запросы я выключил иначе скрин был бы больше)
Как видите все проблемы в выборке данных все в публичных компонентах.
На всех этих компонентах мы оптимизировали выборку данных указав более точные параметры выборки. Включили кеширование информации. В результате снизили нагрузку в этих компонентах.
Минус этого раздела модуля - не показывает на какой странице расположен тот или иной компонент. Пришлось искать по ID хита.
Ошибки PHP
А вот этот раздел будет полезен думаю всем разработчикам. Очень удобный функционал отлова ошибок даже в файлах которые автоматически пересылают вас в другое место или отрабатывают в фоновом режиме (как например правила обработки почты или агенты).
Нашел несколько недочетов в скриптах которые быстренько поправили. Ошибки не критические но раз о них известно то почему бы не исправить
Таблицы
Вот тут я ожидал увидеть гораздо больший функционал!
Я тут увидел только список таблиц и выполнить перевод таблиц в InnoDB.
А где информация по таблицам? Где функции по проверке таблицы или ее восстановлению?
Да я знаю, что это все есть в Инструментах (Инструменты -> Проверка БД) но все-же хотелось бы видеть больший функционал в этом разделе.
Общая оценка.
В принципе как инструмент оптимизации и отладки проекта это отличный инструмент.
Но вот как инструмент работы с базой и оптимизации таблиц тут слабо развито. Хотелось бы увидеть больше возможностей по работе с таблицами и базой данных.
P.S. этот анонс мое ИМХО...
P.S.S. если интересны настройки Nginx, Apache2 и PHP 5 пишите
Преамбула.
Я занимаюсь развитием одного крупного проекта который сейчас набирает обороты. Уже на портале зарегистрировано более 18 000 пользователей, в день на портале получаем около 3 000 хостов и более 25 000 хитов.
Увы на хостинге (хостера называть не буду) начались проблемы. Проект начал загружать нереально базу, что приводило к зависанию базы.
С хостером ругались долго пытаясь понять кто виноват, пытались найти проблему в портале но даже Автоматическое кеширование увы не помогало.
Решили перейти на выделенный сервер. НО со стандартными настройками увы проблемы продолжились.
Отмечу, что текущий размер базы данных ~1.6 Гб.
Чтобы не потерять популярность проекта пришлось в срочном порядке просить помощи от разработчиков 1С-Битрикс. И они дали для анализа производительности этот модуль.
Модуль производительности.
Первое знакомство с модулем. Да ранее мы его видели но у нас не было реальной надобности в его использовании.
Краткость сестра таланта (С).
Минимум настроек. Не надо ломать голову как настроить модуль.
Пара галочек и режим включения мониторинга.
База данных
Начал анализ базы с настроек базы данных.
Как вы видите параметры базы приводят к большим потеря в производительности. И это при том, что на сервере софт собран в оптимальной конфигурации
Nginx + Apache
PHP + ZendOptimizer + eAccelerator
Но главное упущение мое была не оптимальная конфигурация базы. Используя мощный сервер я совсем забыл про настройку базы.
Я начал подбирать оптимальную конфигурацию для базы.
Многих настроек у меня не было или значения стаяли маленькие.
Меняя параметры настроек базы я смотрел результаты работы в модуле.
Позволило уменьшить время затрачиваемое на оптимизацию базы.
Листинг получившейся конфигурации:
# The following options will be passed to all MySQL clients [client] #password = your_password port = 3306 socket = /var/lib/mysql/mysql.sock # Here follows entries for some specific programs # The MySQL server [mysqld] port = 3306 socket = /var/lib/mysql/mysql.sock skip-locking key_buffer = 256M max_allowed_packet = 16M max_connections = 2000 max_heap_table_size=32M myisam_sort_buffer_size = 256M #net_buffer_length = 128M read_buffer_size = 256M read_rnd_buffer_size = 256M sort_buffer_size = 128M table_cache = 7168 thread_cache_size = 16K thread_concurrency = 16 thread_stack = 128K tmp_table_size=1408M query_cache_limit = 16M query_cache_size = 1024M #query_cache_startup_type = 1 query_cache_type = 1 #skip-networking skip-federated log-bin=mysql-bin server-id = 1 [safe_mysqld] log-error=/var/lib/mysql/mysqld.log [mysqldump] quick quote-names max_allowed_packet = 16M [mysql] #no-auto-rehash [isamchk] key_buffer = 16M sort_buffer_size = 8M read_buffer = 10M write_buffer = 10M [myisamchk] key_buffer = 8M sort_buffer_size = 8M read_buffer = 2M write_buffer = 2M [mysqlhotcopy] interactive-timeout |
И вот, что у меня получилось:
Как видите прирост производительности базы на лицо.
Мне понравилась работа по оптимизации базы. Я мог редактировать настройки и тут-же видеть результаты.
Хиты и Хиты с группировкой
Закончив с оптимизацией настроек базы я перешел к проверке нагрузке уже на уровне кода.
Тут мне удалось найти какие именно страницы на портале отнимают больше всего памяти и какие открывались дольше всего... где кеширование обязательно, а где можно выключить.
Запросы
Аналогично анализам хитов но уже на уровне SQL запросов.
(Сами запросы я выключил иначе скрин был бы больше)
Как видите все проблемы в выборке данных все в публичных компонентах.
На всех этих компонентах мы оптимизировали выборку данных указав более точные параметры выборки. Включили кеширование информации. В результате снизили нагрузку в этих компонентах.
Минус этого раздела модуля - не показывает на какой странице расположен тот или иной компонент. Пришлось искать по ID хита.
Ошибки PHP
А вот этот раздел будет полезен думаю всем разработчикам. Очень удобный функционал отлова ошибок даже в файлах которые автоматически пересылают вас в другое место или отрабатывают в фоновом режиме (как например правила обработки почты или агенты).
Нашел несколько недочетов в скриптах которые быстренько поправили. Ошибки не критические но раз о них известно то почему бы не исправить
Таблицы
Вот тут я ожидал увидеть гораздо больший функционал!
Я тут увидел только список таблиц и выполнить перевод таблиц в InnoDB.
А где информация по таблицам? Где функции по проверке таблицы или ее восстановлению?
Да я знаю, что это все есть в Инструментах (Инструменты -> Проверка БД) но все-же хотелось бы видеть больший функционал в этом разделе.
Общая оценка.
В принципе как инструмент оптимизации и отладки проекта это отличный инструмент.
Но вот как инструмент работы с базой и оптимизации таблиц тут слабо развито. Хотелось бы увидеть больше возможностей по работе с таблицами и базой данных.
P.S. этот анонс мое ИМХО...
P.S.S. если интересны настройки Nginx, Apache2 и PHP 5 пишите