Оптимизация при большом количестве юзеров ?

[martin 170]

Сколько юзеров может "стабильно" держать Старгазер последней версии ??

 

Сделал маленький тест - засунул в mysql базу 4000 юзеров, Старгазер их выгребал 8 минут (2.4 АМД 64бит(одно ядро)+1Гиг памяти), потом запустился и забрав 82МБ памяти работал.

Резонный вопрос - статистику обсчета он от первого до последнего юзера уже будет делать лроьше ведь ??

 

И еще вопрос - а зачем выгреб%#ь в ядро всю базу юзеров ??? Почему нельзя держать в памяти только тех кто сейчас находится в онлайне ?? тоесть при подключении юзера ядро забирает юзера из базы и обсчитывает его, при отключении юзера ядро освобождает юзера, естественно те кто АО постоянно в онлайне.

 

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

 

Вобщем мысли вслух на ночь глядя ))

[XoRe 0]

А при подключении инетаксеса от нового юзера каждый раз в БД лезть?

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

Просто это создаются лишние тормоза, пока сервер соеденится с БД.

А если БД нагруженная и отвечает не мгновенно, то это будет ощутимо.

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

 

Да и потом... stg для локалки на 4000 пользователей... как-то надо бы биллинг посерьезнее наверное )

[madf 279]

На самом деле вполне резонный вопрос. Таблица на 4000 записей - это несерьезная нагрузка для базы. Выборка будет происходить быстро (по крайней мере в Firebird и PostgreSQL мне доводилось работать и с большими таблицами). Старгейзер сейчас держит в памяти большое количество неактуальной информации, которую можно было бы вытягивать из базы по запросу.

PS: вроде-бы у кого-то Stg работает на 3000 юзерах.

[XoRe 0]

Помнится тут было движение за то, чтобы stg вообще мог работать при кратковременных потерях связи с БД )

Но это перекос конечно.

 

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

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

[madf 279]

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

Авторизация пользователя - явление эпизодическое. По этому и держать на него данные смысла нет.

Плюс, не забываем, что современные БД - это вам не просто файлы. Там и кеширование и оптимизация запросов и прочее.

В памяти достаточно держать список ip-адресов юзеров и по ним раскидывать трафик. Для авторизованных еще можно держать поля UserData, хотя это тоже спорный вопрос.

[Колян 2]

Заинтриговали вы мну... Решил поэксперементировать:

Железо - старый конченый селерон 700 мгц какой-то, 256 озу

ФРЯ 6.3

СТГ самой последней сборки и MYSQL_STORE

Скрипт пхп, который загонят 10 000 юзеров в бд

В общем. СТГ запускался 4-5 минут, де-то так.

Оперативы это чудо съело 219 метров. Проца кушает 38-45 процентов в свободном режиме.

Коннекчусь конфигуратором, он дооолго пытается вытянуть с сервера инфу. Тянет, тянет, тянет ну минут 5-7, и тут выскакивает вот это:

Что-то с памятью моею стало... что-то мне ее все мало, и мало...

[Колян 2]

Сколько юзеров может "стабильно" держать Старгазер последней версии ??

 

Сделал маленький тест - засунул в mysql базу 4000 юзеров, Старгазер их выгребал 8 минут (2.4 АМД 64бит(одно ядро)+1Гиг памяти), потом запустился и забрав 82МБ памяти работал.

Резонный вопрос - статистику обсчета он от первого до последнего юзера уже будет делать лроьше ведь ??

 

И еще вопрос - а зачем выгреб%#ь в ядро всю базу юзеров ??? Почему нельзя держать в памяти только тех кто сейчас находится в онлайне ?? тоесть при подключении юзера ядро забирает юзера из базы и обсчитывает его, при отключении юзера ядро освобождает юзера, естественно те кто АО постоянно в онлайне.

 

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

 

Вобщем мысли вслух на ночь глядя ))

А вообще, если серьезно, то щас гиг оперативки стоит 130 гривен, и экономить ее, оптимизируя биллинг, когда при этом новые баги могут вылезть, ИМХО не надо.

Ну а конфигуратор... Я бы был не против, если бы он нормально кушал 10к юзеров

[XoRe 0]

Имхо, дело в малой оптимизации работы с этими данными.

Хотя в целом да, можно многое вынести в sql.

Только после вынесения нужно провести тестирование, стресс-тест так сказать.

Как оно будет себя вести под нагрузкой.

 

В целом, если проблем со связью с sql сервером нету, затыки могут возникать только когда надо вытащить оттуда много инфы.

Это разнообразные отчеты.

Ну или когда конфигуратором цепляешься и показывается список юзеров.

Причем не столько изза sql.

Sql сервер нормально выдаст данные о и 1000 и 10000 юзерах.

А вот насколько быстро это обработает и выдаст конфигуратору стг - вопрос.

Поэтому смотреть надо в работу с данными внутри биллинга.

[martin 170]

))) Ну конфигуратор загибается и на 4к юзеров )) - это понятно.

 

Насчет памяти - это да, она то дешёвая.. но както стремно держать кучу юзеров на НЕ "ECC" памяти.. хз че там случится..

 

А вот то что на 700 селероне при 10к юзеров запуск был 4-5 минут.. это странно )

[madf 279]

Имхо, дело в малой оптимизации работы с этими данными.

Хотя в целом да, можно многое вынести в sql.

Только после вынесения нужно провести тестирование, стресс-тест так сказать.

Как оно будет себя вести под нагрузкой.

 

В целом, если проблем со связью с sql сервером нету, затыки могут возникать только когда надо вытащить оттуда много инфы.

Это разнообразные отчеты.

Ну или когда конфигуратором цепляешься и показывается список юзеров.

