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

Распределение времени ответа, при нагрузочном тестировании

performance
Теги: #<Tag:0x00007f7b64fbe550>

(Александр Шиповалов) #1

Коллеги, добрый день. Поставили передо мной довольно таки странную задачу. Занимаюсь сейчас нагрузочным тестированием. Есть довольно таки несложное приложение (Apache, PHP, Drupal, MySQL). Делаю нагрузку с помощью Jmeter и счастлив. Но возникла проблема в другом. Это приложение (назовем его веб мордой), дергает через PHP Bridge, уже другое приложение на Java - которое крутится на Apache -Сoyote (я так мыслю, что это Tomcat). И вот возник резонный вопрос - если “веб-морда” отвечает за 30 секунд, то сколько из них уходит на получение ответа от Java приложения. Команда разработки удаленная (индусы), просто так я к ним обратиться не могу. Попробовал перехватывать траффик через Wireshark, но там я не могу коррелировать результаты с тестами Jmeter. Может быть кто нибудь оказывался в такой ситуации или у кого то были мысли по поводу такого черного ящика в тестировании.


(Sergey Ivanskoy) #2

Здравствуйте. Пока первое что приходит в голову - это то, что веб-морда общается с бэкендом посредством некоего API. Можно попробовать отследить трафик, который уходит из вебморды, и посмотреть какие и куда запросы она формирует на тех страницах, к которым вы обращаетесь. И уже с помощью JMeter нагрузить именно APIшку, а не вебморду. Так вы по крайней мере сможете исключить фронтенд из своих замеров.


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

Столько написал, но постановку задачи не написал. Как задача формулируется? Зачем тебе вообще знать какие там приложения вызываются? Какова цель тестирования?


(Александр Шиповалов) #4

Цель тестирования одна - выяснить, что “тормозит” сильнее всего. Фронтенд или бекэнд.


(Александр Шиповалов) #5

Именно это я и пытаюсь сделать с помощью Wireshark, но пока не очень успешно.


(Sergey Ivanskoy) #6

@alshipovalov

Я, к сожалению, не очень знаком с wireshark. Скажите, пожалуйста, почему был выбран именно он и в чем заключается проблема отслеживания трафика?


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

Какая-то странная отмазка. И поэтому ты решил попросить “помощь зала” для игры в угадайку?

Ты пытаешься решать задачу, которая вообще говоря не только твоя. Ну то есть ты не сможешь её решить в одного никак. Твоя роль здесь - обнаружить проблему, а не найти решение. Этот процесс итерационный в случае нагрузочного тестирования: постепенно углубляясь, продвигаешься от симптомов к причине проблемы.

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


(Sergey Ivanskoy) #8

безусловно это так. Максимум, что вы сможете на этом этапе таким способом - это возможно определить какая именно из глобальнейших частей приложения является bottleneck’ом - фронт или бэк. Бессмысленно без дальнейшего продвижения к причинам и решению проблемы. Если этого все же достаточно, то похоже на проблему менеджмента, который может играть “в мячик”, т.е. нужно просто определить на кого повесить проблему, а без результатов в какой именно части системы тормоза, никто не хочет ею заниматься и каждый отсылает (читай посылают :smile: ) друг к другу. Здесь судить конечно не могу, ибо ваша команда и вам лучше знать что и как, так что извините, если перегнул с выводами :slight_smile:

и не решите.

опять же, похоже на проблему менеджмента в работе с распределенной командой, ибо решение проблемы производительности - это ну уж никак “не просто так”.


(Александр Шиповалов) #9

Я и не думаю это оспаривать. Я и сам понимаю, что задача мягко говоря - очень странная…Но…хоть немного глобально копнуть - мне надо.


(Александр Шиповалов) #10

Первое, что выдал гугл - для перехвата трафика. Fidller, я пока не уверен, что смог встроить в приложение.


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

Fiddler и Whireshark работают с сетевыми протоколами. Если же у тебя фронтенд и бэкенд общаются через вот такой PHP/Java Bridge, тут перехват сетевого трафика ничем не поможет.


(Александр Шиповалов) #12

Да похоже, через него и общаются? А есть какие то варианты, хоть что то расковырять? Иди без команды разработки - никак?


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

Профайлить надо на стороне бэкенда (JVM, Database), и надо знать что искать, куда смотреть, за что дергать. Ковырять конечно можно и без разработчиков (при наличии доступов, можно например профайлить JVM удаленно, используя visualvm или jconsole, для БД тоже есть инструменты), но если хочется именно решить задачу, эффективнее действовать через разработчиков. Так и твое обучение будет идти эффективнее и задача решится быстрее


(YobiByte) #14

Господа,

мне давали нечто подобное в качестве задачи (выяснить, кто виноват, front-end или back-end). Решил я её просто - заставил их написать, что и когда они делают пошагово, время и набор данных.

Решение: повторяю их шаги и выясняю просто в фронт-энде в FireBug (для браузеров на основе Chromium - Developer Tools) временную составляющую и смотрю, как долго реагирует фронт-энд на клики, которые я делаю. Далее - смотрю скорость ответа от бек-энда.

ЗЫ: Вот так всё просто только у меня?
:smile:

ЗЗЫ: как только определились, на чьей стороне косяк, то - решение выполнено, согласно вот этому тексту:

ЗЗЗЫ: Если такое (торможение ответа на 30 секунд) только в случае большой нагрузки сервака, то - нагружаем сервак с помощью JMeter, выполняем действия пользователей и, опять же, смотрим в тайминге браузера или FireBug’a.


(Александр Шиповалов) #15

Тормозит всегда. Время ответа конечно коррелируется с количеством пользователей, но растет очень незначительно. Проблема, в том, что есть как бы два back-ends

  1. Drupal со своей базой данных
  2. Java приложение которое крутится на Apache Coyote и общается с 1-м с помощью PHP/Java Bridje