Оптимальный способ получения данных о пользователе

[dummy 8]

Появился вопрос: каким образом быстрей (эффективней) получить данные о пользователе в скрипте OnConnect (тариф, UserData ....)

Можно через sgconf, можно - напрямую с базы

Что посоветуете ?

[nightfly 1 239]

SELECT `field` from `users` where `login`='....'

[madf 279]

XML RPC

[nightfly 1 239]

Суперечить релігії, "працює - не чіпай зайвий раз"

[Kucher2 122]

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

[dummy 8]

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

я все понимаю, вопрос в том, какой метод самый быстрый ?

[nightfly 1 239]

Очевидно же - прямое получение данных в обход любых прослоек. Это правило относиться ко многим вещам в жизни.

[madf 279]

Очевидно же - прямое получение данных в обход любых прослоек. Это правило относиться ко многим вещам в жизни.

Реальность немного сложнее. Прямой доступ к данным статистики позволит быстрее получить данные, но это будут не актуальные, а устаревшие данные.

А так - да, прямой доступ к базе.

[nightfly 1 239]

Только в случае получения статы по трафику, все остальное типа тарифов, бабла, итп итд пишется же моментально сколько помню?

 

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

[madf 279]

Только в случае получения статы по трафику, все остальное типа тарифов, бабла, итп итд пишется же моментально сколько помню?

...

Бабло и free mb тоже не пишутся моментально.

[kvant-v 0]

Мой OnConnect используeт для получения данных sgconf

На 5 юзеров всё было ОК.

После увеличения числа юзеров always online до семи первые два при запуске не могли получить данные грешил на модуль mysql

поставил костыль в виде циклического перезапроса данных в случае не удачи, временно проблема решилась.

Сейчас при достижении кол-ва юзеров always online 60 проблема появилась снова и выглядит так :

 

при бесконечном цикле перезапроса данных в случае не удачи - сервер зависает судя по логам на старте модуля

"Always Online autorizator v.1.0" точнее зависает наверно скрипт OnConnect, а сервер очевидно ждёт завершения его работы.

 

Если ограничиваю цикл перезапроса данных в случае не удачи пятью попытками - сервер задерживается на старте модуля "Always Online autorizator v.1.0",

в это время скрипт OnConnect отрабатывает не удачно (так и не получив данных) для 6 первых юзеров делая по 5 попыток + sleep 2 на каждого,

затем старт всех модулей старгейзера судя по логам завершается и все остальные "юзеры" стартуют нормально.

 

Затем я обратил внимание на то что модуль "Stg configurator v.0.08" вообще всегда стартует последним !

Т.е. запуск юзеров always online всегда начинается в момент когда модуль "Stg configurator v.0.08" ещё не запущен !!!

И в этот момент действительно никак нельзя получить данные через sgconf

По моей логике это вобще не могло работать, но ведь работало на пять юзеров вообще проблем не замечал ! Как ?!

 

Предполагаю что в варианте на 5 юзеров они не запускались при старте модуля "Always Online autorizator v.1.0", а только добавлялись в очередь, а запускались все уже после старта всех модулей.

Ну а в варианте на 60 юзеров очередь наверно переполняется.

Подскажите пожалуйста правильно ли я тут всё понимаю ?

 

И если правильно то можно ли как-то заставить модуль "Stg configurator v.0.08" запускаться раньше чем модуль "Always Online autorizator v.1.0"

Или без переделки скриптов на прямое обращение к базе мне не обойтись ?

 

И ещё я добавил в windows конфигуратор возможность отображения в таблице полей userdata и при старте скрипт OnConnect заносит туда опять-же через

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

Если я сделаю прямую запись в базу в поля userdata, увижу ли я эти данные в конфигураторе сразу и вобще можно ли так делать ?

 

 

Ос: OpenSuse 11.4

stg v. 2.407-p1

mysql

пробовал вместо mysql firebird не помогло , даже показалось что было хуже.

[Roman Pogosyan 3]

