Эмулировать задержки БД

типа WANem

И почему его нельзя использовать в данном случае? Для приложения как бы без разницы чем вызвана задержка. Но можно и свой tcp прокси на коленке накатать и задерживать ответ.

Сервис на жаве (ЯП не важен) обращается к базе, а не по HTTP. И даже в этом случае пришлось бы разруливать маршрутами кого кидать на прокси, а кого напрямую.

Ну если совсем не хочется искусственных ожиданий (почему?), то организуй поиск строки по файлам разного размера. От 1MB до 1TB :)

обращается к базе

Через астрал? Или таки через tcp.

Постгря через UNIX Socket умеет, в таком случае TCP вообще мимо.

Но вот тестить задержки, юзая сокет-онли — это как-то… странно.

1. Есть - tc

не хочется искусственных ожиданий (почему?)

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

К сожалению мне это ни о чем не говорит и гуглить по двум символам тоже не вышло. Можно расшифровку?

https://en.wikipedia.org/wiki/Tc_%28Linux%29

tc qdisc add dev eth0 root netem delay 1000ms 50ms

Ок, им можно резать трафик и латентность с сетевого интерфейса. Как мне разделить трафик к другим микросервисам и к базе, чтобы тестировать только задержки к базе? Если бэк в кубере, мне придется на разные поды разные интерфейсы назначать?

Постгря через UNIX Socket умеет, в таком случае TCP вообще мимо.

Ну умеет и что?

https://habr.com/ru/company/flant/blog/672902/

Если в кубах, можно как-то так попробовать.

Всмысле в коде? В тестах? А для чего тесты еще нужны? Рандомные задержки таймером да и все.

докер все делает через cgroups, года 3 назад я нечто подобное делал, но сейчас чутка приболел и едва соображаю из за температуры, если за пару дней решение не найдешь, то я скину своё, копай в сторону cgroups + tc или tc + network namespace

Честно говоря, я ОП не читал. ☺

Я так, мимокрокодил.

https://github.com/Shopify/toxiproxy

такое?

тупо железку потестировать - pgbench и аналоги.
в контексте того что могут предоставить сервисы и насколько кривые запросы в сервисах/организация схемы/индексов - тестируй пиковую нагрузку на сервисы, смотри [не]справлятся ли база на текущем обородувании. делай выводы. в процессе смотри top slow query, их explain plan, io, как генерятся wal и успевают ли они на реплику, использования буферов, нужен ли partitioning и т.д. и т.п.

Ты не понял. Речь не про нагрузочное тестирование или поиск медленных запросов, а про функциональное тестирование основного кода в условиях разной латентности базы. Например одна часть кода или сервис пишет данные, другой читает. И тут реплика с чтением переехала на новый кластер и стала отвечать быстрее, чем реплика с записью, а разработчик этого не предусмотрел. А когда это в разных сервисах и написано разными людьми еще и давно, лучше застрелиться чем такое дебажить.

Самый простой способ - настроить в nftables/iptables drop 95% пакетов, к примеру.

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

пишут и читают в разные реплики? тут ещё время на синхронизацию реплик надо учитывать.

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

так отвечает же ж.
кафку не пробовали использовать для межсервисного взаимодействия?
чет то что Вы описываете выглядит как жесткое легаси и тюнинг таймингов sleep();
обидеть не хотел, прост так понял с Ваших слов.

у нас кафка для аналитики больше, а рабочая инфа в базе

тут ещё время на синхронизацию реплик надо учитывать.

хорошее замечание

так отвечает же ж.

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

метод записи отработал успешно, метод чтения ожидает что будет значение по id

Это называется синхронной репликацией, не? SET LOCAL synchronous_commit?

а задержка реплики плавала настолько, что вываливался NPE

может реплика тупит при применение полученых wal, логи смотрели?

задержка реплики плавала настолько

она как-то мониторится?
тут можно попробовать, на свой страх и риск, streaming replication sync/async - смотря что важнее, данные или время отклика.

NPE, который нельзя было поймать в тестовом окружении (ибо там нет реплик)

это как? т.е. в проде(среде) завели реплику, разделили r w между мастером и стендбаем, не тестируя?

может реплика тупит

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

в проде(среде) завели реплику, разделили r w между мастером и стендбаем

нет, в проде r и w разнесены, а на тестинге все в куче, поэтому такие приколы только в проде проверить можно, вот я и думаю как до греха не доводить

Для HTTP я использовал прокси, моки и подобные инструменты типа WANem, хочется для базы такое же.

Так в чём проблема?

Внедрять в коде искусственные ожидания еще хуже.

С чего это вдруг? Подход ровно такой же. Мокаешь соединение к базе данных, и добавляешь там задержку - можешь локально делать sleep, можешь в запросы инжектить. Или берёшь прокси (готовый, или проще выглядит написать свой тупой прокси на уровне сокетов из 20 строк) и добавляешь в нём задержки как тебе надо.

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

Это сарказм, если что. Бери композ, поднимай в нем постгрес (если надо можно даже сварм и поднять на другой тачке) и не парь себе мозг