Хочу поделится с вами моим опытом работы с модулем производительности его плюсами и минусами.
Преамбула.Я занимаюсь развитием одного крупного проекта который сейчас набирает обороты. Уже на портале зарегистрировано более 18 000 пользователей, в день на портале получаем около 3 000 хостов и более 25 000 хитов.
Увы на хостинге
(хостера называть не буду) начались проблемы. Проект начал загружать нереально базу, что приводило к зависанию базы.
С хостером ругались долго пытаясь понять кто виноват, пытались найти проблему в портале но даже Автоматическое кеширование увы не помогало.
Решили перейти на выделенный сервер. НО со стандартными настройками увы проблемы продолжились.
Отмечу, что текущий
размер базы данных ~1.6 Гб.
Чтобы не потерять популярность проекта пришлось в срочном порядке просить помощи от разработчиков 1С-Битрикс. И они дали для анализа производительности этот модуль.
Модуль производительности.Первое знакомство с модулем. Да ранее мы его видели но у нас не было реальной надобности в его использовании.
Краткость сестра таланта (С).Минимум настроек. Не надо ломать голову как настроить модуль.
Пара галочек и режим включения мониторинга.
База данныхНачал анализ базы с настроек базы данных.
![](https://site-cloud-files.bitrix.info/blog/6c4/2.jpg)
Как вы видите параметры базы приводят к большим потеря в производительности. И это при том, что на сервере софт собран в оптимальной конфигурации
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 |
И вот, что у меня получилось:
![](https://site-cloud-files.bitrix.info/blog/b6c/3.jpg)
Как видите прирост производительности базы на лицо.
Мне понравилась работа по оптимизации базы. Я мог редактировать настройки и тут-же видеть результаты.
Хиты и Хиты с группировкойЗакончив с оптимизацией настроек базы я перешел к проверке нагрузке уже на уровне кода.
Тут мне удалось найти какие именно страницы на портале отнимают больше всего памяти и какие открывались дольше всего... где кеширование обязательно, а где можно выключить.
ЗапросыАналогично анализам хитов но уже на уровне SQL запросов.
![](https://site-cloud-files.bitrix.info/blog/939/5.jpg)
(Сами запросы я выключил иначе скрин был бы больше)
Как видите все проблемы в выборке данных все в публичных компонентах.
На всех этих компонентах мы оптимизировали выборку данных указав более точные параметры выборки. Включили кеширование информации. В результате снизили нагрузку в этих компонентах.
Минус этого раздела модуля - не показывает на какой странице расположен тот или иной компонент. Пришлось искать по ID хита.
Ошибки PHPА вот этот раздел будет полезен думаю всем разработчикам. Очень удобный функционал отлова ошибок даже в файлах которые автоматически пересылают вас в другое место или отрабатывают в фоновом режиме (как например правила обработки почты или агенты).
Нашел несколько недочетов в скриптах которые быстренько поправили. Ошибки не критические но раз о них известно то почему бы не исправить
ТаблицыВот тут я ожидал увидеть гораздо больший функционал!
Я тут увидел только список таблиц и выполнить перевод таблиц в InnoDB.
А где информация по таблицам? Где функции по проверке таблицы или ее восстановлению?
Да я знаю, что это все есть в Инструментах
(Инструменты -> Проверка БД) но все-же хотелось бы видеть больший функционал в этом разделе.
Общая оценка.
В принципе как инструмент оптимизации и отладки проекта это отличный инструмент.
Но вот как инструмент работы с базой и оптимизации таблиц тут слабо развито. Хотелось бы увидеть больше возможностей по работе с таблицами и базой данных.
P.S. этот анонс мое ИМХО...
P.S.S. если интересны настройки Nginx, Apache2 и PHP 5 пишите