Немного поковыряв код , все эти данные можно передать сктипру OnConnect на прямую. Тут была тема в которой я приводил пример. думаю это самый быстрый и неглючный метод

[nightfly 1 239]

Подскажите пожалуйста правильно ли я тут всё понимаю ?

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

 

Или без переделки скриптов на прямое обращение к базе мне не обойтись ?

- Доктор я буду жить?

- Будете но очень фигово и не долго.

 

Получение всего что угодно из базы делается ровно в три с половиной строчки и ликвидирует все ваши доморощенные проблемы скажем до 20 кило юзеров.

 

Если я сделаю прямую запись в базу в поля userdata, увижу ли я эти данные в конфигураторе сразу и вобще можно ли так делать ?

Нет - это не будет работать, stargazer читает табличку users только при старте, после чего помнит ее мозгами и периодически перезаписывает. Зачем хранить какие-то штуки (после чего их же и перезаписывать через некислую прослойку sgconf->conf_sg->stargazer->store_mysq ) в табличке users - честно, понять не могу.

 

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

[kvant-v 0]

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

Удобно видеть параметры динамического шейпера в GUI конфигураторе напротив каждого юзера ну вобщем как раз в старгейзере.

Эти параметры могут меняться каждую минуту в зависимости от активности юзера.

Благодаря Вам я теперь знаю, что другого способа, кроме как через "прослойки" их там отобразить нет, а городить только ради этого отделный веб интерфейс как-то не охота.

Да и ошибки установки шейпера пока скрипты не отладил бывало появлялись, очень оперативно было видеть их в таблице,

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

Немного поковыряв код , все эти данные можно передать сктипру OnConnect на прямую. Тут была тема в которой я приводил пример. думаю это самый быстрый и неглючный метод

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

Вобщем уже попользовавшись sgconf, мне никак не хочется расставаться с его универсальностью и простотой использования.

К тому-же sgconf отлично по русски задокументирован.

 

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

Помоему с этим нужно что-то делать и я решил попробовать.

Раз я хоть что-то правильно понял, шанс на успех думаю есть. Мой опыт c++ под linux == 0 ,так что не судите строго

Целый день и почти всю ночь я вёл не равный бой с исходниками с переменным успехом

Пишу к Вам, товрищи, из последних сил глаза уже в кучу.

Есть первые результаты завтра просплюсь убедюсь что это не миражи и поделюсь.

Відредаговано 2012-01-22 00:57:33 kvant-v

[madf 279]

projects/stargazer/plugins/configuration/sgconfig/stgconfig.cpp, строка 243. Заменить 220 на 10. Аналогичную замену провести в строке 248.

Таким макаром вы заставите стартовать плагин конфигуратора раньше плагинов авторизации (у них 70 и 50).

[madf 279]

Среди тикетов есть один по реализации ручного управления тем, какие параметры будут передаваться в скрипты On*, как это реализовано для rscriptd. Выполнить его не сложно, но в 2.408 это не попадет.

[kvant-v 0]

Это то-что надо !

projects/stargazer/plugins/configuration/sgconfig/stgconfig.cpp, строка 243. Заменить 220 на 10. Аналогичную замену провести в строке 248.

Таким макаром вы заставите стартовать плагин конфигуратора раньше плагинов авторизации (у них 70 и 50).

 

Madf, спасибо огромное ! Я бы месяц это искал, даже не думал, что последовательность пуска модулей внутри их самих.

У меня вчера мозгов хватило только на то, чтобы поменять местами в main.cpp строки modules.sort(StartModCmp) и modules.sort(StopModCmp) что привело к полной обратной последовательности пуска-останова доп. модулей и могло иметь плохие последствия.

 

Но мой кривой способ всё-же позволил мне вчера провести эксперимент который я повторил сегодня уже в нормальном варианте:

И так напомню, проблемы с получением данных через gconf в OnConnect начинались с увеличением числа юзеров always online до 7.

