abills.net.ua

Обсуждение

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

1 За последний год в системе появилось множество новых улучшений по функционалу. Эти улучшения привели к определенной «тормознутости» системы при больших нагрузках.

2 В ветке 0.4 будет ориентироваться на провайдеров с базой пользователей в 5000 - 10000 и с 500 -1000 онлайн пользователями.

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

4 Нагруженные таблицы будут разделены по периодам.

5 При radius авторизации система будет ориентироваться в основном на использование rlm_perl

~AsmodeuS~ писал(а):5 При radius авторизации система будет ориентироваться в основном на использование rlm_perl

Посмотрел описание по настройке rlm_perl . Чем это лучше/хуже чем сейчас? Стоит ли все новые инсталляции настраивать на rlm_perl?

в 5-7 раз более производительней

А можно ли rlm_perl пользоваться сейчас, есть какие-либо ограничения в текущей версии?

да можно

~AsmodeuS~ писал(а):1 За последний год в системе появилось множество новых улучшений по функционалу. Эти улучшения привели к определенной «тормознутости» системы при больших нагрузках.

2 В ветке 0.4 будет ориентироваться на провайдеров с базой пользователей в 5000 - 10000 и с 500 -1000 онлайн пользователями.

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

4 Нагруженные таблицы будут разделены по периодам.

5 При radius авторизации система будет ориентироваться в основном на использование rlm_perl

Да - пора отказыватся от ситуации когда по каждому чиху биллинг лезет в SQL. При просмотре исходников я увидел множество мест где можно заюзать такие вкусности как memcache например.

При загрузке сервера биллинга в районе 60% (атлон 5600+ х2) загрузка сервера базы (где и биллинг, и форум, и + старая биллинговая система - для тех, кто еще не перешел на VPN, и + куча мелочи) - несколько % (пик - до 5%, в среднем - около 1-1.5%. При онлайне 300 клиентов, интервал аккаунтинга - 60 секунд.
ИМХО в другую сторону нужно оптимизировать...

NiTr0, а как считаете где узкое место в машине для биллинга (цпу, диск, память)? Справилось бы это же железо с 3000 юзерами онлайн?

~AsmodeuS~ писал(а):да можно

а как насчёт потоков в перле? Не пора бы?

NiTr0 писал(а):При загрузке сервера биллинга в районе 60% (атлон 5600+ х2) загрузка сервера базы (где и биллинг, и форум, и + старая биллинговая система - для тех, кто еще не перешел на VPN, и + куча мелочи) - несколько % (пик - до 5%, в среднем - около 1-1.5%. При онлайне 300 клиентов, интервал аккаунтинга - 60 секунд.
ИМХО в другую сторону нужно оптимизировать...

во-во... в другую сторну... разнести это всё барахло на разные сервера... и надёжнее будет

chtito2 писал(а):NiTr0, а как считаете где узкое место в машине для биллинга (цпу, диск, память)? Справилось бы это же железо с 3000 юзерами онлайн?

Узкое место ИМХО проц либо связка проц-память. Хотя я не пытался юзать rlm_perl - сейчас все работает через rlm_exec (когда пытался запустить биллинг - при юзании rlm_perl скрипт сыпал ошибки, отложил до лучших времен).
3000 онлайн - сомнительно, разве что интервал аккаунтинга поставить 300 секунд...

ran писал(а):во-во... в другую сторну... разнести это всё барахло на разные сервера... и надёжнее будет

Согласен, очень неплохо было бы разнести собссно вебку и радиус-сервер (сервера)... Т.к. все остальное - уже разнесено Единственное, что этому мешает ИМХО - текстовые логи попыток соединения.

NiTr0 писал(а): Согласен, очень неплохо было бы разнести собссно вебку и радиус-сервер (сервера)... Т.к. все остальное - уже разнесено Единственное, что этому мешает ИМХО - текстовые логи попыток соединения.

Юзайте nfs.

Можно... но ИМХО логичнее было бы перенести и эти логи в БД. Или, как минимум, дублировать их в БД.