|
MON$STATEMENTS почему NULL-ы (Обсуждаем серверные таймауты)
|
|||
---|---|---|---|
#18+
hvladCyberMaxВот обозначили выполнение апдейта в 2 секундыТаймаут в 2 сек - это полный маразм, давайте без фанатизма, плс +1 Забыл сказать: у меня стоит таймаут 8часов. Люди больше не работают. Обед нормально переждет, а на ночь надо программы закрывать. У меня просто нет отчетов (или регламентых расчетов), которые надо запускать с вечера, чтобы они были готовы к утру. Избавился. P.S. заодно отстреливаются коннекты от IBE, забытые программистами в терминале. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.10.2013, 11:30 |
|
MON$STATEMENTS почему NULL-ы (Обсуждаем серверные таймауты)
|
|||
---|---|---|---|
#18+
А будет ограничение по минимальному времени таймаутов? Я не спорю, что 2 секунды или 5 или 10 маразм, но найдутся же граждане... ... |
|||
:
Нравится:
Не нравится:
|
|||
15.10.2013, 11:34 |
|
MON$STATEMENTS почему NULL-ы (Обсуждаем серверные таймауты)
|
|||
---|---|---|---|
#18+
тут ещё в конфиге придётся вводить дополнительные единицы измерения s, m, h (наподобие k, m, g) ... |
|||
:
Нравится:
Не нравится:
|
|||
15.10.2013, 11:37 |
|
MON$STATEMENTS почему NULL-ы (Обсуждаем серверные таймауты)
|
|||
---|---|---|---|
#18+
Симонов ДенисCyberMax, просто не надо ставить таймаут когда это не требуется. Вот моё мнение когда использование таймаутов оправдано: - на хостинге (чтобы ограничить ресурсы) - в целях отладки приложения (хотя можно воспользоваться и трейсом) - для админов, например срубать забытый кем-то IBExpert на двое суток. Пытаться предсказать что запрос отработает в течении 5 секунд однозначно не стоит. Если уж устанавливать таймаут, то как минимум с 10 кратным запасом. п-а-а-звольте! 5 сек - это уже 20-ти кратный запас. 2 сек - максимальное время ожидания, не приводящее к баттхерту дискомфорту пользователя для всяких многозвенок важно вовремя понять, что очередной сервер врезал дуба и попытаться переключиться на резервные источники. для многих других приложений такой таймаут, есс-но, неприменим. поэтому я последовательно выступаю за явное указание таймаута для каждой транзакции (ну или коннекта). ... |
|||
:
Нравится:
Не нравится:
|
|||
15.10.2013, 12:33 |
|
MON$STATEMENTS почему NULL-ы (Обсуждаем серверные таймауты)
|
|||
---|---|---|---|
#18+
oleg_m, по моему опыту для "неактивных транзакций" надо ставить таймаут 60 минут, а то и 30 минут. Неактивные коннекты пусть живут хоть 100 лет. И запросы пусть выполняются хоть по 5 часов, если их так написали, и такие данные. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.10.2013, 12:33 |
|
MON$STATEMENTS почему NULL-ы (Обсуждаем серверные таймауты)
|
|||
---|---|---|---|
#18+
pastorдля всяких многозвенок важно вовремя понять, что очередной сервер врезал дуба и попытаться переключиться на резервные источники. в многозвенках обычно сложно понять, кто и где врезал дуба. Я имею в виду клиентскую сторону, от которой до БД слишком много звеньев со своими особенностями. pastorпоэтому я последовательно выступаю за явное указание таймаута для каждой транзакции (ну или коннекта). а я последовательно выступаю за таймауты по неактивности, и в первую очередь для транзакций. На текущий момент это массовая беда. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.10.2013, 12:38 |
|
MON$STATEMENTS почему NULL-ы (Обсуждаем серверные таймауты)
|
|||
---|---|---|---|
#18+
hvladТаймаут в 2 сек - это полный маразм, давайте без фанатизма, плс Таки согласен на 5 сек. hvladТаймауты, в первую очередь, предназначены для предотвращения ненужного потребления ресурсов (тот же застрявщий OST, толпа неактивных коннектов, жрущих память и т.п.) и как страховка от граничных (форс-мажорных, если хотите) ситуаций (кривой запрос, выполняющийся слишком долго и т.д.) Все перечисленные проблемы мне фиолетовы. Меня интересует только гарантированное время получения отклика, хотя бы для переключения на резервный источник данных. Сейчас приходится прибивать ВЕСЬ поток вместе с коннектом. А это очень грязное дело. hvladНе нужно искать realtime в таймаутах И куда же тогда податься бедному еврею? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.10.2013, 12:39 |
|
MON$STATEMENTS почему NULL-ы (Обсуждаем серверные таймауты)
|
|||
---|---|---|---|
#18+
pastor, таймауты здесь тебе не помогут. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.10.2013, 12:40 |
|
MON$STATEMENTS почему NULL-ы (Обсуждаем серверные таймауты)
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovИ это обсуждение не может включать в себя варианты реализации?.. Я вот вижу вариант реализации с дополнительным потоком. А что у тебя на уме? Вот так и кончаются все попытки обсудить варианты реализации. Влад любит аргументы, поэтому приведу один в пользу своего варианта реализации: в дополнительном потоке не обязательно доложен быть простой sleep/WaitFor, там можно крутить цикл select-recv для приёма пакетов их сокета/трубы/ДЕ_знает_чего_у_ХНЕТа, что в свою очередь даёт: 1) Возможность серверу в любой момент послать клиенту пакет "отвались, бездельник" после чего серверные таймауты работают на 100% вместо 95. 2) Оперативный приём, ответ и посылка ватчдог пакетов, что решает проблему переполнения системного буфера и оперативного обнаружения оборванной связи вне зависимости от настроек keep alive. 3) Возможность доставлять события в том же коннекте, без установки дополнительного. 4) С незначительным изменением сетевого протокола можно реализовать асинхронное API или реально параллельное использование одного коннекта разными потоками. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.10.2013, 12:54 |
|
MON$STATEMENTS почему NULL-ы (Обсуждаем серверные таймауты)
|
|||
---|---|---|---|
#18+
Симонов Денисpastor, таймауты здесь тебе не помогут. нужно иметь отличное зрение, чтобы на таком расстоянии увидеть "не помогут" (с) ... |
|||
:
Нравится:
Не нравится:
|
|||
15.10.2013, 13:08 |
|
MON$STATEMENTS почему NULL-ы (Обсуждаем серверные таймауты)
|
|||
---|---|---|---|
#18+
pastor, просто таймауты никак не смогут обеспечить гарантированное время отклика. Думаю здесь вообще ничего не поможет. Получить от программы отклик с сообщением таймаут истёк - это совсем не то чего ожидает увидеть пользователь. Поэтому я и говорю что сфера их применения несколько иная. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.10.2013, 13:13 |
|
MON$STATEMENTS почему NULL-ы (Обсуждаем серверные таймауты)
|
|||
---|---|---|---|
#18+
[quot kdv]pastorдля всяких многозвенок важно вовремя понять, что очередной сервер врезал дуба и попытаться переключиться на резервные источники. в многозвенках обычно сложно понять, кто и где врезал дуба. Я имею в виду клиентскую сторону, от которой до БД слишком много звеньев со своими особенностями. это в кривых многозвенках. речь идет именно о последнем звене и уходе isc_execute_immediate в глухую несознанку, без возможности получения статуса и без возможности привести ее в чувство без убиения вместе с потоком. как вариант - опциональный callback (с дефолтным "продолжайте до упора") для всех вызовов. в т.ч. commit ... |
|||
:
Нравится:
Не нравится:
|
|||
15.10.2013, 13:14 |
|
MON$STATEMENTS почему NULL-ы (Обсуждаем серверные таймауты)
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov2) Оперативный приём, ответ и посылка ватчдог пакетов, что решает проблему переполнения системного буфера и оперативного обнаружения оборванной связи вне зависимости от настроек keep alive . А вот ЭТО было бы весьма и весьма неплохо. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.10.2013, 13:21 |
|
MON$STATEMENTS почему NULL-ы (Обсуждаем серверные таймауты)
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakovhvladа) нет никакой реализации на данный момент, есть обсуждение И это обсуждение не может включать в себя варианты реализации?.. Я вот вижу вариант реализации с дополнительным потоком. А что у тебя на уме?Поток на коннект в клиенте - это маразм перебор. Есс-но, таймеры будут жить не в рабочем потоке приложения, но (на первый взгляд) достаточно одного служебного потока на все цели. На уме у меня - получить наиболее полную спецификацию данной фичи до начала её реализации. Тут уже прозвучали некоторые не самые очевидные нюансы, жду ещё :) ... |
|||
:
Нравится:
Не нравится:
|
|||
15.10.2013, 13:30 |
|
MON$STATEMENTS почему NULL-ы (Обсуждаем серверные таймауты)
|
|||
---|---|---|---|
#18+
hvladСимонов Денисбедный Евгений Болтик и так потерял нить беседыЧитая его тексты, я ещё ни разу не видел в них нити. Скорее запутанные клубки из разных нитей. Так что либо ему это и так привычно, либо это такая месть с нашей (моей) стороны :) Хочется нити, то тогда выходи на контакт и обсуждай без посторонних. Потому что забросаете фигней не по теме и хотите нормальной беседы. Я готов по скайпу в живую нормально объяснить, если чтиво дурно пишу. И будет обсуждение не 2-3 дня, а 1 час т.к. твой ответ будет 1. "не понял я тебя, иди подумай" 2. "мы это делать не будем" 3. "это запланирована голосуй" Я тут выше в этом балагане задал вопрос. А почему бы ИД транзакции не оставить хоть и выполнился запрос. Так хоть можно понять от какой транзакции это чудо. Транзакция то в списке болтается Мы тут не русский изучаем, чтобы придраться что знак вопроса не поставил. " почему бы " это то же знак вопроса. По балагану на твоем месте я бы: 1.Раз понимаешь о чем речь, про тайматуты, сделал первый вариант и сказал желающим попробуйте. И потом давай корректировать под ситуации. Причем для тестирующих на первой паре можно было бы такое на основе RDB$SET_CONTEXT сделать. Стартанул транзакцию кодовое слова для таймаута и время. На тестируются тестеры, сделаете изменения в ODS. 2.или создал трекер(или как оно там) кому надо голосуйте. Т.к. сейчас нету времени. И тут как всегда, желающие ждут пока благодать на сею вещь не сойдет. PS Собеседник был прав. На второй день когда проснулся глазам своим не поверил. Думал что не моя тема. С трудом прочитал... Я вообще не понимаю как можно еще и работать успевать, если столько тут писать. Или я один дурак чем старей, тем больше работаю и меньше общаюсь. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.10.2013, 13:30 |
|
MON$STATEMENTS почему NULL-ы (Обсуждаем серверные таймауты)
|
|||
---|---|---|---|
#18+
Евгений БолтикХочется нитиЖеня, мне - не хочется. Не я задаю вопросы. То, как ты пишешь, после первого прочтения вызывает недоумение, после второго - раздражение, после N лет игнорируемых просьб писать по-человечески приходит ощущение что ко мне обращается человек, которому глубоко наплевать на собеседника. Так понятно ? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.10.2013, 13:36 |
|
MON$STATEMENTS почему NULL-ы (Обсуждаем серверные таймауты)
|
|||
---|---|---|---|
#18+
Евгений БолтикА почему бы ИД транзакции не оставить хоть и выполнился запрос. Так хоть можно понять от какой транзакции это чудо. Транзакция то в списке болтается именно этот твой вопрос считаю вполне осмысленным. Про RDB$SET_CONTEXT ты чушь говоришь. Так делать точно никто не будет. И про ODS тоже. Пока вообще не вижу как таймауты могут на ODS повлиять. Хотя может я и ошибаюсь. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.10.2013, 13:37 |
|
MON$STATEMENTS почему NULL-ы (Обсуждаем серверные таймауты)
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovВлад любит аргументы, поэтому приведу один в пользу своего варианта реализации: в дополнительном потоке не обязательно доложен быть простой sleep/WaitFor, там можно крутить цикл select-recv для приёма пакетов их сокетаТы предлагаешь вообще всю сетевую работу вынести в этот отдельный поток, или только служебные задачи ? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.10.2013, 13:45 |
|
MON$STATEMENTS почему NULL-ы (Обсуждаем серверные таймауты)
|
|||
---|---|---|---|
#18+
pastorМеня интересует только гарантированное время получения отклика, хотя бы для переключения на резервный источник данных. Сейчас приходится прибивать ВЕСЬ поток вместе с коннектом. А это очень грязное дело.Ну так есть же fb_cancel_operation. pastorhvladНе нужно искать realtime в таймаутахИ куда же тогда податься бедному еврею?Для начала - в realtime OS :) ... |
|||
:
Нравится:
Не нравится:
|
|||
15.10.2013, 13:46 |
|
MON$STATEMENTS почему NULL-ы (Обсуждаем серверные таймауты)
|
|||
---|---|---|---|
#18+
hvladПоток на коннект в клиенте - это перебор. Сейчас этот поток создаётся при использовании эвентов. Я предлагаю создавать его безусловно. Среднее приложение устанавливает один, максимум два коннекта одновременно, так что оптимизация в этом месте мне кажется излишней, поскольку усложнит код без реальной потребности. Но, конечно, ты сможешь написать мегакод, который в одном дополнительном потоке сможет обслужить все таймауты всех коннектов, а заодно и события, ватчдоги и прочие пакеты. Я в тебя верю. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.10.2013, 13:48 |
|
MON$STATEMENTS почему NULL-ы (Обсуждаем серверные таймауты)
|
|||
---|---|---|---|
#18+
hvladЕвгений БолтикХочется нитиЖеня, мне - не хочется. Не я задаю вопросы. То, как ты пишешь, после первого прочтения вызывает недоумение, после второго - раздражение, после N лет игнорируемых просьб писать по-человечески приходит ощущение что ко мне обращается человек, которому глубоко наплевать на собеседника. Так понятно ? После того как с тобой общаются, по другому не получается. А особенно когда говоришь "N лет игнорируемых просьб". Это понятно? Я повторюсь у меня нет желания лабудить просто так, даже "не желания", а "времени нет". Я хочу продуктивно поговорить 15 мин и уйти со сцены в раздумья. Давай сделаем по другому я тебе предложу, что то без "игнора". Мы встретимся в скайпе, если будет у меня такое. Ты выслушаешь. И если предложу вроде как нужную мысль, ты ее на обсуждение. Якобы на вашем "человеческом" языке, мне даже не надо моего упоминания, что это мысль была моя. Лишь бы это появилось по возможности. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.10.2013, 13:54 |
|
MON$STATEMENTS почему NULL-ы (Обсуждаем серверные таймауты)
|
|||
---|---|---|---|
#18+
hvladТы предлагаешь вообще всю сетевую работу вынести в этот отдельный поток, или только служебные задачи ? Если бы у меня хватало мозгов чтобы разобраться в современном коде птицы, то лично я бы вынес туда весь приём пакетов от сервера и, возможно, их парсинг. (Надеюсь, для тебя не будет сюрпризом, что принимать пакеты из сокета и посылать их в него могут разные потоки. По крайней мере в Windows.) А отсылку пакетов оставил бы тем потокам, в которых вызываются функции API. Естественно, с сериализацией этой отсылки. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.10.2013, 13:55 |
|
MON$STATEMENTS почему NULL-ы (Обсуждаем серверные таймауты)
|
|||
---|---|---|---|
#18+
Евгений Болтик, тебя регулярно слушает Дмитрий Еманов, насколько я знаю. Так что : - про "N лет игнорируемых просьб" ты преувеличиваешь, - вторую жертву ты не получишь :) ... |
|||
:
Нравится:
Не нравится:
|
|||
15.10.2013, 13:58 |
|
MON$STATEMENTS почему NULL-ы (Обсуждаем серверные таймауты)
|
|||
---|---|---|---|
#18+
Евгений БолтикДавай сделаем по другому я тебе предложу, что то без "игнора". Мы встретимся в скайпе, если будет у меня такое. Ты выслушаешь. извиняюсь, что влезаю, но если человек не может изложить мысль в письме, то и в скайпе он ее не изложит. Иногда даже и в очном разговоре мысль трудно понять. Мы, правда, тут уже давно работаем телепатами, но у этой способности есть предел. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.10.2013, 14:03 |
|
MON$STATEMENTS почему NULL-ы (Обсуждаем серверные таймауты)
|
|||
---|---|---|---|
#18+
Симонов ДенисЕвгений БолтикА почему бы ИД транзакции не оставить хоть и выполнился запрос. Так хоть можно понять от какой транзакции это чудо. Транзакция то в списке болтается именно этот твой вопрос считаю вполне осмысленным. Про RDB$SET_CONTEXT ты чушь говоришь. Так делать точно никто не будет. И про ODS тоже. Пока вообще не вижу как таймауты могут на ODS повлиять. Хотя может я и ошибаюсь. Я про RDB$SET_CONTEXT сказал как временное решение, чтобы не расширять синтаксис до момента осознания, что нужно. То есть временно не документируемый код. Я бы так сделал. Так быстрей можно понять, что нужно и что происходит. Про ODS это к тому, что я так понимаю могут добавиться команды. Если не повлияет то даже можно без RDB$SET_CONTEXT сразу реализовать расширение функционала для тестеров. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.10.2013, 14:04 |
|
|
start [/forum/topic.php?fid=40&startmsg=38427820&tid=1561806]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
45ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 162ms |
0 / 0 |