Re: TCP REMOTE BUFFER
Alexandr Kochmin пишет: а часто обрывы? процентов 5 от общего количества, не больше -- Regards, Ovchinnikov Vasily ova at tkvc ru
Re: TCP REMOTE BUFFER
OV Alexandr Kochmin пишет: OV а часто обрывы? OV процентов 5 от общего количества, не больше честно говоря не понял, от общего количества чего? -- С уважением Кочмин Александр
Re: TCP REMOTE BUFFER
Alexandr Kochmin wrote: да меня скорость фетча вполне устраивает. Меня не устраивает обмен мелкими данными. Самое напрашивающееся решение: посылать результат FetchAll одним пакетом Ну, и служебную инфу, типа описания полей таблицы и т.д. которой много и мелкой. Вообще, я давно сделал такую феньку: справочник (если не слишком большой) при первом обращении грузится целиком в память (CachedUpdates=true, FetchAll, транзакцию закрываем) и там остается до выхода из программы или до команды обновить справочники. Первое открытие окна тормозит, зато второе уже летает мухой. PS. Надо бы описать это да на сайт выложить, но руки никак не дойдут.
Re: TCP REMOTE BUFFER
Horsun Vlad пишет: Yurij ... Туннелирование через ZeBeDee не поможет? Оно вообще на узких каналах помогает. Нет Подтверждаю, что не помогает относительно времени отклика. Зато помогает для экономии траффика (у меня до 10 раз ужимает) и обеспечивает безопасность. Но про это уже много написано. Лично меня пока устраивает FB+ZeBeDee даже в WAN. У нас так продажа автобусных билетов через Интернет сделана для автовокзалов. Будет лучше с оптимизированным REMOTE-протоколом - это просто здорово, кто бы спорил! -- Regards, Ovchinnikov Vasily ova at tkvc ru
Re: TCP REMOTE BUFFER
KRB Самое напрашивающееся решение: посылать результат FetchAll одним KRB пакетом Ну, и служебную инфу, типа описания полей таблицы и т.д. KRB которой много и мелкой. Вот и я примерно также буду делать. -- С уважением Кочмин Александр
Re: TCP REMOTE BUFFER
OV Лично меня пока устраивает FB+ZeBeDee даже в WAN. У нас так продажа OV автобусных билетов через Интернет сделана для автовокзалов. Будет лучше OV с оптимизированным REMOTE-протоколом - это просто здорово, кто бы OV спорил! ага. Так вот раз ты уже этим пользуешься, то можешь ли что-то сказать про потерю пакетов и обрыв коннекта в таком решении? -- С уважением Кочмин Александр
Re: TCP REMOTE BUFFER
Vlad Horsun wrote: Alexey Khayanok ... Это _очень_ зависит от приложения. Наибольший выигрыш будет на большом кол-ве запросов, т.к. хорошо экономятся roundtrip's и траффик у prepare (и у всех info-запросов). Фетчи мы пока не трогали Согласен. Большой р-р сетевого пакета (subj) + ZeBeDee даст именно это. На фетче - да, на служебке zebedee ухудшает производительность, потому, что пытается жать мелкие пакеты хотя резона в этом никакого нет.
Re: TCP REMOTE BUFFER
Alexandr Kochmin пишет: OV Лично меня пока устраивает FB+ZeBeDee даже в WAN. У нас так продажа OV автобусных билетов через Интернет сделана для автовокзалов. Будет лучше OV с оптимизированным REMOTE-протоколом - это просто здорово, кто бы OV спорил! ага. Так вот раз ты уже этим пользуешься, то можешь ли что-то сказать про потерю пакетов и обрыв коннекта в таком решении? Про потерю пакетов ничего не скажу, не диагностировал и не наблюдал, а вот обрывы случаются, быть может и из-за потери пакетов в том числе, ибо дороги длинные и между клиентом и сервером бывает порой до 15 разных роутеров. Фантомные соединения срубаю по KEEPALIVE. С базами ничего страшного не происходит, все довольны, так что я не парюсь и вполне жизнью доволен. -- Regards, Ovchinnikov Vasily ova at tkvc ru
Re: TCP REMOTE BUFFER
OV Про потерю пакетов ничего не скажу, не диагностировал и не наблюдал, а OV вот обрывы случаются, быть может и из-за потери пакетов в том числе, OV ибо дороги длинные и между клиентом и сервером бывает порой до 15 OV разных роутеров. а часто обрывы? OV Фантомные соединения срубаю по KEEPALIVE. С базами ничего страшного не происходит, все довольны, так что я не парюсь и OV вполне жизнью доволен. понятно. Хорошо. -- С уважением Кочмин Александр
Re: TCP REMOTE BUFFER
Alexandr Kochmin [EMAIL PROTECTED] wrote: üÔÏ ÓÅÒ×ÅÒ × ÐÁËÅÔ ÐÁÔÕÅÔ ÔÏÌØËÏ ÐÏÓÌÅÄÏ×ÁÔÅÌØÎÙÊ ÆÅÔÞ ÏÄÎÏÇÏ ÚÁÐÒÏÓÁ? éÌÉ ÏÎ ÍÏÖÅÔ ÒÁÚÎÏÅ ÔÕÄÁ ÎÁÐÁËÏ×ÁÔØ? ôÏÌØËÏ ÆÅÔÞ. îÁÞÉÎÁÑ Ó 2.x (ÇÄÅ x 0), ÓÍÏÖÅÔ ÒÁÚÎÏÅ (ÈÏÔØ É ÎÅ ×ÓÅ). ðÒÏÂÌÅÍÁ ÔÏ × ÔÏÍ, ÞÔÏ ÕÍÅÎØÛÉÔØ ËÏÌÉÞÅÓÔ×Ï ÐÁËÅÔÏ× × ÓÅÔÉ, ÞÔÏ ÐÒÉÌÏÖÅÎÉÅ ÞÅÒÅÚ WAN ÂÙÓÔÒÅÅ ÒÁÂÏÔÁÌÏ. äÌÑ ÎÅÇÏ ÂÏÌØÛÁÑ ÐÒÏÂÌÅÍÁ - ÜÔÏ ÍÅÌËÉÅ ÐÁËÅÔÙ. http://www.firebirdsql.org/index.php?op=devjournal, ÚÁÐÉÓØ ÏÔ 4 ÍÁÑ -- äÍÉÔÒÉÊ åÍÁÎÏ×
Re: TCP REMOTE BUFFER
DY Проблема то в том, чтоб уменьшить количество пакетов в сети, DY чтоб приложение через WAN быстрее работало. Для него DY большая проблема - это мелкие пакеты. DY http://www.firebirdsql.org/index.php?op=devjournal, DY запись от 4 мая почитал. Хорошо. А сейчас никак совсем? Хочется уйти от сервера терминалов на прямой коннект. -- С уважением Кочмин Александр
Re: TCP REMOTE BUFFER
Alexandr Kochmin [EMAIL PROTECTED] wrote: á ÓÅÊÞÁÓ ÎÉËÁË ÓÏ×ÓÅÍ? îÉËÁË. ôÏÌØËÏ Õ×ÅÌÉÞÉÔØ TcpRemoteBufferSize É ×ËÌÀÞÉÔØ TcpNoNagle. åÓÌÉ ÔÙ ÕÖÅ ÎÁ FB, ÔÏ ÍÏÖÎÏ ÔÅÂÅ ÄÁÔØ ÂÉÌÄ (ÎÁ ÏÓÎÏ×Å 1.5.3), × ËÏÔÏÒÏÍ ×ÙÛÅÏÐÉÓÁÎÎÙÅ ÕÌÕÞÛÅÎÉÑ ÒÅÁÌÉÚÏ×ÁÎÙ. îÁ Ô×ÏÊ ÓÔÒÁÈ É ÒÉÓË, ÅÓÓ-ÎÏ. îÏ ÏÐÅÒÁÔÉ×ÎÏÅ ÉÓÐÒÁ×ÌÅÎÉÅ ÎÁÊÄÅÎÎÙÈ ÏÛÉÂÏË ÇÁÒÁÎÔÉÒÕÅÍ :-) -- äÍÉÔÒÉÊ åÍÁÎÏ×
Re: TCP REMOTE BUFFER
Dmitry Yemanov [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Alexandr Kochmin [EMAIL PROTECTED] wrote: á ÓÅÊÞÁÓ ÎÉËÁË ÓÏ×ÓÅÍ? îÉËÁË. ôÏÌØËÏ Õ×ÅÌÉÞÉÔØ TcpRemoteBufferSize É ×ËÌÀÞÉÔØ TcpNoNagle. ôÕÎÎÅÌÉÒÏ×ÁÎÉÅ ÞÅÒÅÚ ZeBeDee ÎÅ ÐÏÍÏÖÅÔ? ïÎÏ ×ÏÏÂÝÅ ÎÁ ÕÚËÉÈ ËÁÎÁÌÁÈ ÐÏÍÏÇÁÅÔ.
Re: TCP REMOTE BUFFER
Yurij ... Туннелирование через ZeBeDee не поможет? Оно вообще на узких каналах помогает. Нет -- Хорсун Влад
Re: TCP REMOTE BUFFER
DY Alexandr Kochmin [EMAIL PROTECTED] wrote: DY DY А сейчас никак совсем? DY Никак. Только увеличить TcpRemoteBufferSize и включить TcpNoNagle. понятно. Попробую. да и то , этож только в FB В yaffil такого нету вроде. DY Если ты уже на FB, то можно тебе дать билд (на основе 1.5.3), в котором DY вышеописанные улучшения реализованы. На твой страх и риск, есс-но. Но DY оперативное исправление найденных ошибок гарантируем :-) хм... надо подумать, чтоб перейти. Хотя я собирался переходить сразу на FB2. -- С уважением Кочмин Александр
Re: TCP REMOTE BUFFER
Y Dmitry Yemanov Y [EMAIL PROTECTED] wrote in Y message news:[EMAIL PROTECTED] Y Y Alexandr Kochmin [EMAIL PROTECTED] Y wrote: Y А сейчас никак совсем? Y Никак. Только увеличить TcpRemoteBufferSize и включить TcpNoNagle. Y Туннелирование через ZeBeDee не поможет? Оно вообще на узких Y каналах помогает. в данном случае причина не в ширине канала, а большом времени отклика. Канал то совсем не загружен. zebedee пробовал. Эффекта нет. Как и думал. -- С уважением Кочмин Александр
Re: TCP REMOTE BUFFER
Alexandr Kochmin [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Y îÉËÁË. ôÏÌØËÏ Õ×ÅÌÉÞÉÔØ TcpRemoteBufferSize É ×ËÌÀÞÉÔØ TcpNoNagle. Y ôÕÎÎÅÌÉÒÏ×ÁÎÉÅ ÞÅÒÅÚ ZeBeDee ÎÅ ÐÏÍÏÖÅÔ? ïÎÏ ×ÏÏÂÝÅ ÎÁ ÕÚËÉÈ Y ËÁÎÁÌÁÈ ÐÏÍÏÇÁÅÔ. × ÄÁÎÎÏÍ ÓÌÕÞÁÅ ÐÒÉÞÉÎÁ ÎÅ × ÛÉÒÉÎÅ ËÁÎÁÌÁ, Á ÂÏÌØÛÏÍ ×ÒÅÍÅÎÉ ÏÔËÌÉËÁ. ëÁÎÁÌ ÔÏ ÓÏ×ÓÅÍ ÎÅ ÚÁÇÒÕÖÅÎ. zebedee ÐÒÏÂÏ×ÁÌ. üÆÆÅËÔÁ ÎÅÔ. ëÁË É ÄÕÍÁÌ. á, ×ÉÄÅÌ ÔÁËÕÀ ÐÅÞÁÌØ.
Re: TCP REMOTE BUFFER
DY Alexandr Kochmin [EMAIL PROTECTED] wrote: DY DY А сейчас никак совсем? DY Никак. Только увеличить TcpRemoteBufferSize и включить TcpNoNagle. DY Если ты уже на FB, то можно тебе дать билд (на основе 1.5.3), в котором DY вышеописанные улучшения реализованы. На твой страх и риск, есс-но. Но DY оперативное исправление найденных ошибок гарантируем :-) Вообщем подумал. буду так делать: 1) в приложении внимательно посмотрю чтоб не отвлекать сервер по пустякам запросами, а больше кэшировать, или брать сразу побольше. Т.к сейчас приложение по каждому пустяку в базу ходит как к себе домой :) 2) если эффект будет недостаточным, то буду быстрее переходить на Firebird1.5 или уже 2. И там включу уже эти ключики. -- С уважением Кочмин Александр
Re: TCP REMOTE BUFFER
Alexandr Kochmin wrote: Вообщем подумал. буду так делать: 1) в приложении внимательно посмотрю чтоб не отвлекать сервер по пустякам запросами, а больше кэшировать, или брать сразу побольше. Т.к сейчас приложение по каждому пустяку в базу ходит как к себе домой :) 2) если эффект будет недостаточным, то буду быстрее переходить на Firebird1.5 или уже 2. И там включу уже эти ключики. Как показали натурные испытания на спецбилде, выигрыша больше чем на 20-30% не получишь, а на больших фетчах весь выигрыш практически нивелируется. Пока не будет реализована упаковка данных передаваемых по сети средствами сервера все остальное мало эффективно.
Re: TCP REMOTE BUFFER
Alexey Khayanok ... Как показали натурные испытания на спецбилде, выигрыша больше чем на 20-30% не получишь, а на больших фетчах весь выигрыш практически нивелируется. Это _очень_ зависит от приложения. Наибольший выигрыш будет на большом кол-ве запросов, т.к. хорошо экономятся roundtrip's и траффик у prepare (и у всех info-запросов). Фетчи мы пока не трогали Пока не будет реализована упаковка данных передаваемых по сети средствами сервера все остальное мало эффективно. Большой р-р сетевого пакета (subj) + ZeBeDee даст именно это. -- Хорсун Влад
Re: TCP REMOTE BUFFER
Vlad Horsun [EMAIL PROTECTED] wrote: üÔÏ _ÏÞÅÎØ_ ÚÁ×ÉÓÉÔ ÏÔ ÐÒÉÌÏÖÅÎÉÑ. é ÏÔ ËÏÍÐÏÎÅÎÔÏ× ÄÏÓÔÕÐÁ. þÅÍ ÏÎÉ ÔÕÐÅÅ (ÔÉÐÁ IBX), ÔÅÍ ×ÙÉÇÒÙÛ ÂÏÌØÛÅ æÅÔÞÉ ÍÙ ÐÏËÁ ÎÅ ÔÒÏÇÁÌÉ ÷ÏÏÂÝÅ-ÔÏ, ÉÈ ÔÒÏÇÁÌÉ ÄÏ ÎÁÓ :-) é Ñ ÐÏËÁ ÎÅ ×ÉÖÕ, ÞÔÏ ÔÁÍ ÅÝÅ ÍÏÖÎÏ ÓÄÅÌÁÔØ, ÚÁ ÉÓËÌÀÞÅÎÉÅÍ ÄÏÓÔÁ×ËÉ ÐÅÒ×ÏÇÏ ÐÁËÅÔÁ ×ÍÅÓÔÅ Ó execute. îÏ ÅÓÌÉ ÄÁÎÎÙÈ ÍÎÏÇÏ, ÔÏ ÜÔÏ ËÁÐÌÑ × ÍÏÒÅ. -- äÍÉÔÒÉÊ åÍÁÎÏ×