Настройка радиуса будет касаться данных строк:

 max_request_time = 9
 cleanup_delay = 10
 max_requests = 2097152
 
 ...
 
 thread pool {
   start_servers = 1
   max_servers = 128
   min_spare_servers = 8
   max_spare_servers = 32
   max_requests_per_server = 3000
   max_queue_size = 1048576
   auto_limit_acct = no
}

Рассмотрим эти параметры:
max_request_time
Максимально время за которое ядро биллинга должно обработать запрос и вернуть результат

cleanup_delay
После получения результата, радиус будет хранить этот "результат" у себя в памяти на случай если результат не дойдет до BRAS сервера и BRAS заново отправит запрос.

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

start_servers
Минимальное кол-во возможных потоков для обработки запросов авторизации

max_servers
Максимальное кол-во потоков для обработки запросов авторизации

min_spare_servers
Минимальное кол-во потоков которое может находится в состоянии "ожидания"

max_spare_servers
Максимальное кол-во потоков которое может находится в состоянии "ожидания"

max_requests_per_server
Максимальное кол-во запросов которое может обработать один поток, после чего он будет перезапущен ( 0 - без ограничения )

max_queue_size
Размер очереди для запросов авторизации (1048576 это максимальное значение, при таком значении радиус потербляет на ~1Gb больше памяти)

auto_limit_acct
Ограничение accounting запросов



Теперь посмотрим на изображение ниже

У радиуса есть “очередь” куда он помещает все запросы. Размер этой очереди определяет параметр max_queue_size.
Если очередь будет переполнена, то любые новые запросы будут отклонены в silent режиме (то есть без каких либо уведомлений в логи).

Как и написано в документации радиуса, переполнение очереди возможно при медленной обработке запросов и при резком скачке запросов авторизации.
Обработкой запросов в очереди занимаются “рабочие потоки”, задача которых:

• взять запрос из очереди
• отправить его на ядро биллинга (через модуль perl)
• дождаться ответа.

После чего цикл повторяется. Соответственно чем больше потоков тем лучше.

Для начала посмотрим на это изображение, на нем показано как работают параметры start_servers, max_servers, min_spare_servers, max_spare_servers

При минимальной нагрузке будет создано 8 потоков (min_spare_servers), по мере нагрузки они могут увеличиться максимум до 32 потоков (max_servers).
Если нагрузка начнет уменьшаться то количество потоков будет уменьшено до 24 (max_spare_servers).
Если нагрузка не достигла 24 потоков (max_spare_servers), то уменьшать кол-во потоков радиус не будет.

1 поток способен обработать до 20-25 запросов в секунду (тесты ниже).
ядро билинга автоматически создает дочерний процесс под каждый поток радиуса, по этому на каждом радиус сервере нужно высчитывать примерное кол-во запросов.

К примеру при 4000 онлайна значения будут:
4000 онлайна разделяем на 20 (столько в среднем может обработать ядро билинга за 1 секунду) умноженное на 9 (максимальное время для авторизации).
4000 / (20*9) = 22
В итоге получаем число 22, примерно столько нужно потоков что бы обработать все 4000 запросов за отведенное время
Так как max_servers не может быть меньше max_spare_servers, то max_servers можно сделать немного больше чем max_spare_servers.
В итоге получаем значения:

• max_spare_servers = 22
• max_servers = 32

Конфигурация сервера на котором проводились тесты

• Дата выпуска: Q1 2012
• CPU: 2х Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz
• Cores: x16
• RAM: DDR3 16gb
• SSD: SAMSUNG MZ7KM480HAHP-0E005

Параметры теста

• Radperf: 200 потоков
• Кол-во запросов авторизации: 10000

Посмотрим график производительности модуля mbcore

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

В данных тестах мы прогоняли от 1000 до 1.000.000 запросов авторизации

Параметры теста #2

• Radperf: 128 потоков
• Радиус: 128 потоков
• RAM: DDR3 16gb

Посмотрим график производительности модуля mbcore

Как видно на графике удалось разогнать packets/s до 2954, на 1.000.000 было замечено падение производительности.

Параметры теста #1

• Radperf: 256 потоков
• Радиус: 256 потоков
• RAM: DDR3 32gb

Как видно на графике удалось разогнать packets/s до 4583, на 1.000.000 было замечено падение производительности и более высокая нагрузка на MySQL.

Это разъяснение о важности иметь максимально низкие тайминги обмена данными между ядром биллинга и MySQL. В последнее время все чаще стали сталкиваться с конфигурациями где mysql вынесли на отдельный сервер, что как бы очень даже верное решение, но одновременно с этим не позаботились о хорошей связи с данным сервером, в итоге задержки при отправке данных на такой сервер составляли 10-30 ms что хоть и кажется не существенным но давайте рассмотрим это чуть подробнее.

Итак, мы знаем что один поток ядра способен обработать ~20 запросов в секунду (тесты выше), в данных тестах все находилось на одном сервере и обмен данными ядра биллинга с MySQL производился с минимальными задержками по сокетам (<0.001 ms). Но что если между ядром и MySQL будет задержка в 20 ms ? В теории один запрос авторизации выполняется за 1000/20 = 50 ms, если к этим 50 ms добавить 20 ms от задержки связи, то 1 запрос будет выполнятся уже 70 ms а это в свою очередь снижает производительность ядра до 14 запросов в секунду. И это при условии что ядро делает только 1 запрос к базе, а так как ядро делает 3 запроса минимум (а в среднем около 10-15) то эти 20 ms спокойно превращаются в 60-300 дополнительных ms к обработке запроса, в итоге производительность ядра может упасть чуть ли не к 3-9 запросам авторизации в секунду.

Логика в настройке радиуса проста: больше потоков ⇒ больше производительность, но не стоит забывать что каждый поток потребляет ресурсы сервера и если "заиграться" и выставить слишком большое кол-во потоков то можно добиться обратного эффекта снизив производительность.