Size: a a a

2020 March 31

SP

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

SP

Sergey Prokhorov in ErlangRus
Petr Kozorezov
интересно, спасибо! :)
Если вдруг будут какие-то отзывы/пожелания - пиши
источник

V

Vasilii Demidenok in ErlangRus
а что у неё с паралельностью?
источник

V

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

SP

Sergey Prokhorov in ErlangRus
Vasilii Demidenok
а что у неё с паралельностью?
Если вопрос мне, то ничего
источник

V

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

SP

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

V

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

V

Vasilii Demidenok in ErlangRus
или нифка с шаренным стейтом
источник

V

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

SP

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

SP

Sergey Prokhorov in ErlangRus
^ ответ про бенчмарк, не concuerror
источник

SP

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

V

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

V

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

s

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

D

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

ММ

Михаил Малюк in ErlangRus
Dim
io:format с меткой времени можно, если по простому. Или то же самое но в syslog отдельный выделенный для трассировки .
это, извините, не профилирование, а колхоз...
источник

D

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

ММ

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