Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Нужен совет в нагрузочном тестировании серверов.


(Трепалин Артём) #1

Задача:
протестировать сервер приложений и сервер БД.
Условия:
Показать такие метрики как:

  1. Потребление ресурсов центрального процесса
  2. Потребление оперативной памяти
  3. Потребление сетевых ресурсов
  4. Время выполнения запроса

Использовать бесплатное ПО.

Исходников нет, запросы которые идут в БД с тонкого клиента вероятно вшиты в объекты, в хранимых процедурах они не хранятся. Удалось сделать более-менее верный апдейт, который идет на базу.

У каждого пользователя есть свой тонкий клиент.

Архитектура соединений: Рис.1

Вопрос: Чем и как можно это все протестировать? Понятно что БД можно протестировать Jmetrer’ом, а вот как нагрузить сервера, я что-то не могу понять.
Чем помочь можно: подсказать направление куда копать, каким инструментом можно воспользоваться, и может быть Jmeter умеет это все делать, только я не знаю об этом?

P.S. опыт только в тестировании веб-приложений.


(Maxim Karpenko) #2

Всё можно сделать с помощью Jmeter. Если есть возможность указать на клиенте прокси - то можно вообще записать сценарий в Jmeter и потом его воспроизвести с необходимой нагрузкой.
По части мотиторинга ресурсов (память, загрузка процессора) - есть плагин для Jmeter, который всё это собирает на стороне сервера - http://jmeter-plugins.org/wiki/PerfMon/


#3

Если тонкий клиент - не веб, то варианта 2.

  1. Раздобыть библиотеку, которую используют разработчики клиента для общения с сервером, и подключить к своему проекту. Если выделенной библиотеки нет, а вызовы разбросаны по коду клиента, то печаль.
  2. Поднимать N клиентов или виртуалок с ними, если это реально.

А для генерации нагрузки в первом случае можно использовал и JMeter, если проект на Java или позволяет сделать Java-обертку.


(Трепалин Артём) #4

Спасибо за плагин.


(Трепалин Артём) #5

реально поднять 10 клиентов, дальше нет ни финансов ни ресурсов.


(Александр Таранков) #6

Что из себя представляет сервер приложений? Почему с рабочего места общение с сервером приложений по ODBC?
JMeter вполне нормально работает по ODBC, не понятно пока в чём проблема.


(Трепалин Артём) #7

на сервере приложений стоит толстый клиент.
Для меня проблема заключается в том что нужно нагрузить не само приложение,а сервер. А как его без приложения и чем нагрузить - не знаю.

Почему с рабочего места общение с сервером по ODBC: сеть внутри предприятия.
Я слабо осведомлен почему именно так построена связь.


(Александр Таранков) #8

В чем смысл нагружать БД без нагрузки приложения? Время ответа приложения разве не надо учитывать? В чём цель такого тестирования, что за время ответа будет замеряться и для чего?

Насчет “чем нагрузить”. А что с тонких клиентов за запросы идут? Что из себя представляет тонкий клиент? Что это за сеть вообще?


(Трепалин Артём) #9
  1. Узнать сколько запросов выдержит сервер и время отклика БД.
  2. По хорошему надо, но нет даже Api приложения, и смоделировать нагрузку с учетом приложения пока не знаю как.
  3. В чем цель - заказчик хочет нагрузочное тестирование серверов, и сколько нагрузки выдержит толстый клиент(сервер приложения) и БД
  4. тонкий клиент представляет из себя декстоп приложение.
  5. Что за сеть - не знаю. Данных не предоставляют.

(Александр Таранков) #10

А что толстый клиент на БД отсылает можно вытащить? Общение тонкого клиента с толстым можно послушать например Fiddler-ом, может натолкнет на какие-то мысли


(Трепалин Артём) #11

Что толстый клиент шлет на БД - нет.
Пробовал трассировщиком вытащить что-то, но похоже запросы находятся в объектах, отчего трассировщик их не видит, в хранимых процедурах пусто. По наитию написал похожий апдейт, чтобы изменялись данные в БД и эти данные попадали в толстый клиент. А вот с инсертом это не помогло - в толстый клиент ничего не попадает. а в базе данные есть.


(Трепалин Артём) #12

Поправка:
Тонкий клиент - декстоп приложение, будет у рядовых пользователей.
Толстый клиент будет у админов, клиент который будет коннектиться напрямую к базе. Потребляет много ресурсов.
сервер приложения - службы, которые будут соединять тонкий клиент и БД. Под сервер приложения, будет выделен отдельный физический сервер.
Надо протестировать сервер приложений, т.е. сколько подключений, количество запросов от тонких клиентов он выдержит и непосредственно, уже, сколько коннектов выдержит и какую производительность покажет сервер БД.


(Александр Таранков) #13

А цель тестирования какая? Если исходников нет, что будете делать в случае неудовлетворительной производительности? Или настройки будете крутить?

Просто так “интересно” задача поставлена: исходников нет, как общаются компоненты приложения - неизвестно, но вот надо нагрузить во что бы то ни стало.


(Трепалин Артём) #14

Цель написана выше, если неудовлетворит, это уже не мои проблемы, скорее всего будут повышать ресурсы серверов:

Вендор тонкого клиента не дает исходники. А мне поставлена задача.


(Трепалин Артём) #15

по поводу общения компонентов: знаю то что протокол на транспортном уровне TCP/IP. по прикладной уровень пока не знаю. Как общаются, отвечу как дилентант: от тонкого клиента идет запрос, служба его обрабатывает, и потом на основании этого запроса пуляется запрос в БД. и так же обратно.


(Александр Таранков) #16

А с вендором связь есть? Может у него спросить что он посоветует?

По сути тебе надо понимать как тонкий клиент общается с сервером приложений и в этой точке создавать нагрузку. Не зная протокола общения, это будет не тестирование, а непойми что: вот ты один запрос угадал, два угадал, а сколько их, какие из них создают нагрузку - не понятно.

Либо как вариант, запускать десктопный клиент во много сессий:

  1. можно ли его запустить из командной строки?
  2. можно ли ему на вход скормить какой-нть файл с операциями?
  3. можно ли заюзать dll-ку (или что там, jar?) и программным способом несколько потоков сделать?

(Трепалин Артём) #17

а проснифать трафик между тонким клиентом и сервером приложений, не вариант?


(Александр Таранков) #18

Тоже вариант, конечно, я уже говорил про Fiddler


#19

Не факт, что Fiddler поможет, т.к. само приложение должно быть настроено, чтобы воспринимать его как прокси.
Для перехвата траффика “as is” можно попробовать WireShark, но можно не разобраться в протоколе, особенно если он бинарный. Нужна или спецификация протокола, или клиентский код.


(Трепалин Артём) #20

Удалось проснифать трафик, и вопрос дилентанта, можно ли это быстро засунуть в Jmeter? Или только ручками?