и решались костылём в виде повторных запросов в случае не удачи с записью в лог, и записи эти были при каждом пуске,

с числом юзеров 60 костыль уже не помогал система стабильно уходила в бесконечный цикл запросов. В скрипте использовался

один запрос sgconf get с шестнадцатью ключами параметров. И один запрос sgconf set который по условию пчти никогда не вызывался.

[nightfly 1 239]

Эти параметры могут меняться каждую минуту в зависимости от активности юзера.

Ну и? Пусть себе меняются. Старгейзеру то какая разница?

У меня как-то динамическое шейпление же работает успешно, не трогая старгейзера в принципе.

 

а городить только ради этого отделный веб интерфейс как-то не охота

не вижу причинно-следственной связи

 

Вобщем уже попользовавшись sgconf, мне никак не хочется расставаться с его универсальностью и простотой использования.

ждем следующего поста на тему "ой, сотня юзеров и все погибло" =)

[kvant-v 0]

Не успел вчера дописать самое интересное.

 

После того как удалось изменить порядок запуска старт прошёл быстро и без единого сбоя,

тогда я для краш теста скопировал запрос sgconf get 10 раз и снова пуск без единого сбоя,

Мой костыль впервые оказался не задействованным при запуске.

Такое кол-во запросов было эквивалентно запуску 600 юзеров моей системы.

 

Тогда я решил проверить как будут обстоять дела с записью параметров sgconf set

Добавил один запрос sgconf set с двумя ключами - и получил зависание уже на втором юзере !

Убрал 9 лишних запросов sgconf get оставив 1, снова зависение на втором юзере.

Стал изучать висящие процессы всё стопорилось как раз на sgconf set

И тут я вспомнил что sgconf set отличается от gconf get тем, что при его отработке должен отрабатывать скрипт OnChange и возможно так-же через общую очередь выполнения скриптов но в висящих процессах его небыло, тогда я воткнул в скрипт OnChange команду echo записывающую в лог старгейзера момент отработки, и к удивлению не обнаружил в логе ни одного запуска этого скрипта, только два пуска OnConnect на втором из которых всё зависло.

дальше была серия бесполезных экспериментов в ходе которых я случайно удалил скрипт OnChange и вдруг всё стартовало без единого сбоя !!!

Правда в логе запуска по каждому юзеру сообщалось что не обнаружен исполняемый файл OnChange.

Я подумал что где то в скрипте ошибка, вернул его на место и полностью опусташил.

И снова висяк на втором юзере ,тут я был в тупике .

 

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

 

Через час до меня дошло ! OnChange ни разу не отработал, но возможно встал в конец очереди на выполние, и sgconf set висит возможно потому

что безуспешно пытается поставить в переполненную очередь очередной скрипт OnChange ,

 

а в случае когда скрипт OnChange вобще отсутствовал то и в очередь его никто ставить не пытался и всё работало.

 

Длинну очереди как собстно и её реализацию в исходниках пока не нашёл но экспериментально знаю что она около 60 скриптов.

и в данном случае заполнить её под завязку мог только модуль "Always Online autorizator v.1.0"

 

и заполнил он её скорее всего из за того, что скорость заполнения значительно превышает скорость выполнения скриптов с включёнными в них sgconf

 

запросами.

 

Решения тут два похоже.

Первое простое и не эффективное: я вставил паузу в 0,4 секунды в цикл включения юзеров и в цикл их отключения в модуль "Always Online autorizatorv.1.0"

Всё работает на ура ! и на запись и на чтение, что подтверждает что я на верном пути.

 

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

 

вот код двух функций ao.cpp со вставленной паузой вставка выделена так: //////////////

 

//-----------------------------------------------------------------------------

void AUTH_AO::UpdateUserAuthorization(USER_PTR u) const

