ПО Set Retail

Привет. Хочу вам рассказать, как мы шли по дороге понимания производительности нашей системы Set Retail 10. А именно, как мы учились измерять производительность, и какими способами отслеживали ее изменения.

Для тестирования мы построили стенд производительности, и теперь на несколько дней запускаем на нём нагрузочные тесты. На этапе проработки тестового стенда мы сломали много копий о щиты ожесточённых споров. Но нам удалось найти ответы на самые главные вопросы — что и как делать, и в какой последовательности. Буду рад, если наш опыт станет полезен и вам.

Несколько слов о сервере Set 10. Это Enterprise Java-приложение на 500 бинов, которые разбиты примерно на 100 модулей. Каждый из бинов более или менее связан с остальными. Эта небольшая армия (точнее, батальон) бинов обслуживает 20-30 потоков данных. Логически они не зависят друг от друга, однако, так как все крутится на одной машине, когда начинает литься поток данных это сказывается и на остальных процессах. Я бы сравнил эту систему с котлом где “варятся” бины, и который может “переварить” все, что в него кинут.

До недавнего времени вопросы производительности сервера Set 10 решались «набегами». Мы смотрели места, которые с нашей точки зрения работали не совсем оптимально. Для таких мест писались разовые скрипты, нагружающие эти места и как-то показывающие их «проходимость». Далее выполнялись работы по оптимизации таких «проблемных мест», и снова запускались скрипты «нагрузи и померь». По результатам смотрелась разница, делались выводы, насколько увеличилась скорость в этом месте. Потом докладывали начальству, все радовались, но на один вопрос мы никак не могли ответить (а нам его часто задавали): «ОК, вы вот это оптимизировали, и что это дало в целом системе? Насколько она стала быстрее работать?»

Так продолжалось бы и дальше, однако нам потребовалось выработать систематический подход к вопросу производительности. Толчком для этого стала необходимость выдвинуть системные требования для железа, на котором будет крутиться наша сложная система. А сложность тут кроется в том, что модулей много, и потоков данных много. Каждый пользователь системы может использовать одни модули и не использовать другие. К примеру, один клиент может пользоваться внешней системой лояльности, и это никак не будет нагружать большую часть модулей нашего сервера, а другой будет использовать ее активно, имея миллионы клиентских карт и активно выдавать им бонусы, купоны, подарки и т.д.

Один клиент может генерировать по 1 чеку в полчаса с 300 касс, а другой может вести активную торговлю скоростью чек в минуту на каждой из 20 касс. Получается, что одна и та же версия такой «сложной системы» может иметь разные требования у разных клиентов. Вот тут-то и пришло понимание, что система «набегов» не помогает решить эту задачу. Мы не можем выставить требования для всей системы в целом. Нужно знать, какая конфигурация у клиента, и это первая зависимость, которую мы обнаружили.

Запрограммировав такую функцию в виде кода/скрипта/стенда — мы получим мощный инструмент, который поможет нам ответить на все поставленные перед нами вопросы. Но обо всем по порядку.

F(x): что это за функция и от каких переменных она считается?
Эта функция считает, насколько «хорошо» работает наша сложная система. Не вдаваясь в реализацию, сразу можно сказать, что она зависит как минимум от железа (на быстрых машинках система будет работать лучше, чем на медленных), конфигурации сложной системы (то, о чем я уже говорил выше, кто-то использует одни модули, кто-то другие), версии кода (с выпуском новых версий системы, ее производительность может увеличиваться, или наоборот уменьшаться). Тут можно придумать еще что-то специфичное для вас, но в нашей компании мы договорились, что эти параметры хорошо отражают зависимости производительности. Итого получилась функция от 3-х переменных.

Если мы сможем реализовать эту функцию программно, то мы как раз и получим наш стенд тестирования производительности, который сможет по конфигурации выдать подходящее железо, а на основе железа, сказать, на какую конфигурацию системы можно рассчитывать. Помимо прочего, на таком стенде можно будет (зафиксировав железо и конфигурацию) мерить производительности от версии к версии, а если зафиксировать железо и версию, то можно выделять параметры внутри конфигурации, которые более чем другие влияют на производительность.

Пропускная способность – выше, прибыль – больше, покупатели – лояльнее.

