/dev/null хотя бы..

Вот, вот это дырочка!!!

Хороша Су***ща

Ребята привет, нагрузил сервис и получил следующие результаты (скрин):
сейчас в профиле из 19 запросов по 4м наблюдается деградация времени ответов, по остальным метрикам все хорошо, нигде нет превышения пороговых значений, кроме CPU на сервере 90-100% (его сжирает редис изза плохого кода).
Изза деградации времени ответов не происходит увеличение РПС с каждой ступенью.
По сути тест уперся в необходимость оптимизации кода и возможно редиса.

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

В сам редис - хз конечно, но в говнокод с редисом - это да, особенно при записи чтении😅

Зачем? Ты нашел максимум... Покажи проекту

Подумайте над этим вместе

Я бы пушил "исправление говнокода"

а сколько там ядер на серваке то?

А тусить дальше смысла мало, т.к. дальше много будет искажения, и после первой оптимизации - картина вполне себе может измениться достаточно сильно... К примеру ты можешь упереться в другой ресурс

/stat@combot

8 core cpu 16 GB RAM

а в курсе что редис юзает только одно ядро?

А это разве не конфигом решается? 😳

гыы

Звучит как настройка

он не умеет лол

хотите много ядер - берите кейдб