{

if (u->GetProperty().alwaysOnline)

{

USER_IPS ips = u->GetProperty().ips;

if (ips.OnlyOneIP())

{

if (u->Authorize(ips[0].ip, 0xFFffFFff, this) == 0)

{

//////////////////////////////////////////////////////

struct timespec ts = {0, 400000000};

nanosleep(&ts, NULL);

//////////////////////////////////////////////////////

}

}

}

}

//-----------------------------------------------------------------------------

 

//-----------------------------------------------------------------------------

int AUTH_AO::Stop()

{

printfd(__FILE__, "AUTH_AO::Stop()n");

if (!isRunning)

return 0;

 

users->DelNotifierUserAdd(&onAddUserNotifier);

users->DelNotifierUserDel(&onDelUserNotifier);

 

list<USER_PTR>::iterator users_iter;

users_iter = usersList.begin();

while (users_iter != usersList.end())

{

Unauthorize(*users_iter);

UnSetUserNotifiers(*users_iter);

++users_iter;

//////////////////////////////////////////////////////

struct timespec ts = {0, 400000000};

nanosleep(&ts, NULL);

//////////////////////////////////////////////////////

}

isRunning = false;

return 0;

}

//-----------------------------------------------------------------------------

 

 

Второе решение сложное и эффективное: "научить" "Always Online autorizator v.1.0" отслеживать состояние очереди выполнения скриптов,

и приостанавливать включение юзеров Always Online когда в очереди уже есть 5-6 скриптов, в этом случае для скриптов OnChange всегда будет место в очереди и на быстродействие "легких" скриптов читающих данные напрямую из базы это не должно повлиять.

 

Но только второе решение я наверно не осилю хотя попытаюсь конечно если поможете.

 

И у меня по этому поводу вопросы:

Ткните меня пожалуйста где реализована очередь, в упор не вижу но знаю что где-то есть.

 

Ну и может быть к ней уже есть доступ из выше описанных функций,

хотя наверно нет.

предполагаю, что нужно сделать функцию в том модуле где эта очередь находится

функция должна возвращать значение int заполненности очереди

Паузу уменьшить раз в 50 и поместить внутрь цикла с вызовом этой функции

цикл должен повторяться пока очередь не освободится до 5 скриптов.

 

Жду вашего мнения по поводу выше описанного алгоритма.

 

Среди тикетов есть один по реализации ручного управления тем, какие параметры будут передаваться в скрипты On*, как это реализовано для rscriptd. Выполнить его не сложно, но в 2.408 это не попадет.

Думаю если допилим работу sgconf до стабильного состояния всё это будет лишним

Ну, а это, надеюсь, в будущих версиях будет идти по умолчанию ?

stgconfig.cpp, строка 243. Заменить 220 на 10. Аналогичную замену провести в строке 248.

Таким макаром вы заставите стартовать плагин конфигуратора раньше плагинов авторизации (у них 70 и 50).

Эти параметры могут меняться каждую минуту в зависимости от активности юзера.

Ну и? Пусть себе меняются. Старгейзеру то какая разница?

 

Старгейзеру действительно никакой, и ему помоему нет дела до большинства параметров хранимых в его базе данных и отображаемых на экране его конфигуратора, они отображаются старгейзером для пользователя в данном случае для меня. Именно этой универсальностью мне он и нравится, он может отображать фильтровать оперативно обновлять и сортировать на экране любые параметры какие я ему поручу, даже те до которых ему нет дела но я хочу их видеть. И помоему ничего лишнего я от него не требую когда пытаюсь заставить sgconf работать в скриптах, а иначе зачем sgconf тогда вобще был создан и задокументирован.

 

Ну а для чего мне видеть в данном случае текущие параметры шейпера то вот пример, звонит мне Вася Пупкин и предьявляет почему у него скорость интернета периодически падает я одним взглядом на экран сразу знаю что ему ответить, и если Вася грубанул с трафиком и шейпер снизил ему приоритет то я ему так и скажу, а если шейпер его не обижал, значит пора мне искать причину у себя.

(забыл пояснить, старгейзером я раздаю интернет в офисе)

