Comments 10
Подготовка тестовых данных, для систем со множеством интеграционных взаимодействий, не тривиальная задача и ввиду ее большой трудоемкости зачастую пренебрегают точностью профиля и/или консистентностью данных относительно промышленной БД.
Каким образом вам удалось подготовить тестовые данные для тестирования «в реальных условиях эксплуатации»?
Каким образом вам удалось подготовить тестовые данные для тестирования «в реальных условиях эксплуатации»?
Если правильно понял вопрос, то речь о подготовке данных с точки зрения объемного тестирования.
Для того, чтобы организовать данные для тестовой среды нагрузочного тестирования мы:
1) Полностью мигрировали справочные данные из актуальной боевой инфраструктры
2) Выполнили миграцию данных за период двух месяцев и применили их мультиплексирование за счет созданных скриптов, которые фактически берут реальные данные и версионируют их.
Поэтому фактически статическая выборка, тем самым, была приближена к реальным условиям по составу, а инструменты п.2 позволили анализировать изменения, происходящие с системой в режиме накопления данных.
Профиль нагрузки, т.е фактические сценарии использования их количество и интенсивность,
распределения по ролям, мы получали за счет системы мониторинга реальной боевой среды.
Для того, чтобы организовать данные для тестовой среды нагрузочного тестирования мы:
1) Полностью мигрировали справочные данные из актуальной боевой инфраструктры
2) Выполнили миграцию данных за период двух месяцев и применили их мультиплексирование за счет созданных скриптов, которые фактически берут реальные данные и версионируют их.
Поэтому фактически статическая выборка, тем самым, была приближена к реальным условиям по составу, а инструменты п.2 позволили анализировать изменения, происходящие с системой в режиме накопления данных.
Профиль нагрузки, т.е фактические сценарии использования их количество и интенсивность,
распределения по ролям, мы получали за счет системы мониторинга реальной боевой среды.
А если не секрет, то какие мощности были потрачены на эмуляцию клиентских запросов? И как они осуществлялись? По опыту на это надо потратить тоже немало ресурсов.
авторизация пользователя в системе — 400 мс— это много или мало? И про остальные цифры тот же вопрос.
Как повлияли манипуляции с софтом и железом на эти цифры?
Спасибо за вопрос. Я считаю так: если бизнес-пользователь не испытывает каких либо проблем (времена совпадают или опережают его ожидания ), то это очень неплохой результат. Исходя из этого, можно сказать что к данным цифрам стоит относиться позитивно.
С другой стороны, стоит задать вопрос: какой ценой дались эти времена? И здесь ответ однозначен: на оборудовании хуавей можем вот так. С технической точки зрения уверен, что есть ещё возможность улучшить данные цифры.
С другой стороны, стоит задать вопрос: какой ценой дались эти времена? И здесь ответ однозначен: на оборудовании хуавей можем вот так. С технической точки зрения уверен, что есть ещё возможность улучшить данные цифры.
можете про сам стек приложения рассказать?
микросервисы или монолит?
про cl/cd, monitoring?
микросервисы или монолит?
про cl/cd, monitoring?
Про стек технологий используемых для построения системы можно было бы написать отдельную статью если будет интересно. Сама система — это совокупность сервисов, объединённая общей шиной событий на основе Apache ActiveMQ Artemis. Ряд сервисов действительно микросервисы (сервис шрихкодирования, сервис конвертации в pdf, сервис проверки эп и тд). Но основной сервис бизнес логики это многослойный пирог объединяющий прикладную функциональность. С точки зрения сервиса бизнес логики мы выдерживаем компромисс между трудоемкостью сопровождения и развития. Слои сервиса бизнес логики состоит из слоя restapi, слоя доменной логики, слоя документоориентированных коннекторов к хранилищу и платформы AF5. Для большинства сервисов используем Spring Framework. Для различных клиентов: GWT, Angular, также есть нативные для iOS и Android. Поисковый движок Apache Solr. Субд соответсвенно PostgreSQL Все сервисы контейниризируются. Для автоматизации сборок Jenkins и maven, контроль качества автотесты на selenium, юнит тесты, интеграционные тесты и метрики через Sonar Cube.
объем файлов-вложений: 1 Тб в год;
Данные приложения консолидировали на… 117 SSD по 3,6 ТБ каждый, общий полезный объем — более 300 ТБ.
Зачем вам так много места? Процесс согласований — это по сути просто текст. Там нужно хранить — кто когда и что нажал, что написал, это все — максимум сотня килобайт на документ.
Прикрепляемые документы- всего 1 ТБ в год. Даже если вы закачаете в него всю историю за 10 лет, у вас останется ещё грубо 290 ТБ.
Конечно, есть ещё мета-информация — описания файлов, поиск по ключевым словам, но не настолько во много больше же, чем у вас самих документов?
Метрика объем файлов вложений\в год не учитывает общую потребность в подсистеме хранения. СХД для системы используется монопольно. Это позволяет решить вопросы тюнинга и конкуренции с прочими системами Банка. Помимо исторического набора данных с вложениями которых сейчас порядка 25 ТБ, мы имеем накладные расходы на поисковые индексы, на сервисы архивного хранения протоколов аудита и прочих, интеграционные сервисы и микросервисы системы. Т.е общая потребность в подсистеме хранения на текущий момент порядка 100 ТБ, а также заложены объемы на развитие.
Sign up to leave a comment.
Не нагрузишь — не протестируешь: как мы выявляли проблемы с системой документооборота ВТБ