Wireless2 777og:
1. Какая реальная нагрузка на ваш сервер - сколько запросов на авторизацию/минуту,
сколько accounting-запросов/минуту ?
2. Можете дать краткие характеристики самых тяжелых таблиц, к которым обращаются ваши SP в момент авторизации? Информация вида - размер на диске, число записей, число индексов, наличие триггеров и пр.


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

2. Из больших таблиц в аторизации учавствуют SessionLog (~600тыс. записей) - в основном выборка/обновление/вставка, user_totals (~160тыс.) - в основном выборка/обновление, таблица юзеров (~30тыс.) - в основном выборка. Деталей по поводу размера на диске, триггеров и индексов, честно говоря, не знаю. Выяснение деталей у нашего DBA имеет свои м-м-м, скажем так, свои сложности.

Даже глядя на эти цифры (пускай даже если их и умножить на 3) видно, что объёмы не очень серьёзные. И реального прироста производительности можно добиться, как правильно заметил Aion простыми вещами типа грамотной организации данных, индексов и т.п. Осталось в этом убедить нашего DBA :-)

AionВсем привет.

2 777og
Те данные, которые Вы тут привели (характуристики системы, железо и т.д.), наводит (точнее доводит) мои мысли до следующего:
- та техника, что у Вас имееться должна справляться с поставлеными задачами
- большие проблемы не толко в организации данных но и в их обработки


Согласен. Будем исправлять.

Aion
А вообщето неплохо бы посчитать стоимость одной единицы.
Т.е. сделать некий простой тест, который Вам даст результаты (сурогатные) типа: мах производительность, сколько нужно времени для обработки одной единицы (если с системой никто неработает, работают 10/100/1000 пользователей).
Это еще может Вам дать аргумент для админа, типа: "Вот видишь, наш Oracle обрабатывает 1 request в секунду!!! Если в системе будут 100 пользователей, то 100-й пользователь будет ждать антификации 40 секунд!!!!" :-))))


Вот по этому поводу я и думал. Хочется вокруг нашего биллинга построит систему мониторинга, отображающую качество обработки поступающих запросов. Я имею в виду следующее:
скорость обработки одного запроса (Dt) - время между приходом пакета на интерфейс и уходом пакета с ответом на пришедший запрос. Можно получить Dt_auth, Dt_start, Dt_stop. Dt_auth имеет смысл разбить на Dt_accept и Dt_reject, т.к. Reject пакеты имеет смысл задерживать (увеличивать Dt_reject) намеренно для защиты от флуда пакетами н.п. с подбором пароля, а борьба за минимизацию Dt_accept для нас имеет очень важное значение :-) Аналогично с Dt_start и Dt_stop, они являются показателями качества алгоритмов обработки и настроек базы, с одной стороны, и позволяют правильно выбрать время для ретрансмита пакетов на серверах доступа с другой стороны.

количество поступивших на обработку пакетов (N_access, N_start, N_stop) - с этип понятно.

некую относительную характеристику (dt_accept, dt_start, dt_stop) - аналогичную первой, но учитывающую количество поступивших запросов.

Имеется в виду следующее: если к нам поступает 3 пакета в течение 3 минут (DT = 3 мин) с интервалом в 20 секунд, то даже на самом хилом железе и на криво настроенной базе мы их сможем обработать с Dt_accept = 1сек. Если к нам за DT=3мин приходит 30 пакетов, то мы их можем обработать скажем за Dt_accept = 1,5сек, в случае 300 пакетов Dt_accept = 5сек. Поскольку DT=const, хилость_железа=const, то полученные Dt_accept(300) - Dt_accept(3) = 5 - 1 = 4 сек являются показателем неадаптированости алгоритмов обработки и настроек базы к данной нагрузке (чего нам собственно говоря и хочется узнать). Смотреть на график Dt_auth(t) и совмещать его с N_auth(t) неудобно, поэтому хочется относительную характеристику dt_accept(t) и аналогичные ей. Только я не могу придумать как её определить.


количество необработанных запросов (N_access_dropped, N_start_dropped, N_stop_dropped) - количество тех пакетов, на которые сервер вообще не ответил.

По полученным данным можно потом ещё строить гистограммы/распределения вида:
- количество обработанных запросов N за определённый Dt. В идеале эти распределения должны иметь вид дельта-функций :-)
- Dt от количества запросов и т.п.

Может мне не стоит изобретать велосипед, и уже есть ряд ТТХ, характеризующих подобные системы? Где об этом можно почитать?

Мне это нужно для того, чтобы можно было определить эффективность тех или иных мероприятий по оптимизации биллинга и что бы можно было строить прогнозы на предмет того сколько ещё пользователей можно добавить без существенной потери в производительности и без апрейта железа.