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