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

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

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

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

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

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

@alshipovalov

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

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

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

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

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

и не решите.

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

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

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

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

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

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

Господа,

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

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

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

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

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

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

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