zgrep -c "Event"  log_file.gz

 xD

Обычно ситуация такая.

Лог пишется на 100 МБайт, потом жмется в gz. Поэтому есть, как жатые, так и текстовые логи. Придумал способ про zcat и cat.

Текстовые лучше читать после сжатых. Так как они записываются позже. Так ниже шанс упустить событие.

А как лучше сделать?

Вопрос про logback. В актуальной версии настройка flush log по умолчанию = true. Таким образом, каждая строка пишется в лог сразу, буфер записи не используется.

В log4j по умолчанию была асинхронная запись. Через накопление буфера. Это ведь создаёт меньшую нагрузку на диск и систему в целом. Но есть риск потерять буфер, при падении приложения.

Обращаете ли вы на это внимание? Настраиваете ли logback на асинхронную работу?

я написал, одна команда вместо трех -

zgrep -c "Event"  log_file.gz

У меня вопрос к знатокам

У меня в тесте очень много разноплановых запросов - полная имитация действий пользователя с кредитом на первой стадии. В итоге вот такая вот картина

Насколько это хорошо/плохо. Либо нужно много однотипных запросов

У меня просто в тз так  было 1) симитировать приход контрактов (кредитов в ситему) одним post запросом 2) симитировать работу пользователя с кредитом на 200 пользователей

И я теперь переживаю, может, я не так сделала

Я не знаток, но точно соответствие модели нагрузки не свангуешь по такой картинке... 😅

Если ты считаешь, что профиль соответствует требованиям, объем(и сама модель в частности) нагрузки - требуемый.

То на картинке, почти настоящие времена отклика(как и в бою будут)...

Не понятно что тебя беспокоит, если у тебя не достает компетенции сказать - "мы хорошо поработали, сервис работает как надо под нагрузкой", нужно приобщить ещё кого-то с проекта:
1) Поиграй с группировкой метрик по разному(персентиль, медиана итд)
2) Нарисованные графики покажи аналитику(разрабу, заказчику или кто там компетентный в "ожиданиях"), подумайте в месте, выдерживает сла, или нужно ещё поработать с оптимизацией, или чем ещё.

Если я не понял вопроса - уточни, может подскажу

Может и не так, но чего переживать то, это опыт, это тесты - это результат. Так что в любом случае, это хорошо что ты что-то делаешь!

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

Спасибо за ответ.

Я пока не в состоянии хорошо анализировать графики. Мне бы "хоть как-то". Умные люди обещали разобраться

Аггрегированное время для всех запросов бесполезная метрика, для анализа нужны времена ответов для отдельных запросов, именно они будут нужны для анализа

Действия пользователя симетированы в сценарии, осталось подать нужное их количество (200 пользователей ). Кажется, что все вроде бы нормально

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