Думаю структуру модулей тестов еще поменяю. Пока что содрал с rebar3_proper но когда начал пробовать писать бенчмарки к разным библиотечкам оказалось что не очень удобно

Если вдруг будут какие-то отзывы/пожелания - пиши

а что у неё с паралельностью?

если бекенд побенчмаркать например, можно ли?

Если вопрос мне, то ничего

да, тебе =) я просто в своё время по этой причине basho_bench брал чтобы параллельный доступ был, думал может ты прикрутил что-то

Имеешь в виду load test? Не, я больше как микробенчмарк целился

да нет, не лоад тестинг. ну скажем захочешь ты погонять тесты на твоём маленьком kv

или нифка с шаренным стейтом

блин сижу сейчас и думаю, тоже чтоль conquerror помучить. надо лок-сервер свой тестировать, но писать пропер тесты чот прям очень не хочется. черпаю вдохновение в https://github.com/emqx/canal-lock/blob/master/test/canal_lock_steps.erl кто-нибудь подобное делал?

хз, такое не пробовал. Там есть setup / teardown и функция которую бенчмаркаем которая будет сотни раз вызываться. Можно наверное в init запустить пул процессов а в цикле заставлять их делать запросы. Но боюсь выйдет не очень стабильно. Если там большой разброс во времени выполнения каждой итерации то статистика уже ненадёжная

^ ответ про бенчмарк, не concuerror

В basho_bench там вроде у них несколько другой алгоритм: там тест гоняется до тех пор пока не накопится достаточно статистики чтобы отклонения от среднего не выходили за границы нужного интервала. Это может быстро произойти, а может и никогда. У меня наоборот - строгое ограничение по времени и в конце просто выводим среднее и погрешности. Если погрешности слишком высокие, то кидает warning что бенчмарк нестабильный и статистически нельзя доказать что какой-то из двух вариантов алгоритма лучше или хуже

я делал как с ограничением по времени, так и ограничению по количеству операций, пришлось немного похачить правда

но да, я понимаю что либа изначально совсем для другого

Всем привет. Коллеги скажите, как и чем вы профилируете erlang приложения?

io:format с меткой времени можно, если по простому. Или то же самое но в syslog отдельный выделенный для трассировки .

это, извините, не профилирование, а колхоз...

Да колхоз, зато всегда под руками. Метку времени до вызова функции , метку после. Метрики нужные можно собирать на реально работающем коде.

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