Сетевые скидки и их влияние на производительность
Одним из основных блоков работы в ресторанных сетях является подсистема маркетинга и расчета скидок при реализации товаров и блюд на кассовых местах. Задача расчета скидок является в достаточной степени нетривиальной. Связано это с тем, что скидки имеют двойственную природу: локальные (например, каждый второй кофе в заказе бесплатно) или сетевые (например, 10-я чашка кофе бесплатно, вне зависимости от места покупки предыдущих 9-ти чашек). И если вопрос расчета локальной скидки может быть решен в базе на кассовом узле, то получение информации по сетевым скидкам возможно только при наличии информации обо всем, что происходит в компании в целом. Поэтому облачный или корпоративный серверы, на которых производится расчет скидок при обращении к ним из кассовых узлов, испытывают повышенную нагрузку.
Результатом повышенной нагрузки может являться замедление работы системы, увеличения ожидания отзыва от сервера и, как следствие, ожидание клиента на кассе с накоплением негатива обслуживаемых клиентов. Большая очередь в заведении может резко снижать репутацию и вести к уменьшению продаж. По этой причине в задачу проектирования блока скидок включается требование обеспечения производительности, чтобы время расчета и отклика не превышали 3 секунд.
В рамках данной статьи будет рассматриваться исследование возможностей блока дисконтного сервера на базе типового решения «1С:Фастфуд. Фронт-офис», а также повышения эффективности его работы.
Тестовый стенд
Параметры стенда:
- Типовое решение на кассовых узлах: «1С:Фастфуд.Фронт-офис» в файловом режиме 32х.
- Количество кассовых узлов — 50.
- Типовое решение в сети для расчета скидок: «1С:Фастфуд.Фронт-офис» в серверном режиме с публикацией в режиме веб-сервиса 64х.
- Операционная система: Windows Server 2012 R2.
- База данных: Microsoft SQL Server 2017 64х.
- Платформа 1С: 8.3.14.1630.
- Количество настроенных скидок — 20.
- Целевое время выполнения расчета скидок — не более 3 секунд.
-
Конфигурация сервера для расчета скидок.
- Процессор: Intel Xeon X5680 12M Cache 3.33, 6 ядер, 2 шт.
- Оперативная память: 16GB/DDR3/2Rx4.
- Дисковый накопитель: Intel SSDSC2BA800G4.
Исследование
Блок дисконтного сервера «1С:Фастфуд. Фронт-офис» предполагает наличие распределенных баз данных (РИБ). При этом в центральной базе публикуется веб сервис, позволяющий выполнять обновление данных по операциям из кассовых узлов и обратную передачу информации по скидкам в режиме реального времени.
Выполнение нагрузочного тестирования можно выполнять различными способами и с использованием различных инструментов. Например, выполнять тестирование вручную, или применять подсистему «1С:Тест-центр» (ТЦ) из пакета «1С:Корпоративный инструментальный пакет» (КИП), или использовать сторонние программы и утилиты, эмулирующие нагрузку на систему. Далее подробнее остановимся на возможных инструментах.
1С:Тест-центр:
Использование конфигурации «1С:Тест-центр» из пакета 1С:КИП.
Подсистема «1С:Тест-центр» это инструмент автоматизации многопользовательских нагрузочных испытаний информационных систем на платформе «1С:Предприятие 8». С его помощью можно моделировать работу предприятия без участия реальных пользователей, что позволяет оценивать применимость, производительность и масштабируемость информационной системы в реальных условиях.
Для использования данной подсистемы требуется ее включение в тестируемую конфигурацию. Для этого потребуется файл конфигурации «Тест-центр» (формата *.cf), и с помощью механизма «сравнение/объединение» объединяем с основной конфигурацией.
Стоит отметить, что подсистема «Тест-центр» использует подсистему «Оценки производительности», входящую «1С:Библиотека стандартных подсистем» (БСП). Поэтому в случае, если тестируемая конфигурация не содержит ее, требуется подключить и ее.
Далее необходимо подготовить обработку, которая в дальнейшем будет выполнять сценарий работы, моделирующий работу пользователя. В качестве основы такой обработки рекомендуется использовать обработку «ТЦШаблонТестовойОбработки», которая входит в подсистему «Тест-центр».
Описание логики планируемого сценария прописывается в модуле формы. Для получения данных по времени операций добавляем вставить подсистемы Оценки производительности Начать и Зафиксировать замеры.
После выполнения подготовительного этапа в конфигураторе можно переходить в настройку в режиме «1С:Предприятие».
В подсистеме «Администрирование» включаем оценку производительности БСП.
Последующие шаги выполняем в подсистеме «Тест-центр».
Создаем новый элемент в справочнике «Обработки» и указываем путь к подготовленной ранее обработке. Стоит отметить, что Тест-центр позволяет тестировать как встроенные в конфигурацию обработки, так и внешние.
Затем переходим в справочник «Роли». Данный справочник позволяет интерактивно заполнить ограничения, параметры формы обработки, а также запустить обработку вручную, чтобы проверить отсутствие ошибок выполнения.
Для выполнения всех этих действий необходимо нажать на кнопку «Настроить».
Следующим шагом настройки является создание элемента справочника «Компьютеры». В качестве наименования необходимо указывать имя компьютера, которое можно найти в свойствах системы.
Далее добавляем новый элемент в справочнике «Клиенты». В данном элементе необходимо выбрать компьютер, на котором будет производится запуск, а также тип клиента, под которым будет запускаться тестируемое приложение.
На этом подготовка заканчивается и можно переходить к экспериментам.
Для этого переходим в справочник «Агенты» и запускаем агента тестирования.
После чего переходим в Сценарии тестирования, где создаем и заполняем новый элемент, указывая структуру запуска и список ограничений.
Подготовив элемент сценария, можно начать его запуск — для этого необходимо нажать на кнопку «Выполнить».
После выполнения тестирования появляется отчет по созданным ключевым операциям.
В ходе данного эксперимента нас интересует событие «Нажатие на обработку расчета скидок». Среднее время его выполнения составляет 4,988 секунды, что превышает рекомендуемое время выполнения на 66%.
Также можно выявить, что основное время занимает расчет скидок и постоянное получение данных с центрального сервера.
Использование сторонних программ и утилит:
В случае, когда нет возможности воспользоваться конфигурацией «1С:Тест центр» из-за ее отсутствия, или условия проведения эксперимента не позволяют этого сделать, или потому, что по условиям эксперимента использование тест-центра неудобно. Например, если тестируемое приложение является файловой базой или количество запускаемых сеансов настолько велико, что ресурсы компьютера существенно «выедаются» самим тест-центром, то для таких ситуаций можно воспользоваться дополнительными инструментами.
Для проверки нагрузки центрального сервера была разработана утилита на C#, позволяющая отправлять пакеты данных, аналогичные пакетам, отправляемыми из кассового узла. Одной из возможных причин задержек отклика предполагался способ соединения и передачи данных на сервере расчета скидок. В качестве способа обмена последовательно проводились эксперименты: SOAP (от англ. Simple Object Access Protocol) и REST (от англ. Representational State Transfer).
Внешний вид утилиты весьма прост: задаются параметры нагрузки и запускается утилита кнопочкой «В бой». С помощью дополнительных параметров утилиты можно выполнить настройку в количестве потоков/сеансов, а также установку паузы между запросами.
Для оценки нагрузки на сервере расчета скидок включим сбор технологического журнала (ТЖ) по событиям «DBMSSQL, SDBL, CALL, SCALL». Для этого формируем файл logcfg.xml с содержимым:
<?xml version="1.0" encoding="UTF-8"?> <config xmlns="http://v8.1c.ru/v8/tech-log"> <log history="72" location="E:\Logs\FF_1909_3"> <event> <eq property="name" value="DBMSSQL"/> <eq property="p:processName" value="grimut_WhatYouWant"/> </event> <event> <eq property="name" value="SDBL"/> <eq property="p:processName" value="grimut_WhatYouWant"/> </event> <event> <eq property="name" value="CALL"/> <eq property="p:processName" value="grimut_WhatYouWant"/> </event> <event> <eq property="name" value="SCALL"/> <eq property="p:processName" value="grimut_WhatYouWant"/> </event> <property name="all"/> </log> <plansql/> </config>
Для получения данных о состоянии «железа» сервера настроим счетчики производительности в Performance Monitor:
После выполнения подготовительных шагов запускаем сбор счетчиков, ТЖ, а также утилиту, эмулирующую нагрузку на 10 минут и отправку запроса на расчет скидок каждую секунду. Понятно, что ежесекундная нагрузка, скорее всего, выше, чем будет в реальности. Параметры большой сети предполагали около 400 кассовых узлов, 50 фоновых потоков на сервере расчета скидок, с проходимостью в пиковые периоды 1 клиент в 3 минуты. Таким образом, предполагая равномерное распределение клиентов в эти 3 минуты, получаем удельный пинг (3*60)/(400 кассовых (узлов/50 фоновых потоков) = 22.5 секунды.
После проведения нагрузочной части эксперимента приступим к анализу технологического журнала. Для этого воспользуемся Cygwin, в котором выполним скрипт для получения 10 максимальных по длительности событий CALL и SDBL.
Пример скрипта:
egrep ",CALL," НаименованиеЛога.log | awk -F\- '{print $2}' | sort -rnb | head egrep "ВремяТранзакции,CALL," НаименованиеЛога.log | sort -rnb | head egrep ",SDBL," НаименованиеЛога.log | awk -F\- '{print $2}' | sort -rnb | head egrep "ВремяТранзакции,SDBL," НаименованиеЛога.log | sort -rnb | head
Анализируя данные по событию CALL, можно обратить внимание на данные по MemoryPeak, а точнее на то, что оно достигало 739188 Байт, что является довольно большим показателем. Особенно если учитывать, что посылаемые данные занимают на порядок меньше памяти.
Данные по счетчикам системы показали высокую загруженность процессора. В пиковые периоды он доходил до 98%. Работа дисковых накопителей была стабильной.
На основании полученных данных можно предположить, что при использовании способа обмена SOAP осуществляются дополнительные затраты на память. Проведем эксперимент повторно, только используя REST.
В качестве источника REST запросов будем использовать apache-jmeter-5.1.1. Для этого необходимо добавить группу потоков (thread group), в которой необходимо указать количество потоков (Number of Thread) и период (Ramp-up Period).
Затем указать параметры подключения к серверу.
Далее необходимо описать структуру передаваемых запросов, для этого необходимо добавить элементы HTTP Request.
После выполнения данных шагов можно запустить сбор счетчиков, ТЖ, а также apache-jmeter, эмулирующий нагрузку на 10 минут с отправкой запроса на расчет скидок каждую секунду.
После проведения эксперимента на вкладке Summary Report отображаются результаты эксперимента. Используя итоговый показатель колонки Average (средний показатель), можно получить итоговое время: 0.11*20 = 2.2 с., что является удовлетворительным результатом по сравнению с целевым временем эксперимента.
Анализируя данные ТЖ по событию CALL, можно обратить внимание на данные по MemoryPeak: здесь оно составляет 311348 Байт, что почти в 2 раза меньше, в отличии от результатов использования SOAP.
Данные счетчиков системы выявили аналогичную загрузку процессора. Однако процент пиковой нагрузки составлял 89%. Проблема работы с дисковыми накопителями также не была выявлена.
Результат
В данной статье были рассмотрены возможности блока дисконтного сервера на базе типового решения «1С:Фастфуд. Фронт-офис». Проведение нагрузочного тестирования блока с помощью различных инструментов позволило выявить недостаточную скорость работы при использовании обмена через SOAP. Однако использование REST запросов повысило скорость работы в 2 раза, а также снизило в 2 раза потребление памяти за вызов. Полученные результаты попали в целевое время.
Также данный вариант запросов был выбран основным при реализации блока дисконтного сервера на базе типового решения «1С:Фастфуд. Фронт-офис».
Для проведения нагрузочного тестирования были использованы такие инструменты, как конфигурация «1С:Тест-центр» из пакета «1С:Корпоративный инструментальный пакет», утилита собственной разработки на C#, а также свободно распространяемый Apache-JMeter.
От экспертов «1С-Рарус»