В решении уже заложены готовые самые популярные инструменты для коммуникации с покупателями: скидочные механики, бонусные программы и купонинг. Система лояльности работает офлайн. В каждом обновлении системы— новые маркетинговые доработки бесплатно.

Заложенные в решение механики позволяют разгрузить занятость персонала. Встроенная система уценки товаров с истекающим сроком годности — понизть объём списаний. Компактные чеки и слипы, алгоритмы округления суммы чека — сэкономить миллионы в год.

Масштабируемость и развитие.

Программное ядро решения Set Retail разработано для использования на всех типах кассового оборудования: клавиатурных кассах, сенсорных моноблоках, мобильных терминалов и касс самообслуживания.

Управление оборудованием, рабочими процессами и системой лояльности происходит централизованно. Один сервисный инженер способен обновить торговую сеть за 2 дня.

Транспортная шина данных позволяет гарантированно доставить справочники на кассы и выгрузить данные о продажах в торговых сетях любого масштаба. Решение построено на технологии горизонтального масштабирования в кластере и не станет слабым звеном в IT-инфраструктуре при развитии торговой сети.

Модуль Set SLS позволит клиентам запустить высоконагруженные, сложные и масштабные проекты лояльности. Сервис позволит учесть миллионы пользователей и предоставлять им более миллиарда персональных акционных предложений в год. Сервис работает 24/7 в отказоустойчивом режиме.

Кассовый сервер

Минимальные системные требования

Кассовая программа

Рекомендованные системные требования

Стоимость и сроки доставки

Бесплатная доставка осуществляется только до грузового терминала ТК СДЭК, если клиент находится в городе, где нет пункта самовывоза ТК СДЭК, до бесплатно доставляем до ближайшего терминала данной компании (СДЭК). Сроки по данной доставке устанавливаются согласно тарифам ТК и на усмотрение отправителя.

Срочного тарифа и адресной доставки, в услуге «Бесплатная доставка» нет.

Бесплатной доставкой можно воспользоваться только при заказе ККТ с полным комплектом услуг (касса под ключ). При данном условии, бесплатно доставляется только касса.

Если клиент покупает ККТ с полным комплектом услуг + другой товар (весы, денежный ящик, счетчик банкнот, принтер этикеток, 10 коробок чековой ленты и т.д), то бесплатно доставляем только ККТ, доставку на все остальное клиент оплачивает отдельно.

Условия бесплатной доставки по Москве и МО Ваш заказ доставляет курьерская служба:

Бесплатной доставкой можно воспользоваться только при заказе ККТ с полным комплектом услуг (касса под ключ)! При данном условии, бесплатно доставляется только касса.

Бесплатная доставка осуществляется по Москве на следующий день после её оформления. По МО (до 25 км от МКАД) — 1-2 дня. В день планируемой доставки Вам необходимо ответить на звонок курьера, иначе он будет вынужден перенести доставку на следующий день.

Если Вы находитесь более чем 25 км от МКАД, то доставку осуществляет ТК CDEK до ближайшего к Вам пункта выдачи данной компании, согласно параметрам для данного направления (сроки сообщаются логистом при оформлении заказа на доставку).

Выбор ТК, по условиям бесплатной доставки, производится на усмотрение отправителя.

Конфигурация

Из 3-х параметров нашей функции производительности только конфигурация вызывает вопросы. Действительно, запуская один и тот же тест на разном оборудовании, мы получим разные значения функции производительности, это понятно и не вызывает особых вопросов. С версией тоже проблем нет — запуская тест на разных версиях, мы так же имеем свободную размерность и можем её менять, как хотим. Но с конфигурацией у нас были большие вопросы. К примеру, какие параметры должны входить в конфигурацию? Как их комбинировать? Кто их должен формулировать — программисты или бизнес? Что в конкретном случае мерить?

Комплексная система для автоматизации торговых и бизнес процессов

Кассовая программа Set Retail понятна каждому кассиру, вне зависимости от опыта его работы. Благодаря удобному интерфейсу программы человек сможет освоить ее буквально за считанные минуты.

Управление операционным днем: чеки, смены и банковские транзакции. Контроль кассовой линейки и доставка данных в ERP.

