RabbitMQ C # Клиент Масштабируемый?

Question

Глядя на официальный код клиента .net, в нескольких местах я видел утверждения Лока.Это вызвало внутренний вопрос о том, насколько это влияет на производительность.

Мое текущее решение - это веб-приложение, которое использует graylog для ведения журнала, а его приемник - очередь кроликов.Один запрос критического пути может привести только к нескольким десяткам журналов, и в идеале он должен работать на 500 мс.В пиковые моменты мы ожидаем обрабатывать 3-5 таких запросов и 1-2 сотни других каждую секунду.

Прямо сейчас, соединение и модель в основном одиночные, и мой вопрос: насколько должен волноватьсяя о тех замках, когда мы попали в тяжелый груз?Есть ли какие-нибудь тупики?

Answer 1

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

Краткий ответ: 50 нс

Таким образом, фактический вопрос: какая часть на самом деле заблокирована и имеет ли это значение?

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

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