Ну можно конечно всё в лог валить, а потом через трёх конвеерный grep всё там искать, но я как-то не очень дружу с консолью, вобщем у всех свои методы.

ждем следующего поста на тему "ой, сотня юзеров и все погибло" =)

Если в моём офисе будет сотня юзеров то первым погибну я

[Небесный 26]

Во блин... Впервые про такие грабли слышу, может поискать бы в другом месте нежели рыскать в исходниках?

Так не бывает, что у одного грабли, у других их нету.

Может в скриптах (OnConnect ... и т.д.) тонны кода?

Но, лично мое мнение, что лезть в исходники - это уже крайний метод. Другое дело, если бы это наблюдалось у всех.

[madf 279]

...

И тут я вспомнил что sgconf set отличается от gconf get тем, что при его отработке должен отрабатывать скрипт OnChange и возможно так-же через общую очередь выполнения скриптов но в висящих процессах его небыло, тогда я воткнул в скрипт OnChange команду echo записывающую в лог старгейзера момент отработки, и к удивлению не обнаружил в логе ни одного запуска этого скрипта, только два пуска OnConnect на втором из которых всё зависло.

дальше была серия бесполезных экспериментов в ходе которых я случайно удалил скрипт OnChange и вдруг всё стартовало без единого сбоя !!!

Правда в логе запуска по каждому юзеру сообщалось что не обнаружен исполняемый файл OnChange.

Я подумал что где то в скрипте ошибка, вернул его на место и полностью опусташил.

И снова висяк на втором юзере ,тут я был в тупике .

 

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

 

Через час до меня дошло ! OnChange ни разу не отработал, но возможно встал в конец очереди на выполние, и sgconf set висит возможно потому

что безуспешно пытается поставить в переполненную очередь очередной скрипт OnChange ,

 

а в случае когда скрипт OnChange вобще отсутствовал то и в очередь его никто ставить не пытался и всё работало.

Правильный вывод.

 

...

 

Второе решение сложное и эффективное: "научить" "Always Online autorizator v.1.0" отслеживать состояние очереди выполнения скриптов,

и приостанавливать включение юзеров Always Online когда в очереди уже есть 5-6 скриптов, в этом случае для скриптов OnChange всегда будет место в очереди и на быстродействие "легких" скриптов читающих данные напрямую из базы это не должно повлиять.

 

Но только второе решение я наверно не осилю хотя попытаюсь конечно если поможете.

 

И у меня по этому поводу вопросы:

Ткните меня пожалуйста где реализована очередь, в упор не вижу но знаю что где-то есть.

Эта очередь реализована гдето в ядре ОС - это часть механизма IPC.

 

Ну и может быть к ней уже есть доступ из выше описанных функций,

хотя наверно нет.

предполагаю, что нужно сделать функцию в том модуле где эта очередь находится

функция должна возвращать значение int заполненности очереди

Паузу уменьшить раз в 50 и поместить внутрь цикла с вызовом этой функции

цикл должен повторяться пока очередь не освободится до 5 скриптов.

 

Жду вашего мнения по поводу выше описанного алгоритма.

Можно проверять состояние очереди с помощью msgctl, по в случае если она переполнена все равно не получится ничего сделать. Запрос на выполнение скрипта нужно поставить в очередь, но сделать это невозможно, по этому нить блокируется, что и вызывает описанные выше эффекты. Нужно либо научитья управлять размером очереди, либо добавить промежуточный кольцевой буфер между stargazer core и script executer и управлять уже его размером. Суть решения проста - очередь должна быть достаточно велика чтобы вмещать в себя все запросы авторизации always online и запросы на изменение параметров из скриптов. Смущает только тот факт что целиком она будет использовать только при старте системы, а в процессе нормальной работы весь этот объем памяти будет пустовать. В случае более тысячи абонентов с always online размер будет немалым.

В принципе, при желании, можно попробовать динамически изменять размер очереди.

 