Причем не столько изза sql.

Sql сервер нормально выдаст данные о и 1000 и 10000 юзерах.

А вот насколько быстро это обработает и выдаст конфигуратору стг - вопрос.

Поэтому смотреть надо в работу с данными внутри биллинга.

Не понял, что там можно в sql вынести.

И о каких отчетах ты говориш.

Всяческие отчеты можно генерировать сторонним доступом к базе - помимо stg. И там уж оптимизировать особо нечего.

Да, когда сейчас цепляешся конфигуратором - он отдает всех юзеров со всеми данными. И вся эта бодяга сохраняется в xml, да еще и шифруется. Сам stg при этом не упал - замечательно. А вот конфигуратор - один из самых старых компонент системы. Там всякое может случиться. Да и вобще, не нравится он мне. Логика работы - в первую очередь.

Но это мы уже с Борей обсуждали, и идеи по поводу новой версии есть - нет только времени на реализацию.

[madf 279]

))) Ну конфигуратор загибается и на 4к юзеров )) - это понятно.

 

Насчет памяти - это да, она то дешёвая.. но както стремно держать кучу юзеров на НЕ "ECC" памяти.. хз че там случится..

 

А вот то что на 700 селероне при 10к юзеров запуск был 4-5 минут.. это странно )

Это зависит не только от stg, но еще и от БД.

[Ork Yason 8]

Макс, будь проще...

 

конфигуратор получает всех пользователей

 

нафиг!

 

сделайте выборку хотябы по адресу или айпи...

координально логику менять не надо

а точнее ваще не надо...

 

 

любая софтина загнецца отображая таблицу из 1000 строк...

[martin 170]

))) Ну конфигуратор загибается и на 4к юзеров )) - это понятно.

 

Насчет памяти - это да, она то дешёвая.. но както стремно держать кучу юзеров на НЕ "ECC" памяти.. хз че там случится..

 

А вот то что на 700 селероне при 10к юзеров запуск был 4-5 минут.. это странно )

Это зависит не только от stg, но еще и от БД.

2 тачки, втыкнуты друг в друга гигабитом, на одной SQL (Core2 Duo + 4 GB ram Mysql ) (AMD64 3800+ +1 GB STG) на обоих Gentoo последняя.

И в таких условиях загружается - выркзка из лога :

 

2008-05-05 15:00:04 -- Storage plugin: mysql_store v.0.67 #начинаем загрузку

 

2008-05-05 15:01:28 -- Users started successfully. #кончили загрузку

 

 

Вобщем уже не так уж и плохо ))

[Ork Yason 8]

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

[martin 170]

ты уже его задал )) Конечно он вкурсе, только давай не будем разводить святую войну по поводу того что на FreeBSD выигрыш в многопроцесорности против Linux на мускуле 50 %

[madf 279]

Все равно postgreSQL лучше

[Max 0]

Все равно postgreSQL лучше

абсолютно согласен, была даже мысль сделать плагин бд для него.....

[Колян 2]

Все равно postgreSQL лучше

А мерс покруче жигулей

Мускуль - более распространенная субд. Да и вообще... Можно и мускуль оттюнинговать хорошо. Было бы желание и надобность.

[Al G 0]

Всяк кулик своё болото хвалит... (с) //Народная мудрость

[Ork Yason 8]

ты уже его задал )) Конечно он вкурсе, только давай не будем разводить святую войну по поводу того что на FreeBSD выигрыш в многопроцесорности против Linux на мускуле 50 %

нееееееееееееее

 

ты не понял...

 

я не знаю как там у мускуля -а вот у ФБ есть версии для пенька, для пенька с хипертрейдингом, для двух ядер

 

мсскл - в настройках указывается шо можно юзать второй проц...

 

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

 

так вот мне и интересно - майскл в курсе шо у него два проца, и можно их юзать параллельно?

[Ork Yason 8]

Все равно postgreSQL лучше

А мерс покруче жигулей

Мускуль - более распространенная субд. Да и вообще... Можно и мускуль оттюнинговать хорошо. Было бы желание и надобность.

эт интересно как нужно тюнить жугуленог, шоб он мерсом стал

[Колян 2]

Ну... Если очень захотеть, можно в космос улететь. Модуль под мускуль уже есть... Читая форум, я понял, что фаерберд под фрю+ стг с модулем фаерберд завести не реально, так что на данный момент единственная СУБД для работы с СТГ под фрю - мускуль. На производительность пока не жалуюсь, около 150 тел в сети, в онлайне 20-60% онлайн.

Да, забыл... железо:

селерон 2.0, 512 озу, самый обычный десктопный хард samsung 40 ГБ.

[martin 170]

ты уже его задал )) Конечно он вкурсе, только давай не будем разводить святую войну по поводу того что на FreeBSD выигрыш в многопроцесорности против Linux на мускуле 50 % 

нееееееееееееее

 

ты не понял...

 

я не знаю как там у мускуля -а вот у ФБ есть версии для пенька, для пенька с хипертрейдингом, для двух ядер

 

мсскл - в настройках указывается шо можно юзать второй проц...

 

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

 

так вот мне и интересно - майскл в курсе шо у него два проца, и можно их юзать параллельно?

На сайте мускула есть скомпиленный пакет с оптимизацией под Интел.

 

Пы.Сы. - а насчет Postgre модуля я согласен, был бы вообще шоколад с таким модулем )

[Ork Yason 8]

ну дай бог вашему майсклу нашего феникса зъйисты

[madf 279]

...

 

Пы.Сы. - а насчет Postgre модуля я согласен, был бы вообще шоколад с таким модулем )

На базе сорсов mod_store_firebird - пишется за неделю.