Сегодня сделали с Дмитрий открытие. Что если в #Garana стоит фильтр по переменной, у которой значение All, а значений в фильтре штук 200-300, то графана делает фильтр не по

field =~ /.*/

а добавляет в фильтр регулярку на 200-300 полей:

field =~ /value1|value2|.../

И запрос может получиться таким большим, что #Influxdb скажет Bad Request.


Починили мы так: удалили этот фильтр с доски.

Продолжаю разбираться с Gatling. Получается, он частично ведёт себя как браузер? Грузит файлы, которые явно не прописаны в коде симуляции

Может, если так прописано в объекте http protocol

> At the protocol level, you can use inferHtmlResources methods, so Gatling will automatically parse HTML to find embedded resources and load them asynchronously.

Ага, понял. Спасибо

Custom All  в настройках переменной прописать .*

Тоже с этим сталкивался

у меня тут на собесе задали вопрос: если QPS(the query-per-second rate низкий, то что это означает и как показатель увеличить? а я ток про TPS знаю)) какой ответ нужно было дать?)

Это все одно и тоже, только сущности разные

Query, transaction, request

как я понЯла это конкретно про query к дб. ответить почему квери в дб работают медленно? о_О

Как это часто бывает, возможно, хотели не столько конкретный ответ, а посмотреть как Вы рассуждаете

Размеры кэшей, планы запросов, диски...

..., сами запросы тяжёлые, таблицы большие и не партиционированные, без индексов. Причин может быть много

я написала больше про tps хД и про медленные query. большое кол-во данных в таблицах. про индекс забыла

еще вопрос: ищем baseline для api. GET user/info by user-user. выключаете ли вы кэгирование при этом? или генерите 100 юзеров и переиспользуете не смотря на кеширование или создаете 49000 юзеро в ДБ чтобы 20thread 20мин уникальных запросов выдержать? ><

Использую существующих пользователей/генерирую нужное количество для теста

т.е. создать 49000 юзеров это обычное дело? я думала спрсить у девов как кэш для этого апи выкл и дергать одним юзеорм...

Всего 49000)

Не совсем понял ситуацию... Кеширование - часть системы и её тюнинг прямо афектит перформанс. Выключить кеширование на тестовой среде когда на пром оно включено накладывает дополнительные ограничения на результаты теста и сложности интерпретации. Если мощностей генераторов нагрузки не хватает, то можно предварительно исследовать импакт кэширования и построить профиль без него. А нагенерить 100500 пользователей в бд кажется по сравнению с этим вобще элементарной задачей

Надо посмотреть как кешируется, например, если позволяет система, можно к каждому запросу добавлять рандомный параметр и обойтись небольшим числом пользователей