Сделайте это "настолько большим, насколько это разумно".Например, если вы согласны с тем, что он потребляет до 1 ГБ памяти, выделите его размер равным 1 ГБ, поделенному на среднее число байтов объектов в очереди.
Если мне нужно было выбрать "разумный номер, я бы начал с 10000.Причина в том, что если он вырастет до большего, то увеличение его не будет хорошей идеей и вряд ли поможет, потому что требования к ведению журнала явно опережают вашу способность регистрироваться, поэтому пришло время отказаться отклиенты.
«Настройка» с помощью экспериментов, как правило, является наилучшим подходом, поскольку зависит от профиля вашего приложения:
- Если в работе вашего приложения есть максимумы и минимумы, тобольшая очередь поможет «сгладить» нагрузку на ваш сервер.
- Если ваша прикладная программа имеет относительно устойчивую загрузку, тогда подходит меньшая очередь, так как большая очередь только задерживает неизбежную точку.когда клиенты заблокированы - вам лучше уменьшить его и выделить больше ресурсов (пару потоков журналирования) для выполнения работы.
Обратите также внимание, что очень большая очередь может повлиять на отзывчивость сборки мусора для освобождения памяти, поскольку при каждом запуске она должна обходить гораздо большую кучу (все объекты в очереди), увеличиваязагрузка как процессора, так и памяти.
Вы хотите сделать размер как можно меньшим, не оказывая слишком большого влияния на пропускную способность и скорость отклика.Чтобы оценить это, вам нужно настроить тестовый сервер и загрузить его с типичной нагрузкой, чтобы увидеть, что происходит.Обратите внимание, что вам, вероятно, понадобится подключить его к нескольким машинам, чтобы создать реалистичную нагрузку на сервер, поскольку попадание на него с одного компьютера может ограничить нагрузку из-за количества ядер ЦП и других ресурсов на тестовом клиентском компьютере.
Если честно, я бы просто сделал размер 10000 и настроил количество рабочих потоков, а не размер очереди.