Среди тикетов есть один по реализации ручного управления тем, какие параметры будут передаваться в скрипты On*, как это реализовано для rscriptd. Выполнить его не сложно, но в 2.408 это не попадет.

Думаю если допилим работу sgconf до стабильного состояния всё это будет лишним

Это будет нелишним, т.к. избавит от сотен fork/exec в момент запуска и кучи сетевого взаимодействия. Так получать информацию намного эффективнее. Но это не избавит от необходимости изменять значения параметров через sgconf set.

 

Ну, а это, надеюсь, в будущих версиях будет идти по умолчанию ?

stgconfig.cpp, строка 243. Заменить 220 на 10. Аналогичную замену провести в строке 248.

Таким макаром вы заставите стартовать плагин конфигуратора раньше плагинов авторизации (у них 70 и 50).

Не вижу смысла. Разве что вынести эти значения в настройки плагинов в качестве не обязательных параметров.

[madf 279]

Во блин... Впервые про такие грабли слышу, может поискать бы в другом месте нежели рыскать в исходниках?

Так не бывает, что у одного грабли, у других их нету.

Может в скриптах (OnConnect ... и т.д.) тонны кода?

Но, лично мое мнение, что лезть в исходники - это уже крайний метод. Другое дело, если бы это наблюдалось у всех.

Я вот, например, всегда лезу в исходники при граблях

[nightfly 1 239]

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

Ухты, моя попытка донести мысль - увенчалась успехом.

 

Теперь попытаюсь донести следующую. Всесто того чтобы извращаться пытаясь изменить тонкую биохимию старгейзера,вы могли бы осознать, что проблема записи сквозь него не актуальна, в данном контексте. Проблема с отображением? Значит нужно модифицировать отображающую часть - тобишь виндовый конфигуратор (чур меня, чур) в вашем случае. Думаю довесить в него ровно 1(!) SELECT xxx from yyy будет менее травматично и трудоемко.

 

Если в моём офисе будет сотня юзеров то первым погибну я

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

 

Поверьте - проще и еффективнее единоразово осознать что не нужно трогать нормально работающий stargazer руками, после чего не иметь никаких проблем вообще. Учитывая вашу самоцель просто показывать какую-то цифрень для какого-то логина из базы ("...звонит мне Вася Пупкин и предьявляет...") все таки сводится к одному коннекту-запросу-дисконнекту, что самоочевидно проще и перспективнее.

[kvant-v 0]

Так не бывает, что у одного грабли, у других их нету.

А помоему на этом форуме оч. много сообщений о граблях, ноги у которых на самом деле как раз из модуля "always online" растут.

Например сообщения о том, что старгейзер глючит от больших скриптов.

И мой опыт показал, что добиться нормального выполнения "больших скриптов" вполне реально.

 

Может в скриптах (OnConnect ... и т.д.) тонны кода?

Конечно код там присутствует и он делает "тонны" полезной для меня работы.

И если код скриптов без ошибок то какие причины для отказа его выполнения ?

Помоему максимум плохого что должно быть от больших скриптов это снижение быстродействия.

 

Вопрос к Madf: приемущества от смены порядка запуска модулей помоему очевидны - мы получаем возможность использовать gconf get

Раз вы не видите смысла значит есть и минусы - какие ?

[nightfly 1 239]

А помоему на этом форуме оч. много сообщений о граблях, ноги у которых на самом деле как раз из модуля "always online" растут.

Более 5-ти лет использования, юзеров - достаточно, все всегда AO. Грабель не замечал. Старгейзер руками не трогаем - религия такая.

 

 

Может в скриптах (OnConnect ... и т.д.) тонны кода?

Небесный, ты ж отлично сам знаешь, что у меня за содомия твориться в онконнектах и его обвесах. Опять же просто нужно идти по пути наименшего сопротивления и как показывает практика все будет хорошо

 

Помоему максимум плохого что должно быть от больших скриптов это снижение быстродействия.

либо недовыполнение по таймауту, ухудшение аппетита и общего самочувствия.