Управление рекламными акциями, купонинг, бонусная программа. 168 готовых механик из коробки. Постоянное внедрение нового функционала.

Полноценный многофункциональный редактор ценников и этикеток. Готовые шаблоны , уже настроенные типовые принтеры для печати этикеток, регулярных и ценников для акции всех цветов, размеров и вариантов.

Готовая интеграция с весами самых популярных моделей. Поддержка акционных цен. Автоматическая очистка памяти весов от товаров с закончившимся сроком цены.

Срочные задачи на кассе решаются через telegram-бот без личного присутствия администратора. Персонал будет проинформирован о важных событиях, например, очередях.

Решение для высоконагруженного обмена данными между системами хранения данных ритейлера и решением Set Retail.

Единое решение для любого оборудования.

Система Set Retail доступна на различных видах касс: с сенсорным дисплеем, на клавиатурной кассе или в решениях для самообслуживания. Использование нескольких вариантов устройств в одном магазине не будет преградой: сотрудник может самостоятельно выбрать необходимый интерфейс в зависимости от типа его кассы.

Соответствует самым высоким ожиданиям

1. JMeter — система нагрузочного тестирования. Очень специфичный инструмент. Изначально разрабатывался для нагрузки WEB-приложений, и это чувствуется. Достаточно сложно реализовать произвольный тест производительности, чтобы потоки нагрузки создавались в определенном месте теста, чтобы был этап ПРЕ-теста и ПОСТ-теста. Много проблем с визуализацией результатов теста (встроены некоторые графики и можно генерить картинки по ним, но все равно генерация общей страницы предполагается делать за пределами JMeter). В общем, написать свой алгоритм теста проще оказалось на Java, чем разбираться с многообразием нодов JMeter и их последовательностью и ограничениями.
2. Zabbix — система мониторинга. Умеет запускать скрипты и мониторить любые метрики. Рассматривалась возможность логику теста зашить в скрипты (не очень хотелось так делать) или вынести в Java. Огромный плюс zabbix’a — он уже умеет мониторить основные параметры системы и можно легко дописывать свои параметры для мониторинга. Плюс есть наглядные графики. Но мы нашли еще более простое решение.
3. Glances — система мониторинга. Позволяет мониторить основные параметры удаленной машины. Легко устанавливается, запускается в виде сервера и имеет API по HTTP/Json. Все очень просто и удобно.

В итоге, логику теста мы реализовали на Java, мониторинг работает на glances, небольшой веб-сервис умеет запускать тесты и показывать их результаты (html, js), для графиков использовали chartJS

Единое ядро для всех видов касс

Простой и удобный интерфейс, мгновенный отклик кассовой программы, готовый сценарий общения кассира с покупателем. Результат использования: пропускная способность кассовой линейки увеличивается в разы и отсутствуют очереди в торговом объекте.

Отсутствие клавиатуры и люминесцентного дисплея покупателя; интерфейс, как на смартфоне; возможность транслировать рекламу на большом дополнительном дисплее.

Поддержка крупнейших мировых производителей касс самообслуживания. Готовая интеграция. Никаких затрат на настройку. Собственное решение для самообслуживания.

Покупатели самостоятельно сканируют и упаковывают товар. Оплата происходит без участия кассира. Для реализации решения требуется минимальное количество консультантов.

После долгих споров мы пришли к следующим выводам

1. Разработчики составляют список факторов внутри системы, влияющих на производительность (т.к. разработчики более осведомлены в этом вопросе). Каждый такой фактор должен быть понятен для всех разработчиков и бизнеса, должна быть возможность его нагрузить и померить. Список факторов должен быть отсортирован в порядке влияния на производительность по мнению разработчиков (реальные тесты могут подтвердить или опровергнуть это предположение).

2. Далее бизнес выставляет требование к каждому фактору по списку. Требование не должно зависеть ни от других частей системы, ни от железа, ни от прочих факторов. Эти требования мы еще использовали для выставления количественной оценки: требование выполнено — 100%, требование выполнено наполовину — 50% и т.д.

3. Так как система работает на одной машине, то нельзя их проверять по очереди (все по очереди они могут работать быстро, но все вместе у реального заказчика — тормозить), поэтому нагружать нужно все и сразу.