Что именно файлы graph_*.dat содержат в необработанных результатах LR

Я смог вывести следующее о столбцах:

ID TimeStamp  RespTim  TPS      A        B        C 
== ========== ======== ======== ======== ======== =========
40 xxxxxx7723 5.458429 0.800000 2.406426 8.481170 27.879561
40 xxxxxx7724 5.458429 0.800000 2.406426 8.481170 27.879561
40 xxxxxx7725 5.458429 0.800000 2.406426 8.481170 27.879561
40 xxxxxx7726 5.458429 0.800000 2.406426 8.481170 27.879561
40 xxxxxx7727 5.458429 0.800000 2.406426 8.481170 27.879561

40 xxxxxx7728 2.551755 0.400000 2.462352 2.641159 2.607780
40 xxxxxx7729 2.551755 0.400000 2.462352 2.641159 2.607780
40 xxxxxx7730 2.551755 0.400000 2.462352 2.641159 2.607780
40 xxxxxx7731 2.551755 0.400000 2.462352 2.641159 2.607780
40 xxxxxx7732 2.551755 0.400000 2.462352 2.641159 2.607780

ID          Transaction ID from sum_data.ini file
TimeStamp   UNIX Timestamp (UTC 0)
RespTime    Avg. Response for this period
TPS         Transactions per Seconds
A,B and C   These are unknown still

Обратите внимание, что первые 5 строк ИДЕНТИЧНЫ, за исключением отметки времени. Я считаю, что это связано с тем, как LR собирает данные за 5 секунд.

Значение TPS (0,8) указывает на то, что за эти 5 секунд фактически было совершено 4 транзакции. Их сред. время отклика составило 5,458429 секунд.

Чтобы проверить столбец TPS, я обнаружил, что если вы просуммируете все значения TPS для конкретной транзакции, вы получите количество ПРОШЕЛ, как показано на странице сводки!

Я определил, что A всегда меньше, чем B и C, но B может быть больше, чем C, обычно C намного больше, чем B. Я просто пока не вижу закономерности для них ... A - это минимальная транзакция. time и B — максимальное время транзакции, а «RespTime» — среднее время транзакции. Я еще не знаю, что означает C.

Во-первых, я не могу рекомендовать интерпретировать или иным образом зависеть от внутренних форматов данных Loadrunner. Я сделал это с WinRunner, и это совершенно не было долгосрочным или среднесрочным решением, поскольку они (HP/Ex-Mercury), похоже, меняют форматы по своему усмотрению, даже для небольших обновлений/SR/второстепенных выпусков.

Во-вторых, одна из цифр может быть «потерянным впустую» временем, т. е. суммой всех размышлений, которые были частью транзакции.

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

В-третьих, но это всего лишь предположение: я на 99% (ну, на 70%...) уверен, что в других случаях содержатся значения, которые собирает LR, чтобы он мог выполнить разбивку веб-запросов. (Когда вы интегрируете сценарии LR в Business Availability Center, у вас может быть разбивка графика для всех веб-запросов любой транзакции. Я не уверен, что сам LR использует эти значения в отчетах или что мы имеем. Однако вы можете подтвердите мою догадку, используя пустую транзакцию — компоненты времени простоя должны быть равны 0 (или равны общему времени отклика?), как и компонент времени обдумывания).

Хтс...