Render_ 0 Опубліковано: 2007-07-12 05:10:54 Share Опубліковано: 2007-07-12 05:10:54 шансы 50/50 - это как? Оборвется либо не оборвется? ))) да имеено так. 2. Оставить схему работы ту же и искать пути решения проблемы в подстановке костылей. Например при соединении задать таймаут соединения в несколько минут. Сервер по истечении таймаута будет отключаться, а модуль будет тут же подключаться заново. Или можно перед выполением запроса в БД делать проверку соединения контрольным запросом и в случае невозможности выполнения запроса рвать соединение и создавать заново. вот что нам нужно. Ссылка на сообщение Поделиться на других сайтах
Колян 2 Опубліковано: 2007-07-12 08:00:33 Share Опубліковано: 2007-07-12 08:00:33 шансы 50/50 - это как? Оборвется либо не оборвется? ))) Выскажу и свое имхо. Уверен, что дампы - это то самое зло, уйти от которого и было целью при создании модуля. Мы уже проходили все проблемы с файлами, потерей данных и пр. Вы же предлагаете вернуться к этому же. Вариантов решения проблемы на сегодня два. 1. Полностью переделать схему работы с mysql-сервером по принципу "connect - query - answer - disconnect". Здесь возможны варианты. Можно, например, формировать очередь из запросов и выполнять запросы в БД с какой то периодичностью. Однако это тоже чревато потерей данных в случае аварийного завершения работы сервера или еще чего то. 2. Оставить схему работы ту же и искать пути решения проблемы в подстановке костылей. Например при соединении задать таймаут соединения в несколько минут. Сервер по истечении таймаута будет отключаться, а модуль будет тут же подключаться заново. Или можно перед выполением запроса в БД делать проверку соединения контрольным запросом и в случае невозможности выполнения запроса рвать соединение и создавать заново. Это все нюансы. Главное определить принцип работы. Однако дампы... файлы... - не тот путь! ИМХО. Первое ИМХО более надежно чем второе. Ссылка на сообщение Поделиться на других сайтах
Ork Yason 8 Опубліковано: 2007-07-12 08:02:20 Share Опубліковано: 2007-07-12 08:02:20 хм... я конечно не силен в майскле но не могу понят, а почему нельзя при коннекте пользователя открыть ему сессию и держать ее до его онконнекта? даже если учесть что база на 1000 абонентов, 30%онлайн, то 300соединений для нормального сервера не большое число с учетом того, что данные срыгиваются раз в 10минут, отдельным процессом, а пользовательские делают то, что пишут остатки по счетам и какие-либо мелкие изменения, т.е. работают с таблицами размером, соизмеримым с кол-во поьзователей по поводу дампов СУДБ - дают реальный прирост в скорости. это факт, иначе оракла бы не придумали... Ссылка на сообщение Поделиться на других сайтах
Ork Yason 8 Опубліковано: 2007-07-12 08:12:08 Share Опубліковано: 2007-07-12 08:12:08 стоп сессия одна это сессия модуля майскла к самому майсклу в ней он делает все что ему нужно а вот тайм-аут не нужен оно должна жить всегда, пока жив модуль майскла+стг можно еще одну создавать при сливе данных раз в 10минут а вообще, хреново жить без транзакций... биллинг на майскле... ой... Ссылка на сообщение Поделиться на других сайтах
vop 370 Опубліковано: 2007-07-12 10:18:14 Share Опубліковано: 2007-07-12 10:18:14 Уверен, что дампы - это то самое зло, уйти от которого и было целью при создании модуля. Мы уже проходили все проблемы с файлами, потерей данных и пр. Я прошу прощения, но проблема была не в файлах, а в программистах. Надо код писать надежный, а не искать проблемы с файлами. Если этого не понять -то будут проблемы и sql, и с чем угодно. Ссылка на сообщение Поделиться на других сайтах
Колян 2 Опубліковано: 2007-07-12 10:18:26 Share Опубліковано: 2007-07-12 10:18:26 Ну посмотрим, что разработчик скажет. Я свое мнение насчет коннекта выразил, возможно учтут, возможно писал просто так, для себя. по крайней мере, пока модуль тестовый, нужно пробовать, по крайней мере так. И из двух зол выбрать лучшее. Ссылка на сообщение Поделиться на других сайтах
Max 0 Опубліковано: 2007-07-12 17:48:03 Автор Share Опубліковано: 2007-07-12 17:48:03 Уверен, что дампы - это то самое зло, уйти от которого и было целью при создании модуля. Мы уже проходили все проблемы с файлами, потерей данных и пр. Я прошу прощения, но проблема была не в файлах, а в программистах. Надо код писать надежный, а не искать проблемы с файлами. Если этого не понять -то будут проблемы и sql, и с чем угодно. хочу заметить что баг не в самом модуле, а в Сервер БД (MYSQL) это кстати признали и сами разработчики мускула, однако править отказались по неведомым причинам... Ссылка на сообщение Поделиться на других сайтах
Колян 2 Опубліковано: 2007-07-12 18:08:15 Share Опубліковано: 2007-07-12 18:08:15 И кто теперь меня поддержит, раз на то пошло? Ссылка на сообщение Поделиться на других сайтах
platerx 0 Опубліковано: 2007-07-13 13:26:39 Share Опубліковано: 2007-07-13 13:26:39 Итак по поводу схемы присоединился - записал/прочитал - отсоединился: Сброс данных а базу происходит с определенным промежутком, по умолчанию 10 мин. Предположим у нас 200 пользователей. 10 мин = 600 сек. Т.е. на запись данных об одном пользователе выделяется 3 сек. Коннект с базой и закрытие соединения суммарно занимают 0.004 сек. (Я писал простейший тест. Кому надо могу выложить исходники.) для 200 коннектов время будет 1 сек. т.е. из 600 сек 1 сек будет тратиться на коннекты. По моему это приемлемо. Конечно это грубый подсчёт, необходимы более реальные тесты. Сейчас тестируется есть модуль в котором реализована именно эта схема. По поводу первоначальной схемы: В версии модуле 0.63 есть серьёзные ошибки(в плане работы с функциями mysql), есть подозрения, что именно из за этих ошибок он работает неправильно, но что бы их исправить нужно переписать много кода, и возможно изменять сам stg. И нет 100% гарантии, что именно из за этого мы имеем потерю соединения. Может это проблемя самго mysql. Поэтому если при тестировании модуля в котором реализована схема присоединился - записал/прочитал – отсоединился не будет серьёзных проблем с производительностью, то мы остановимся на ней. Иначе будем исправлять модуль с первоначальной схемой работы. Ссылка на сообщение Поделиться на других сайтах
Колян 2 Опубліковано: 2007-07-13 13:56:52 Share Опубліковано: 2007-07-13 13:56:52 Итак по поводу схемы присоединился - записал/прочитал - отсоединился:Сброс данных а базу происходит с определенным промежутком, по умолчанию 10 мин. Предположим у нас 200 пользователей. 10 мин = 600 сек. Т.е. на запись данных об одном пользователе выделяется 3 сек. Коннект с базой и закрытие соединения суммарно занимают 0.004 сек. (Я писал простейший тест. Кому надо могу выложить исходники.) для 200 коннектов время будет 1 сек. т.е. из 600 сек 1 сек будет тратиться на коннекты. По моему это приемлемо. Конечно это грубый подсчёт, необходимы более реальные тесты. Сейчас тестируется есть модуль в котором реализована именно эта схема. По поводу первоначальной схемы: В версии модуле 0.63 есть серьёзные ошибки(в плане работы с функциями mysql), есть подозрения, что именно из за этих ошибок он работает неправильно, но что бы их исправить нужно переписать много кода, и возможно изменять сам stg. И нет 100% гарантии, что именно из за этого мы имеем потерю соединения. Может это проблемя самго mysql. Поэтому если при тестировании модуля в котором реализована схема присоединился - записал/прочитал – отсоединился не будет серьёзных проблем с производительностью, то мы остановимся на ней. Иначе будем исправлять модуль с первоначальной схемой работы. Ну что сказать, я рад! Жду с нетерпением релиза (с бубном)! Ссылка на сообщение Поделиться на других сайтах
Alferov 0 Опубліковано: 2007-07-13 17:05:06 Share Опубліковано: 2007-07-13 17:05:06 FreeBSD 5.4 Mysql - 4.0.26 STG - последняя сборка store_mysql 0.65 (принцип работы: connect-query-answer-disconnect) пользователей - 212 (AlwaysOnline) Час эксплуатации - полет нормальный. Увеличения нагрузки не замечаю. Наблюдаем дальше. Ссылка на сообщение Поделиться на других сайтах
Колян 2 Опубліковано: 2007-07-13 18:28:47 Share Опубліковано: 2007-07-13 18:28:47 Что, уже релиз есть??? Ссылка на сообщение Поделиться на других сайтах
Alferov 0 Опубліковано: 2007-07-13 18:45:53 Share Опубліковано: 2007-07-13 18:45:53 я бы назвал это RC Что то при остановке стг в корку вывалился один раз. Ссылка на сообщение Поделиться на других сайтах
Колян 2 Опубліковано: 2007-07-13 18:54:05 Share Опубліковано: 2007-07-13 18:54:05 Ну от офф разработчика подождем, увидим что будет. Я же знаю, что я говорю! Как видите, нагрузки больше не стало. Ссылка на сообщение Поделиться на других сайтах
Cell 7 Опубліковано: 2007-07-14 15:12:29 Share Опубліковано: 2007-07-14 15:12:29 FreeBSD 5.4Mysql - 4.0.26 STG - последняя сборка store_mysql 0.65 (принцип работы: connect-query-answer-disconnect) пользователей - 212 (AlwaysOnline) Час эксплуатации - полет нормальный. Увеличения нагрузки не замечаю. Наблюдаем дальше. Ну что там после суток? Ссылка на сообщение Поделиться на других сайтах
Max 0 Опубліковано: 2007-07-14 15:21:47 Автор Share Опубліковано: 2007-07-14 15:21:47 http://www.opennet.ru/opennews/art.shtml?num=11405 касаемо мускул прокси Ссылка на сообщение Поделиться на других сайтах
Alferov 0 Опубліковано: 2007-07-14 16:19:06 Share Опубліковано: 2007-07-14 16:19:06 Сутки эксплуатации - полет нормальный. Никаких нареканий пока нет. Тьфу 3 раза. )) Ссылка на сообщение Поделиться на других сайтах
zulu_Radist 856 Опубліковано: 2007-07-14 16:55:55 Share Опубліковано: 2007-07-14 16:55:55 Alf где взял RC? Почему бы не выложить на тест и остальным? Ссылка на сообщение Поделиться на других сайтах
Колян 2 Опубліковано: 2007-07-14 18:10:12 Share Опубліковано: 2007-07-14 18:10:12 Это Альферова разработака, мало ли что... А вдруг заглючит оно у тебя в самый ответственный момент? Подождите уже наверное офф разработчика. Ссылка на сообщение Поделиться на других сайтах
Alferov 0 Опубліковано: 2007-07-14 18:19:13 Share Опубліковано: 2007-07-14 18:19:13 Это оф.разработка. Я просто тестирую. Думаю стоит подождать релиза. Бету не имеет смысл раздавать. п.с. не альферов, а алферов. Мягкий знак лишний. Ссылка на сообщение Поделиться на других сайтах
Колян 2 Опубліковано: 2007-07-14 19:15:14 Share Опубліковано: 2007-07-14 19:15:14 Это оф.разработка. Я просто тестирую.Думаю стоит подождать релиза. Бету не имеет смысл раздавать. п.с. не альферов, а алферов. Мягкий знак лишний. А мне не дадите протестить? Все равно он валяется постоянно, я кстати уже и скрипт написал для поднятия СТГ. Ссылка на сообщение Поделиться на других сайтах
Alferov 0 Опубліковано: 2007-07-14 19:16:59 Share Опубліковано: 2007-07-14 19:16:59 http://local.com.ua/forum/index.php?showto...=90entry63151 Ссылка на сообщение Поделиться на других сайтах
Max 0 Опубліковано: 2007-07-15 17:31:49 Автор Share Опубліковано: 2007-07-15 17:31:49 доступна официальная стандартная версия, брать сдесь: http://www.v-lan.ru/projects/stargazer-2.4/Modules/ Ссылка на сообщение Поделиться на других сайтах
Колян 2 Опубліковано: 2007-07-15 18:23:39 Share Опубліковано: 2007-07-15 18:23:39 Теперь ждем патча от Альферова, чтобы работала его статистика. Ссылка на сообщение Поделиться на других сайтах
zulu_Radist 856 Опубліковано: 2007-07-15 18:39:35 Share Опубліковано: 2007-07-15 18:39:35 Теперь ждем патча от Альферова, чтобы работала его статистика. Уже пропатченный, судя по ответу Альфа, можно взять здесь: http://alf.uzlovaya.ru/stg/stg-web/mod_sto..._STG-WEB.tar.gz Я еще не проверял, завтра буду пробовать, я чуток не в трезвом состоянии =:-/ Ссылка на сообщение Поделиться на других сайтах
Рекомендованные сообщения
Создайте аккаунт или войдите в него для комментирования
Вы должны быть пользователем, чтобы оставить комментарий
Создать аккаунт
Зарегистрируйтесь для получения аккаунта. Это просто!
Зарегистрировать аккаунтВхід
Уже зарегистрированы? Войдите здесь.
Войти сейчас