1. Обновление системы балансировки запросов в кластере
Новая версии системы балансировки запросов в кластере, существенно улучшает процесс распределения запросов, оптимизируя распределение нагрузки между серверами. Коротко, основные изменения в следующем:
- До первого запроса изменения данных: система функционирует в привычном режиме.
- В случае запроса на изменение данных, фиксируется список модифицированных таблиц.
- При последующих запросах выборки, проверяется есть в них изменённые таблицы или нет. Если таблицы используемые в запросе не модифицировались, запросы продолжают обрабатываться через slave-серверы.
Тесты показали значительное увеличение количества запросов, обрабатываемых slave-серверами. И минимизацию ошибок при работе с кластерной конфигурацией. Это позволяет лучше распределять запросы между серверами и практически полностью разгружать мастер сервер.
Стандартный вариант балансировки: Master порядка 30 la, Slave порядка 3 la.
Новый вариант балансировки: Master порядка 1 la, Slave порядка 50 la
Прекрасный результат! Настройки кластера теперь позволяют перенаправлять 100% нагрузки на slave-серверы.
2. Улучшения в системе кеширования
И еще одно интересное обновление главного модуля, касается системы кеширования. И позволит любым проектам сильно повысить свою устойчивость к высоким нагрузкам:
- Оптимизация очистки кеша для Redis и Memcached ( расширение php ).
- Исправление ошибок в условиях гонки, приводивших к созданию нескольких копий одного кеша, снижает расход памяти.
- Функционал "блокирующего режима" кеширования. При этом кеш генерируется одним потоком, а остальные получают старое значение до его обновления в кеше. Или если его нет, то как и раньше каждый поток генерирует данные.
"Блокирующий режим" режим в котором кеш генерирует только один поток, а остальные получают передыдущие значение. При этом как таковой блокировки нету, параллельные потоки получат либо старое значение ключа кеша. Либо если его нету, тоже начнут его генерировать, как и раньше.
Блокирующий режим работает, если:
- Кеш истек, и с момента истечения не прошло более установленного времени.
- Кеш был удалён по ключу, и с момента удаления не прошло более 60 секунд (настраиваемый параметр).
// Удаление кеша по ключу, с сохранением старого значения $cache = Bitrix\Main\Data\Cache::createInstance(['actual_data' => false]); $cache->clean($key, $dir); // Создание кеша с поддержкой работы со старыми ключами $cache = Bitrix\Main\Data\Cache::createInstance(['actual_data' => false]); |
- Компоненты как раз поддерживают работу, в этом режиме по умолчанию.
Будет работать обычный механизм
- Кеш создан или очищен без указания параметра ['actual_data' => false][
- Кеш истек по времени, больше чем на ttl * $ttlMultiplier
- Была очистка кеша по тегу или по папке.
- Кеш был очищен по ключу, но время с момента его удаления прошло более 60 сек.
Пример работы: В демонстрационном видео показано, как два потока обращаются к одному ключу кеша. При этом один из потоков периодически очищает ключ кеша, в это время второй продолжает получать старые данные до момента обновления.
В ряде случаев такой подход сильно снижает нагрузку. Ниже пример нагрузочного теста на портале с авторизацией на пустой странице и открытие страницы с компонентом списков новостей с небольшим временем жизни кеша. В обычном режиме видим пики времени генерации, низкий общий rps и пики ошибок.
В блокирующем режиме, видим более стабильное время генерации, более высокий rps, большее количество хитов, меньшее время генерации.
