Настройка базы данных MySQL
Оптимизация работы с базой данных для MySQL-версии продукта является одной из важнейших стратегий в оптимизации системы в целом, так как продукт активно работает с базой данных.
Простой формат данных MyISAM хранит каждую таблицу с данными или индекс в отдельном файле. В целом, на небольших по нагрузке сайтах данный формат является наиболее быстрым, хотя и не обеспечивает полной целостности и надежного хранения данных за счет отсутствия транзакций.
Основным недостатком MyISAM с точки зрения производительности является блокировка на уровне таблицы при выполнении тех или иных операций. В результате, при большой нагрузке MySQL именно MyISAM таблицы становятся основным узким местом в системе, мешая увеличивать утилизацию машины и число обрабатываемых запросов. Это также приводит к увеличению времени работы страницы за счет ожидания используемых таблиц на уровне MySQL.
Рекомендуется переводить все таблицы проекта в формат данных InnoDB. Формат InnoDB, начиная с версии MySQL 4.0, входит в стандартную поставку продукта и обеспечивает надежное хранение данных, транзакционность и блокирование данных на уровне строки.
Два важных момента, которые дают основание предпочесть таблицы InnoDB перед MyISAM:
- Надежность. В MyISAM высока вероятность сбоя таблиц, особенно больших, особенно при высокой посещаемости, особенно часто изменяемых. Есть риск потерять несколько (десятков, сотен) записей и целостность данных. В InnoDB чинить отдельные таблицы не придется. Если упадет, так все сразу. Но на практике это — исключительное явление, практически не встречаемое. Благодаря транзакционности, риск нарушения целостности минимальный. Недостатки InnoDB: нужно внимательно следить за свободным местом на диске; накапливающаяся фрагментация данных (лечится периодическим переводом таблиц из InnoDB в MyISAM и обратно).
- Скорость. На невысокой посещаемости MyISAM ведет себя быстрее, как на модификацию, так и на чтение. Однако, при росте посещаемости достаточно быстро сказывается отсутствие транзакций и блокировка на уровне таблиц. При некоторой величине посещаемости проект просто реально умирает. В InnoDB запись будет медленнее (транзакции же), зато при высокой посещаемости блокировки наступят намного, намного позже, чем для MyISAM.
Поменять тип таблиц на InnoDB можно следующим образом:
-
В административном меню Настройки системы > Инструменты > SQL запрос выполнить команду:
SHOW TABLES
ALTER TABLE , type=InnoDB
define("MYSQL_TABLE_TYPE", "InnoDB");
Переход на тип таблиц InnoDB позволяет избежать возникновения узкого участка в производительности при работе с базой данных и в полном объеме использовать системные ресурсы.
Внимание! Обязательно конфигурируйте InnoDB. Для лучшей производительности базы данных при работе с InnoDB рекомендуется настроить my.cnf для MySQL в разделе параметров для InnoDB innodb_* .
Наибольшее внимание следует обратить на следующие параметры и примеры:
set-variable = innodb_buffer_pool_size=250M set-variable = innodb_additional_mem_pool_size=50M set-variable = innodb_file_io_threads=8 set-variable = innodb_lock_wait_timeout=50 set-variable = innodb_log_buffer_size=8M set-variable = innodb_flush_log_at_trx_commit=0
Рекомендуется: Для сокращения времени ответа сервера можно использовать отложенные транзакции и, в частности, устанавливать переменную set-variable = innodb_flush_log_at_trx_commit=0 .
Если MyISAM уже не используется активно, можно высвободить память в пользу InnoDB параметров.
Желательно, чтобы кэш данных вмещал в себя основной объем данных, используемых продуктом в работе. Обычно для работы базы данных выделяется порядка 60-80% свободной памяти в системе.
Рекомендуется: Производить многопотоковую (multithreading) сборку MySQL для улучшения производительности системы и возможностей по параллельной обработке запросов.
Пример рекомендуемых настроек для сервера с 2 Гб оперативной памяти, работающего с операционной системой FreeBSD/Linux:
set-variable = table_cache=4096
В составе продукта около 250 таблиц, поэтому рекомендуется увеличивать кэш для заголовков таблиц.
set-variable = key_buffer_size=16M set-variable = sort_buffer=8M set-variable = read_buffer_size=16M
Эти параметры используются только для MyISAM. Если в базе нет таблиц MyISAM, то лучше установить минимальные значения.
set-variable = query_cache_size=64M set-variable = query_cache_type=1
Кэширование результатов запросов. Обычно бывает достаточно 32 Мб (смотреть на статус Qcache_lowmem_prunes). Максимальный размер результата по умолчанию — 1 Мб, его можно регулировать.
set-variable = innodb_buffer_pool_size=780M
Основной буфер — чем больше, тем лучше.
set-variable = innodb_additional_mem_pool_size=20M
Вспомогательный буфер на внутренние структуры, большой делать не имеет смысла.
set-variable = innodb_log_file_size=100M set-variable = innodb_log_buffer_size=16M
Чем больше размер лог-файла, тем реже надо будет записывать в основной файл данных. Суммарный размер лог-файла может быть сопоставим с величиной innodb_buffer_pool_size (по умолчанию ведется два лога).
set-variable = innodb_flush_log_at_trx_commit=0
Отложенная фиксация транзакций, раз в секунду
set-variable = tmp_table_size=32m
Размер временных таблиц рекомендуется увеличивать до 32 Мб.
Рекомендуется так же увеличивать join_buffer_size до 2 Мб, это существенно влияет на скорость выполнения ряда запросов.
set-variable = join_buffer_size = 2M
Совет администратору Переход на InnoDB может привести к значительному замедлению некоторых масштабных операций записи и обновления данных. Это связано с тем, что все операции по изменению данных начинают выполняться с использованием транзакций. Кроме того, в отличие от MyISAM для кэширования таблиц InnoDB не используется кэш операционной системы, а все кэшированные данные хранятся в кэше БД, определяемом параметром innodb_buffer_pool_size . Вы должны сами определить оптимальность перехода вашего проекта на формат данных InnoDB.
Внимание! Если по каким-то причинам вы решили продолжить работу с типом данных MyISAM, обязательно проведите конфигурирование MySQL для увеличения объемов кэшируемой информации, областей сортировки и минимизации числа дисковых операций. Использование для базы данных 60-80% оперативной памяти может ускорить работу стандартного проекта в несколько раз.
Временная папка
При наличии достаточного количества ОЗУ рекомендуется выносить временную папку MySQL на ramdisk в памяти.
- Убедитесь, что в ядре реализована поддержка tmpfs.
- Создайте новую точку монтирования и дайте все права на использование:
# mkdir /mnt/tmpfs/ # chmod 777 /mnt/tmpfs/
# mount -t tmpfs -o size=1024M tmpfs /mnt/tmpfs/ или $ sudo mount -t tmpfs -o size=1024M tmpfs /mnt/tmpfs/
где 1024M есть размер RAMdisk в Мегабайтах.
Внимание! К размеру папки нужно подходить осторожно: если вы попросите создать ramdisk больше, чем имеете оперативной памяти, система начнёт сгружать всё в swap-файл и реальный результат подключения временной папки может быть отрицательным.
Список ссылок по теме:
Оптимизация Brainy под Битрикс
Как правило, если на VPS или выделенном сервере размещаются только сайты под управлением CMS Битрикс, то используется специализированное решение от самой Битрикс — «1С-Битрикс: Веб-окружение» — Linux (BitrixEnv). В этом случае каких-либо дополнительных действий по оптимизации не требуется.
Но, если необходимо разместить на той же машине сайты на других CMS, то данное окружение мало применимо. Выходом послужит использование одной из панелей управления, например бесплатной BrainyCP. Арендовать VPS в России или выделенный сервер в России можно на нашем сайте.
1. Проверка типа таблиц
Проверим какой тип таблицы используется в базе данных. Сделаем это, подключившись к MySQL через утилиту phpmyadmin, далее выбрав нужную базу и нажав «Структура».
Если таблицы имеют тип InnoDB, то дальнейших действий не требуется.
Если же все или часть таблиц имеют тип MyISAM, то переведем их в InnoDB, поскольку в большинстве случаев они работают быстрее нежели MyISAM. Да и оптимизации MySQL под один тип таблиц проще.
Сначала обязательно сделаем дамп базы данных, на случай если что-то пойдет не так. Сделать это можно через тот же phpmyadmin, в разделе «Экспорт».
Для перевода таблиц в существующей базе можно воспользоваться следующим запросом через phpmyadmin
SET @DATABASE_NAME = ‘name_of_your_db’;
SELECT CONCAT(‘ALTER TABLE `’, table_name, ‘` ENGINE=InnoDB;’) AS sql_statements
FROM information_schema.tables AS tb
WHERE table_schema = @DATABASE_NAME
AND `ENGINE` = ‘MyISAM’
AND `TABLE_TYPE` = ‘BASE TABLE’
ORDER BY table_name DESC;
name_of_your_db заменяем на имя базы данных. Результатом выполнения данного запроса будет текст другого запроса, который нужно будет скопировать и выполнить для перевода таблиц из MyISAM в InnoDB.
В зависимости от количества таблиц в базе и их имен может потребоваться включить опцию «Полные тексты» и увеличить количество выводимых строк в phpmyadmin
2. Оптимизация настроек MySQL для InnoDB
Оптимизируем настройки MySQL под InnoDB, исходя из оперативной памяти VPS
Задать данные настройки можно, как через панель «База данных» — «Управление MySQL/MariaDB» — «Управления через пакетный менеджер» — кнопка «Настроить», так и через консоль, редактируя файл.
Важно! Перед редактированием данного файла, создадим резервную копию файла.
Проще всего сделать это консольной командой cp /etc/my.cnf /etc/my.cnf _back
А так же копию базы данных через дамп или целиком скопировав папку /var/lib/mysql
innodb_buffer_pool_size — Это очень важный параметр для настройки InnoDB. Обычно предполагается выделение 70-80% памяти для серверов, на которых ничего не запущено, кроме InnoDB. Если же на сервере будут запущены и другие процессы (php, Apache и т.д.), то размер лучше ограничить в 40-50% от объема оперативной памяти.
innodb_additional_mem_pool_size — Данная опция практически никак не влияет на производительность MySQL, однако рекомендуется оставлять для InnoDB около 20 МБ (или чуть больше) под различные внутренние нужды.
innodb_log_file_size — Эта опция влияет на скорость записи. Она устанавливает размер лога операций (так операции сначала записываются в лог, а потом применяются к данным на диске). Чем больше этот лог, тем быстрее будут работать записи (т.к. их поместится больше в файл лога). Но следует помнить, что увеличение этого параметра увеличит и время восстановления системы при сбоях. Обычно выставляют значение около 64-512 МБ в зависимости от размера сервера.
innodb_log_buffer_size — Стандартное значение данной опции вполне подойдёт для большинства систем со средним количеством операций записи и небольшими транзакциями. Если же в Вашей системе бывают всплески активности, или Вы активно работаете с BLOB-данными, то рекомендуется немного увеличить значение innodb_log_buffer_size. Однако не переусердствуйте — слишком большое значение будет пустой тратой памяти: буфер сбрасывается каждую секунду, поэтому Вам не понадобится больше места, чем требуется в течение этой секунды. Рекомендуемое значение — около 8-16 МБ, а для небольших баз — и того меньше.
innodb_file_per_table. Если включить эту опцию, Innodb будет сохранять данные всех таблиц в отдельных файлах (вместо одного файла по умолчанию). Прироста в производительности не будет, однако есть ряд преимуществ:
- При удалении таблиц, диск будет освобождаться. По умолчанию общий файл данных может только расширяться, но не уменьшаться.
- Использование компрессионного формата таблиц потребует включить этот параметр.
Следует выставить значение innodb_file_per_table = ON
innodb_flush_logs_at_trx_commit — Значение по умолчанию 1 означает, что после каждой завершенной транзакции (или после изменения состояния транзакции) лог должен быть сброшен на диск. Это достаточно ресурсоемкая операция.
Многие приложения, особенно те, в которых раньше использовался MyISAM будут хорошо работать при значении 2, который означает, что не надо сбрасывать буфер на диск, а следует отправить его в кэш операционной системы. Лог по-прежнему будет сбрасываться на диск каждую секунду и максимум, что вы можете потерять — это 1-2 секунды записей. Значение 0 обеспечивает более высокую скорость, но и более низкую надежность.
Следует выставить значение innodb_flush_logs_at_trx_commit = 0 или innodb_flush_logs_at_trx_commit = 2
innodb_flush_method Рекомендуется — innodb_flush_method = O_DIRECT, либо innodb_flush_method = O_DSYNC чтобы избежать двойного кеширования (выключает операционный кеш для файлов данных MySQL) .
O_DSYNC будет работать быстрее, чем O_DIRECT, но не так надежно.
transaction-isolation. Уровень изоляции транзакций. Рекомендуется значение READ COMMITTED. Это уровень изолированности, который устанавливается по умолчанию — в большинстве СУБД (но не в MySQL!). Он соответствует приведенному ранее простому определению изолированности: транзакция увидит только те изменения, которые к моменту ее начала подтверждены другими транзакциями, а произведенные ею изменения останутся невидимыми для других транзакций, пока текущая не будет подтверждена. Задается строкой:
transaction-isolation = READ-COMMITTED
innodb_doublewrite. Doublewrite представляет собой буфер двойной записи и используется в InnoDB чтобы изменённые страницы были записаны в файл данных. Позволяет избежать потери данных при внезапном сбое сервера. В этом режиме InnoDB перед записью страниц в основной файл данных предварительно записывает их в непрерывную область — doublewrite. В целом не рекомендуется отключать на продакшене при работе с ценными данными, т.к. в результате сбоя сервера повреждается файл с данными без возможности сделать repair.
В остальных случаях можно ускорить работу выставив innodb_doublewrite = 0
innodb_io_capacity. Параметр контролирует, как много операций запросов на запись за секунду будет совершать сервер при выполнении операций сброса на диск. На стандартных значениях SSD-диски зачастую не могут реализовать полностью свой потенциал, для них рекомендуемое значение следующее: innodb_io_capacity = 2000
sync_binlog. Параметр sync_binlog определяет логику синхронизации данных из бинлога с диском. Если значение равно 1, запись на диск будет происходить после каждой транзакции. Это делает хранилище очень надежным, но крайне сильно нагружает дисковую подсистему. Значение 0 отключит синхронизацию из Mysql, и база данных будет полагаться на ОС в вопросе записи лога на диск. Такое значение может сильно увеличить производительность. Задаём значение sync_binlog = 0
Также для всех типов таблиц рекомендуется настроить следующие параметры:
skip-name-resolve — не определять доменные имена для IP-адресов подключающихся клиентов. При этом пользовательские разрешения нужно настраивать не на хосты, а на IP-адреса (за исключением localhost). Если вы соединяетесь с сервером только с локальной машины, то особого значения не имеет. Для внешних соединений ускорит установку соединения.
skip-external-locking — опция установлена по умолчанию, начиная с версии 4. Указывает MySQL-серверу не использовать внешние блокировки при работе с базой. Внешние блокировки необходимы в ситуациях, когда несколько серверов работают с одними и теми же файлами данных, т.е. имеют одинаковую datadir, что на практике не используется.
sql_mode. Контроль режимов работы sql. Рекомендуется режимов не задавать, задав строку в виде
sql_mode = »
table_open_cache. Оптимальное значение рассчитывается как количество таблиц во всех базах, умноженное на 2, ориентировочно рекомендуем устанавливать опцию в 2048.
thread_cache_size определяет максимальное количество тредов в кеше. Когда новый клиент устанавливает соединение с Mysql, Mysql открывает создает новый тред (thread) для этого клиента. В средах с больших количеством клиентов и соединений, создание и удаление тредов становится дорогой операцией. Для того, чтобы оптимизировать этот процесс, существует настройка thread_cache_size. Вместо постоянного создания и удаления, Mysql может сохранять неактивные треды в кеш (и использовать в случае необходимости).
Если есть возможность, рекомендуется установить это значение не меньше, чем значение переменной max_used_connections. Если значение max_used_connections больше 128, рекомендуется ограничиться этим значением.
Проверить значение max_used_connections можно подключившись к MySQL и введя команду:
show status LIKE «max_used_connections%
Чтобы изменения вступили в силу необходимо перезагрузить mysql командой:
service mysqld restart
3. Изменение настроек PHP
Переходим в хост-аккаунт, на котором будем размещать сайт
В разделе «WWW» — «Конфигурация php.ini» задаем для соответствующей версии PHP значение параметров:
opcache.revalidate_freq=0
max_input_vars = 10000
4. Изменение настроек opcache
Через консоль (по ssh) или через файловый менеджер под пользователем root правим файл по пути /home/имя хост-аккаунта/etc/версиязрз/php.d/10-opcache.ini (В данном примере это для пользователя admin и версии php7.4 это /home/admin/etc/php74w/php.d/10-opcache.ini), в котором задаем значение:
opcache.max_accelerated_files = 10000
и перезапускаем веб-сервер командой:
service httpd restart
Все способы
© 2009–2024 «HANDYHOST.RU» 8-800-505-68-01
- Услуги
- Хостинг сайтов
- Домены
- Конструктор сайтов
- Linux VPS / Windows VPS
- Выделенные серверы
- SSL сертификаты
- Клиентам
- Контакты
- О компании
- Акции
- Оборудование
- Партнерская программа
- Поддержка
- Способы оплаты
- Регламент
- Документы
- Справка
Как пофиксить медленную запись в БД MySQL?
Сервер выделенный, достаточно мощный. База на SSD. Почему-то низкие показатели на запись. Первым индикатором стали показания битрикс «панель производительности». (про то какой битрикс «чудо» продукт, я в курсе).
Затем провел несколько тестов.
./mysqltuner.pl
>> MySQLTuner 1.6.10 — Major Hayden
>> Bug reports, feature requests, and downloads at mysqltuner.com
>> Run with ‘—help’ for additional options and output filtering
[—] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.1.73
[OK] Operating on 64-bit architecture
——— Storage Engine Statistics ——————————————————————
[—] Status: +CSV +InnoDB +MRG_MYISAM
[—] Data in MyISAM tables: 81K (Tables: 12)
[—] Data in InnoDB tables: 6G (Tables: 3335)
[!!] Total fragmented tables: 149
——— Performance Metrics ————————————————————————
[—] Up for: 82d 17h 56m 35s (2 q [0.000 qps], 25M conn, TX: 157B, RX: 115B)
[—] Reads / Writes: 100% / 0%
[—] Binary logging is disabled
[—] Physical Memory : 62.9G
[—] Max MySQL memory : 9.9G
[—] Other process memory: 13.8G
[—] Total buffers: 8.2G global + 24.9M per thread (70 max threads)
[—] P_S Max memory usage: 0B
[—] Galera GCache Max memory usage: 0B
[OK] Maximum reached memory usage: 9.9G (15.76% of installed RAM)
[OK] Maximum possible memory usage: 9.9G (15.72% of installed RAM)
[OK] Overall possible memory usage with other process is compatible with memory available
[OK] Slow queries: 0% (0/2)
[!!] Highest connection usage: 100% (71/70)
[OK] Aborted connections: 0.51% (130070/25606836)
[OK] Query cache efficiency: 100.0% (457M cached / 457M selects)
[!!] Query cache prunes per day: 1965813
[OK] No Sort requiring temporary tables
[OK] No joins without indexes
[OK] No tmp tables created on disk
[OK] Thread cache hit rate: 99% (10K created / 25M connections)
[OK] Table cache hit rate: 100% (9K open / 0 opened)
[OK] Open file limit used: 0% (124/28K)
[OK] Table locks acquired immediately: 99% (3B immediate / 3B locks)
——— MyISAM Metrics —————————————————————————-
[!!] Key buffer used: 18.3% (24M used / 134M cache)
[OK] Key buffer size / total MyISAM indexes: 128.0M/138.0K
[OK] Read Key buffer hit rate: 100.0% (1B cached / 30 reads)
[OK] Write Key buffer hit rate: 100.0% (499M cached / 24 writes)
——— InnoDB Metrics —————————————————————————-
[—] InnoDB is enabled.
[OK] InnoDB buffer pool / data size: 7.8G/6.6G
[OK] InnoDB Used buffer: 87.81% (449606 used/ 512000 total)
[OK] InnoDB Read buffer efficiency: 100.00% (4784039165461 hits/ 4784039252171 total)
[!!] InnoDB Write Log efficiency: 13.3% (16130866 hits/ 121277476 total)
[!!] InnoDB log waits: 0.00% (7 waits / 105146610 writes)
——— Replication Metrics ————————————————————————
[—] Galera Synchronous replication: NO
[—] No replication slave(s) for this server.
[—] This is a standalone server.
——— Recommendations —————————————————————————
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
Enable the slow query log to troubleshoot bad queries
Reduce or eliminate persistent connections to reduce connection usage
Increasing the query_cache size over 128M may reduce performance
Variables to adjust:
max_connections (> 70)
wait_timeout ( < 28800)
interactive_timeout ( < 28800)
query_cache_size (> 128M) [see warning above]
innodb_log_buffer_size (>= 1M)
mysqlslap -u root -p —auto-generate-sql
Enter password:
Benchmark
Average number of seconds to run all queries: 0.481 seconds
Minimum number of seconds to run all queries: 0.481 seconds
Maximum number of seconds to run all queries: 0.481 seconds
Number of clients running queries: 1
Average number of queries per client: 0
mysqlslap -u root -p —auto-generate-sql —concurrency 20 —iterations 10 —engine=innodb -vvv
Enter password:
Benchmark
Running for engine innodb
Average number of seconds to run all queries: 6.309 seconds
Minimum number of seconds to run all queries: 1.907 seconds
Maximum number of seconds to run all queries: 14.787 seconds
Number of clients running queries: 20
Average number of queries per client: 0
Подскажите где копать?
- Вопрос задан более трёх лет назад
- 7547 просмотров
Как ускорить сайт на 1С-Битрикс: 14 шагов, чтобы увеличить производительность и скорость
За последние три года мы оптимизировали производительность многих проектов на 1С-Битрикс. Среди них были как новые сайты, которые размещались на хостинге впервые, так и проекты, перенесённые с других хостингов и корпоративных серверов.
В этой статье вы узнаете основные шаги, которые мы рекомендуем, чтобы увеличить производительность сайта и сделать его более быстрым для посетителей и поисковых систем.
На какой результат можно рассчитывать?
Если пройти эти шаги последовательно, то можно увеличить производительность даже очень медленных сайтов, которые показывают 20-30 пунктов по шкале Битрикс, до 100 пунктов и выше.
С помощью правильных настроек вполне реально сделать так, чтобы “тормозной” сайт стал “летать” и радовать посетителей удобством и высокой скоростью.
Итак, вот 14 шагов для оптимизации сайта на 1С-Битрикс:
- Подобрать более мощное железо на хостинге.
- Использовать специализированное окружение Битрикс.
- Минимизировать скрипты и стили.
- Отследить и исправить медленные запросы.
- Сжать изображения.
- Отложить загрузку медиа-контента.
- Настроить время жизни кэша.
- Включить CDN.
- Обновить версию PHP до 7.1 и выше.
- Отключить лишние модули.
- Оптимизировать настройки БД.
- Создать фасетные индексы.
- Включить тип таблиц InnodDB в базе данных.
- Настроить innodb buffer pool size.
Рассмотрим каждый из этих шагов подробнее.
Подобрать более мощное железо на хостинге
Производительность сайта зависит от серверных мощностей – количества ядер и частоты процессора, объёма оперативной памяти, типа и ёмкости дисков.
Если вы настраиваете хостинг для нового проекта, важно выбрать конфигурацию сервера, соответствующую “прожорливости” сайта и предполагаемому уровню нагрузки. А уже затем делать тонкую настройку на основе мониторинга производительности.
Мы знаем, что Битрикс очень чувствителен к частоте процессора, скорости дисков и объёму памяти. Поэтому в шаблонах хостинга Максиплэйс предусмотрено несколько готовых конфигураций. На них большинство сайтов, которые переезжают к нам с обычных хостингов, сразу начинают показывать более высокую производительность.
Для сайтов компаний и интернет-магазинов с небольшой посещаемостью будет достаточно 1-2 ядер процессора, 2 Гб оперативной памяти и до 30 Гб на SSD-диске. Эта конфигурация подойдет и для тех, кто только запустил сайт и ещё не замерил нагрузку от посещаемости.
Если же ваш сайт достаточно “тяжёлый”, понадобится больше ресурсов. Так, для сайтов с высокой посещаемостью, а также интернет-магазинов с большим каталогом товаров или порталов, например, Битрикс24, мы рекомендуем использовать тариф “MIDDLE” с 4 ядрами процессора, 4 Гб RAM и 80 Гб на SSD-диске.
По стоимости переход с минимальной конфигурации на среднюю сопоставим со стоимостью одного (!) небольшого заказа в интернет-магазине (около 2 тыс. рублей). А результатом может быть как рост заказов за счёт ускорения работы сайта, так и повышение позиций сайта в поисковой выдаче.
После усиления или оптимизации “железа” переходим к настройке окружения и самого сайта.
Если вы настраиваете хостинг для нового проекта, важно выбрать конфигурацию сервера, соответствующую “прожорливости” сайта и предполагаемому уровню нагрузки. А уже затем делать тонкую настройку на основе мониторинга производительности.
Использовать специализированное серверное окружение Битрикс
Мы рекомендуем использовать на хостинге специализированное окружение – виртуальную машину BitrixVM, рекомендованную разработчиками платформы 1С-Битрикс.
Что даёт использование специализированного окружения?
«1C-Битрикс: Виртуальная машина» – это виртуальный сервер, полностью настроенный, протестированный и предназначенный для оптимальной работы с сайтами на «1С-Битрикс».
В нём уже учтены многие параметры, влияющие на производительность. Набор ПО и связка веб-сервисов уже настроена, чтобы обеспечить оптимальную работу сайта на 1С-Битрикс или портала Битрикс24.
Если же вы не используете окружение Битрикс, а самостоятельно конфигурируете среду на своём VPS-сервере, обратите внимание на режим использования php как модуль apache. Эту опцию вы увидите в настройках и можете использовать её для ускорения работы Битрикс. При этом есть много нюансов, так как при высокой нагрузке предпочтительным окажется другой режим, и придётся привлекать специалиста.
Поэтому для удобства и скорости развёртывания мы рекомендуем использовать готовое и многократно протестированное окружение BitrixVM. Мы используем его для всех клиентских проектов на платформе Битрикс.
Обновить версию PHP до 7.Х
Если вы устанавливали виртуальную машину больше года назад, скорее всего, у вас стоит одна из старых версий PHP.
Нужно проверить версию PHP и обновить её до 7.x, т.к. новые версии работают быстрее.
Когда основа серверной части настроена, пора переходить к настройкам, которые делаются из админ-панели 1С-Битрикс.
Минимизировать скрипты и стили
Большинство файлов стилей и скриптов не используются на начальном этапе загрузки страницы, поэтому их стоит перенести в самый конец. При этом минификация и объединение сократят их вес и снизят количество запросов.
В настройках главного модуля необходимо выставить галочки, как показано на скриншоте ниже.
Очень важно учесть момент подключения файлов скриптов и стилей, они должны быть подключены следующим образом:
Это важно, так как в случае статического подключения, оптимизировать файлы не удастся.
Уже только это может дать ощутимое ускорение загрузки страниц сайта.
Сжать изображения
Основным «тяжелым» ресурсом на веб-странице являются изображения. Чем больше их вес, тем медленнее загружается страница.
Для Битрикса существует отличное бесплатное решение для оптимизации изображений без потери качества. Работает оно буквально в один клик.
Часто веб-мастера упускают оптимизацию изображений, а зря. Нам приходилось встречать сайты, где в плейсхолдеры 300х400 пикселей вставлены картинки размером 1200х1600.
Представьте, насколько медленно грузится такой интернет-магазин, если в его каталоге 40 тысяч товаров.
Отложить загрузку медиа-контента
Что пользователю важнее увидеть в первую очередь: красивые картинки или основной контент сайта? Картинки, безусловно, важны, но лучше первым делом показать структуру и контент. Для решения этой задачи можете воспользоваться плагином JQuery Lazy. Для его работы также необходимо использовать библиотеку JQuery.
Подключение плагина в шаблоне сайта
use Bitrix\Main\Page\Asset;
Asset::getInstance()->addJs(SITE_TEMPLATE_PATH . «/js/jquery.min.js»);
Asset::getInstance()->addJs(SITE_TEMPLATE_PATH . «/js/jquery.lazyloading.min.js.js»);Инициализация плагина для выбранного класса изображений
Изображениям необходимо добавить выбранный класс .lazy-img , а также заменить атрибут src на data-src
» >
Для решения проблемы с изображениями являющимися background-ом, вместо css свойства background: url(/images/cloud.jpg) следует добавить класс .lazy-img и атрибут data-src для блока
Настроить время жизни кеша
Эта настройка определяет частоту обновления информации на странице.
Если информация на сайте обновляется раз в сутки, то ошибочно будет оставлять время жизни кэша по умолчанию (3600 с). Необходимо выставить значение 24 часа (86400 с), иначе каждый час посетитель будет заново загружать контент с сервера.
Этот параметр важно учитывать и выставлять с учётом периода реального обновления информации на сервере.
Проверить, что подключён механизм кеширования memcached
Memcached – это сервис кэширования данных в оперативной памяти на основе хеш-таблицы. Это самый быстрый способ кеширования, так как ОС при наличии ресурсов будет держать последние открытые файлы в памяти. Поэтому убедитесь, что он подключён.
Когда мы переносим сайты на хостинг, в нашем шаблоне он включен по умолчанию. Проверьте в настройках сайта (dbconn), что этот механизм включен и используется, потому что он также обеспечивает ускорение в работе.
Подключить CDN
Битрикс предоставляет возможность использовать технологию CDN (Content Delivery Network), которая позволяет загружать картинки, стили и скрипты с сервера, находящегося ближе всего к пользователю. Это увеличивает скорость загрузки всей страницы.
Для включения данной опции необходимо перейти в Настройки — Облако 1С-Битрикс — Ускорение сайта (CDN).
После включения CDN произведите замер скорости загрузки для исключения противоположного эффекта.
В Также в панели есть инструмент измерения скорости загрузки отклика сайта. Он измеряет скорость загрузки сайта у посетителей.
Этот тест показывает четыре зоны — “Очень быстро”, “Быстро”, “Медленно” и “Очень медленно”, а также среднее время загрузки. Рассчитывается для 1000 последних посетителей вашего сайта. Скорость сайта фактически показывает, как быстро отобразился ваш сайт для большинства из этих 1000 посетителей.
Также можно тестировать скорость загрузки и с помощью сервиса Google PageSpeed или с помощью средств разработчика в одном из современных браузеров.
Оптимизировать настройки БД
В настройках БД важно проверить несколько параметров.
Настроить тип таблиц
Если мы говорим про современные проекты, которые переносим с других серверов, проверьте, что тип таблиц в базе – InnoDB.
Сайты с этим типом таблиц работают быстрее и надёжнее с точки зрения сохранности данных. Это соответствует рекомендациям Битрикс.
Настроить параметр buffer pool size
Общая рекомендация — проверять и выставлять innodb buffer pool size примерно равным объёму БД.
В шаблоне BitrixVM он настраивается автоматически в зависимости от объема оперативной памяти на сервере.
Создать фасетные индексы
Данный механизм позволяет сэкономить время на выдаче результата запроса.
Например, вы решили найти на сайте информацию о BMW M5. Без использования фасетного индекса поиск осуществлялся бы сначала по маркам автомобилей, а затем по модельному ряду. Фасетные индексы заранее предопределяют возможные варианты и поиск выдаст результат быстрее.
Для создания фасетного индекса необходимо, чтобы свойства товара присутствовали в умном фильтре. После чего во вкладке Контент — Инфоблоки — Фасетные индексы следует запустить процесс создания индексов.
Включить композитный режим работы сайта
Заходим в панель управления сайтом. Переходим в раздел
Настройки > Настройки продукта > Композитный сайт > Настройки > Композит
Нажимаем «Включить композит»
Также нужно установить время жизни кэша сутки (86400 сек), так как 120 секунд ухудшат производительность.
Включаем настройки nginx для композитного сайта через утилиту командной строки
/opt/webdir/bin/bx-sites -o json -a composite —enable —site=default
(вместо default, если нужно, вписываем имя требуемого сайта)
Для отключения, соответственно:
/opt/webdir/bin/bx-sites -o json -a composite —disable —site=default
Отключить лишние модули
В Битриксе есть модули, которые не все используют. Они включены по умолчанию, но нужны далеко не каждому сайту.
К ним можно отнести AD/LDAP интеграцию, Push and Pull, Wiki, А/B-тестирование, Веб-аналитику, Веб-кластер, Веб-мессенджер, Веб-сервисы, Дизайнер бизнес-процессов, Документооборот, Календарь событий, Конструктор отчетов, Менеджер идей, Мобильную платформу, Мобильное приложение для интернет-магазина, Обучение, Перевод, Почту, Техподдержку, Универсальные списки, Управление масштабированием, а также модуль интеграции с “Битрикс24”. Все они отрицательно влияют на производительность. Поэтому неиспользуемые модули важно отключить.
Другой пример такого модуля – “Сайты24”, который позволяет быстро создавать простые сайты на 1С-Битрикс без веб-разработчика. Его тоже можно отключить, чтобы ускорить работу основного сайта.
Отследить медленные запросы и узкие места в структуре сайта и БД
Часто к нам обращаются клиенты с такой проблемой: начал тормозить сайт, который до этого работал хорошо.
Например, инженеры анализируют нагрузку и видят, что большинство запросов идёт со стороны сервиса MySQL. При этом по данным мониторинга за предыдущие дни повышенной загрузки раньше не было.
Сначала инженеры пробуют выяснить у клиента, что именно менялось на сайте. И если клиент не может сказать точно, тогда инженеры с помощью специальных утилит отслеживания, смотрят, какие запросы выполняются медленно или создают высокую нагрузку на базу данных.
- mytop
- mysqldumpslow
- pt-query-digest (требуется, если установлен Percona Server)
Иногда видно, что на сайте появились ресурсоёмкие циклические запросы, которые и тормозят работу.
Мы указываем на них заказчику. Он понимает, какими изменениями кода они вызваны, и принимает меры, чтобы исправить ситуацию.
Что-то из этого можно увидеть в админке Битрикса самостоятельно, включив отслеживание производительности и не обращаясь к инженерам. Это поможет понять, какие изменения на сайте или в логике его работы приводят к таким тормозящим запросам.
В панели производительности есть возможность посмотреть на показатели и проанализировать детально скорость загрузки страниц.
Несколько вариантов конфига mysql, где включить логирование:
/etc/my.cnf
/etc/mysql/mariadb.conf.d/50-server.cnf
/etc/my.cnf.d/server.cnf
/etc/mysql/conf.d/bx_replica.cnfПравим:
[mysqld]
slow_query_log = 1
long_query_time = 5 # нужное количество в секундах
slow_query_log_file = /var/log/mysql/mysql-slow.logРекомендуется включить режим диагностики и походить по своему сайту. Битрикс фиксирует это в диагностическом модуле и показывает, что вызвало задержки. Также можно посмотреть самые частые и самые медленные запросы к БД. И на основе этих данных решить, что можно оптимизировать в коде сайта.
На какой прирост производительности можно рассчитывать?
При отключении неиспользуемых модулей можно сразу получить прирост производительности в 10-20 пунктов.
Оптимизация запросов MySQL может дать очень много в зависимости от самих запросов. Если сайт работал совсем медленно, показывая индекс 20-30, то после ликвидации медленного запроса индекс может подняться до 100 пунктов.
Вот один из примеров:
Заказчик обратился к нам с интернет-магазином автозапчастей с большим каталогом. Сайт открывался очень медленно. Посмотрели производительность по страницам.
Главная открывалась быстро, переход по разделам тоже. А при открытии карточек товаров сайт начинал тормозить. Так, страница с товаром загружалась 25-30 секунд. Посмотрели на сервере – особенной нагрузки при этом не было.
Стали выяснять у заказчика, что он делал на сайте до появления проблемы. Заказчик вспомнил, что включал модуль нанесения водяных знаков на изображения. Сначала модуль работал нормально, но потом стал переполняться диск, и заказчик этот модуль отключил. Видимо, модуль не отключился полностью и начал вызывать огромную задержку при просмотре товаров.
В итоге клиент заново установил и удалил этот модуль, после чего проблема исчезла.
Правило: вспомните, что вы меняли перед тем как сайт стал тормозить, даже если это, казалось бы, никак не связано с замедлением его работы.
При переносе сайтов на наш хостинг мы проверяем все настройки конфигурации и выставляем их правильно, так как сайты переносятся на подготовленное окружение.
Дополнительно инженеры выставляют параметры, основываясь на специфике каждого отдельного сайта, чтобы обеспечить его максимальную производительность.
Для проектов с высокой нагрузкой иногда приходится придумывать отдельные решения.
Использовать масштабируемый кластер серверов без покупки дорогостоящего решения
Недавно у медиа-компании, которая прогнозировала большой наплыв посетителей, появилась задача увеличить параметры сервера, чтобы гарантированно справиться с нагрузкой.
Мы посчитали, что даже максимальных показателей одного сервера будет недостаточно. Компания обратилась к нам с вопросом, что можно сделать в этой ситуации.
Конечно, есть коробочное решение – пакет Битрикс Enterprise, который позволяет размещать сайты на нескольких серверах, чтобы справляться с высокой нагрузкой. Но это решение очень дорогостоящее, стоимостью в сотни тысяч рублей. Заказчик пока не рассматривал такие инвестиции.
Поэтому мы предложили создать простую версию масштабируемого кластера без необходимости покупать дорогую лицензию.
Контент сайта мы разместили на двух серверах так называемых “php бэкендах”, и добавили отдельный сервер в качестве балансировщика. Он распределял нагрузку между двумя серверами в зависимости от количества запросов к сайту. База данных была вынесена на отдельный сервер.
Тестирование показало, что максимальное количество запросов (RPS) которые способен обработать кластер, выросло как минимум в три раза по сравнению с одиночным сервером. При этом появилась возможность дальнейшего масштабирования кластера за счёт добавления дополнительных бэкендов.
При очередном скачке посетителей такое кластерное решение справилось с возросшей нагрузкой, и задача была решена.
Таким образом, клиент получил кластерное решение без необходимости платить сотни тысяч рублей за покупку дорогой лицензии. Задача была решена на порядок меньшим бюджетом.
Двойной эффект от ускорения сайта
Увеличение скорости работы сайта имеет двойной эффект.
Во-первых, быстрые сайты, которые “летают”, имеют для посетителей “вау-эффект”. По сравнению с ними сайты конкурентов кажутся ещё более медленными и задержки при работе с ними начинают раздражать. А выделяющийся на их фоне быстрый сайт не только подтверждает, что компания вложилась в технологии и подумала об удобстве пользователей, но и создаёт “эффект притяжения” — на таком сайте хочется дольше находится, чаще возвращаться и совершать больше транзакций.
И во-вторых, как отмечают многие из наших клиентов, ускорение загрузки страниц сайта повышает его позиции в поисковой выдаче Google и Яндекс. А это уже прямая коммерческая выгода.
Мы постарались в этой статье написать о тех приёмах увеличения скорости загрузки, которые можно как использовать самостоятельно, так и обратиться за консультацией к нашим специалистам. Будем рады помочь ускорить и ваш интернет-проект.
Если у вас есть что добавить к этим способам или вы захотите поделиться своими – напишите в комментариях. Будет полезно всем, кто работает в этом направлении.
Статья добавлена 1 год назад. Автор — Eltigro