Перейти до

Разработка модуля MySQL


Рекомендованные сообщения

шансы 50/50 - это как? Оборвется либо не оборвется? )))

да имеено так.

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

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

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

вот что нам нужно.

Ссылка на сообщение
Поделиться на других сайтах
  • Відповіді 301
  • Створено
  • Остання відповідь

Top Posters In This Topic

шансы 50/50 - это как? Оборвется либо не оборвется? )))

 

Выскажу и свое имхо.

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

Вы же предлагаете вернуться к этому же.

 

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

1. Полностью переделать схему работы с mysql-сервером по принципу "connect - query - answer - disconnect". Здесь возможны варианты. Можно, например, формировать очередь из запросов и выполнять запросы в БД с какой то периодичностью. Однако это тоже чревато потерей данных в случае аварийного завершения работы сервера или еще чего то.

 

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

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

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

Это все нюансы. Главное определить принцип работы.

 

Однако дампы... файлы... - не тот путь! ИМХО.

Первое ИМХО более надежно чем второе.

Ссылка на сообщение
Поделиться на других сайтах

хм...

я конечно не силен в майскле

но не могу понят, а почему нельзя при коннекте пользователя открыть ему сессию и держать ее до его онконнекта? даже если учесть что база на 1000 абонентов, 30%онлайн, то 300соединений для нормального сервера не большое число

 

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

 

по поводу дампов

СУДБ - дают реальный прирост в скорости. это факт, иначе оракла бы не придумали...

Ссылка на сообщение
Поделиться на других сайтах

стоп

 

сессия одна

это сессия модуля майскла к самому майсклу

в ней он делает все что ему нужно

а вот тайм-аут не нужен

оно должна жить всегда, пока жив модуль майскла+стг

 

можно еще одну создавать при сливе данных раз в 10минут

 

а вообще, хреново жить без транзакций...

 

биллинг на майскле... ой...

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

Я прошу прощения, но проблема была не в файлах, а в программистах. Надо код писать надежный, а не искать проблемы с файлами. Если этого не понять -то будут проблемы и sql, и с чем угодно.

Ссылка на сообщение
Поделиться на других сайтах

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

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

Я прошу прощения, но проблема была не в файлах, а в программистах. Надо код писать надежный, а не искать проблемы с файлами. Если этого не понять -то будут проблемы и sql, и с чем угодно.

хочу заметить что баг не в самом модуле, а в Сервер БД (MYSQL) это кстати признали и сами разработчики мускула, однако править отказались по неведомым причинам...

Ссылка на сообщение
Поделиться на других сайтах

Итак по поводу схемы присоединился - записал/прочитал - отсоединился:

Сброс данных а базу происходит с определенным промежутком, по умолчанию 10 мин. Предположим у нас 200 пользователей. 10 мин = 600 сек. Т.е. на запись данных об одном пользователе выделяется 3 сек. Коннект с базой и закрытие соединения суммарно занимают 0.004 сек. (Я писал простейший тест. Кому надо могу выложить исходники.) для 200 коннектов время будет 1 сек. т.е. из 600 сек 1 сек будет тратиться на коннекты. По моему это приемлемо. Конечно это грубый подсчёт, необходимы более реальные тесты. Сейчас тестируется есть модуль в котором реализована именно эта схема.

 

По поводу первоначальной схемы: В версии модуле 0.63 есть серьёзные ошибки(в плане работы с функциями mysql), есть подозрения, что именно из за этих ошибок он работает неправильно, но что бы их исправить нужно переписать много кода, и возможно изменять сам stg. И нет 100% гарантии, что именно из за этого мы имеем потерю соединения. Может это проблемя самго mysql.

 

Поэтому если при тестировании модуля в котором реализована схема присоединился - записал/прочитал – отсоединился не будет серьёзных проблем с производительностью, то мы остановимся на ней. Иначе будем исправлять модуль с первоначальной схемой работы.

Ссылка на сообщение
Поделиться на других сайтах
Итак по поводу схемы присоединился - записал/прочитал - отсоединился:

Сброс данных а базу происходит с определенным промежутком, по умолчанию 10 мин. Предположим у нас 200 пользователей. 10 мин = 600 сек. Т.е. на запись данных об одном пользователе выделяется 3 сек. Коннект с базой и закрытие соединения суммарно занимают 0.004 сек. (Я писал простейший тест. Кому надо могу выложить исходники.) для 200 коннектов время будет 1 сек. т.е. из 600 сек 1 сек будет тратиться на коннекты. По моему это приемлемо. Конечно это грубый подсчёт, необходимы более реальные тесты. Сейчас тестируется есть модуль в котором реализована именно эта схема.

 

По поводу первоначальной схемы: В версии модуле 0.63 есть серьёзные ошибки(в плане работы с функциями mysql), есть подозрения, что именно из за этих ошибок он работает неправильно, но что бы их исправить нужно переписать много кода, и возможно изменять сам stg. И нет 100% гарантии, что именно из за этого мы имеем потерю соединения. Может это проблемя самго mysql.

 

Поэтому если при тестировании модуля в котором реализована схема присоединился - записал/прочитал – отсоединился не будет серьёзных проблем с производительностью, то мы остановимся на ней. Иначе будем исправлять модуль с первоначальной схемой работы.

Ну что сказать, я рад! Жду с нетерпением релиза (с бубном)!

Ссылка на сообщение
Поделиться на других сайтах

FreeBSD 5.4

Mysql - 4.0.26

STG - последняя сборка

store_mysql 0.65 (принцип работы: connect-query-answer-disconnect)

пользователей - 212 (AlwaysOnline)

 

Час эксплуатации - полет нормальный.

Увеличения нагрузки не замечаю. Наблюдаем дальше.

Ссылка на сообщение
Поделиться на других сайтах
FreeBSD 5.4

Mysql - 4.0.26

STG - последняя сборка

store_mysql 0.65 (принцип работы: connect-query-answer-disconnect)

пользователей - 212 (AlwaysOnline)

 

Час эксплуатации - полет нормальный.

Увеличения нагрузки не замечаю. Наблюдаем дальше.

Ну что там после суток?

Ссылка на сообщение
Поделиться на других сайтах

Это Альферова разработака, мало ли что... А вдруг заглючит оно у тебя в самый ответственный момент? Подождите уже наверное офф разработчика.

Ссылка на сообщение
Поделиться на других сайтах

Это оф.разработка. Я просто тестирую.

Думаю стоит подождать релиза. Бету не имеет смысл раздавать.

 

п.с. не альферов, а алферов. Мягкий знак лишний. :)

Ссылка на сообщение
Поделиться на других сайтах
Это оф.разработка. Я просто тестирую.

Думаю стоит подождать релиза. Бету не имеет смысл раздавать.

 

п.с. не альферов, а алферов. Мягкий знак лишний. :)

А мне не дадите протестить? Все равно он валяется постоянно, я кстати уже и скрипт написал для поднятия СТГ.

Ссылка на сообщение
Поделиться на других сайтах
Теперь ждем патча от Альферова, чтобы работала его статистика. :)

Уже пропатченный, судя по ответу Альфа, можно взять здесь:

 

http://alf.uzlovaya.ru/stg/stg-web/mod_sto..._STG-WEB.tar.gz

 

Я еще не проверял, завтра буду пробовать, я чуток не в трезвом состоянии =:-/

Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

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

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.


×
×
  • Створити нове...