Форум » Для флейма » ADS Remote тормоза по TCP/IP » Ответить
ADS Remote тормоза по TCP/IP
Haz: Поднят VPN и через него получили виртуальную сеть, на одном из компов которой установлен сервер ADS и базы На другом компе этой сети установлена клиентская программа. Параметры подключения прописаны в ADS.INI В итоге клиент конектится к серверу , но навигация по бровсам жуть как тормозит. Пробовал в ini указать принудительно подключаться через UDP/IP - в результате те же яйца , только в профиль , тормозит по прежнему. В бренмауре порты и протоколы разрешены , TCPView при любом протоколе указанном в ini упорно показывает что пакеты идут только через TCP/IP. Подробнее тут, указывая UDP пакеты идут по TCP, но если в брендмауре запретить UDP - то клиент перестает конектиться. Никак не пойму что за шляпа с этим ADS в протоколах По идее UDP пошустрее должен быть. Дальше еще интереснее, если клиента цепануть к базам через local server то тормозов нет, реально рагница раз в 10 по быстроте реакции. Может проблема в том что ADS сервер поднят на обычной Win7 , и у нее есть какие нибудь ограничалки на TCP ? Имеет ли смысл там поставить серверную винду ? Как первопричину тормозов вижу еще и хреновый интернет канал на компе с ADS. SpeedTest кажет 15 мегабит, на компе с ADS и 10 мегабит на компе клиента, но тупое копирование на расшаренную папку между компом клиента и компом ADS показывает в фаре скорость 70 - 300кб/с что в принципе мало для 15 мегабит. Коллеги , может есть у кого мысли в каком порядке бороться с тормозом ? Начинать в серверной ОС или не стоит, заняться каналом интернет и пр. пока склоняюсь к каналу, по гложат сомнения и по поводу Win7 т.к. клиентов будет штук 20 PS. VPN поднят через OpenVPN на VDS в 100 МВ/С, в другой компании аналогичная связка отлично работает , но там и win server и канал шире.
Ответов - 36, стр:
1 2 All
SergKis: PS На сервере имею TAG на время модификации, по нему выборки оч. быстрые
Haz: Оптимизация прорисовки бровса, нужна. Будет посвободнее займусь. Пока у меня в хеш массиве кешируются только справочники. Надо посмотреть на прорисовку. Возможно сделать симбиоз из бровса по базе и массиву с подчиткоой из базы. Сейчас у меня головняк это резкое падение скорости на Opevpn. Сегодня продолжу эксперимент, в одной рекомендации нашел тесты скорости при различных mtu. Наибольшее значение было при mtu 48000 и это при пакете в 1472.
SergKis: Haz пишет Будет посвободнее займусь Улыбнуло, сам все время так мыслю ... Возможно сделать симбиоз из бровса по базе и массиву с подчиткоой из базы. По мне, надо перевести все отображение на внутр. массив и внутренние данные типа ordKeyCount(), LastRec(), ... Их запрашивать с сервера при refresh(.t.), скролах. тогда же подчитывать и в массив.
Haz: Pasha пишет: Попробуйте забить значения для :bKeyNo, :bKeyCount, :bLogicLen пустышками, вроде: oB:bKeyNo := {|| 1} Да , по скорости прогресс хороший , Правда вся навигация съехала Причем достаточно :bKeyNo, :bKeyCount уже можно работать В итоге : 1)на OpenVPN отключено шифрование 2)MTU = 48000 3)Буфер приема передачи = 512к 4) :bKeyNo, :bKeyCount := {|| 1} 5) Справочники читаются через хеш а не из бызы и система ожила, работает не как по локалке , но шустро PPS это все же убрал , оказалось влияет на скорость не так существенно 4) :bKeyNo, :bKeyCount := {|| 1}
Haz: SergKis пишет: надо перевести все отображение на внутр. массив Вобщем-то ты прав. По сути получится то же окно через которое смотрим на базу. Размер окна равен размеру бровса. В базу нужно добавить поле штампа времени модификации записи. В бровс массив времени можификации записи по последней выборке из строки. По таймеру запускать процедуру проверки этих значений и при необходимости обновлять нужную строку ( проверяя возможный get в ней). Такой алгоритм снизит трафик в минимум и на узком канале все будет работать хорошо. Но платой за это будет тормоз при скроле и листании страниц. Хотя можно читать не окно строк бровса а опционально по несколько вверх и вниз от окна которое видим. К примеру 1000 строк вверх низ от видимого окна. Тогда Тормозить бадет на этих границах. Дополнительно тоже самое со справочниками. И все это наверное не в массиве а в мем базе, удобнее будет делать сик по времени и синхронизировать. Как идея вроде должна работать. Я пока справочники на это перевожу. До самой базы дойду не скоро. И не уверен что это нужно прятать внутрь класса.
SergKis: Haz пишет Но платой за это будет тормоз при скроле и листании страниц Думается этого можно избежать. Сейчас работает примерно в такой схеме 1. :DrawLine пробегает по всем строкам окна с чтением из базы и прорисовкой каждой строки 2. :DrawLine читает, прорисовывает текущую строку 3. :DrawSelect читает, прорисовывает текущую строку далее возможны варианты от чистоты\неточности кода. Если перевести на вн. массив, то в :DrawLine можно добавить параметр, к примеру lRefresh, при .T. можно подчитывать запись nRow в массив, потом прорисовывать всеми методами из вн. массива хоть nn раз. Схема будет мало отличаться от действующей, ведь изменения, по мне, должны проходить на тек. раб версии не ломая ее. Т.е. для начала все режимы (массив, dbf, txt, rcordset) надо перевести на массив. С timer по переотображению не все просто, попадал на клиентов, которые пугались, когда время перепоказа совпадало с действием на что то в тсб (хотя таймер на без дейсвие юсера). Реально сечас оставляю кнопку для ручного refresh. Но это субъективно, главное вне тсб и потому не очень важно. Потом нет необходимости в каждой записи тсб хранить время модификации, достаточно на всю прочитанную таблицу. Запрос на получение изменений позже этого значения. Получив изменеия и положив их во врем. раб. табл., сохраняем новое последнее время модификации для дальн. исп. . И все это наверное не в массиве а в мем базе, удобнее будет делать сик по времени и синхронизировать. Можно не тольео в mem:, но и в TEMP каталоге, как просто dbf или как временный файл, открываем монопольно со всеми вытекающими. Можно пользовать не только dbSeek, но и set relation.
PSP: На мой взгляд вариант загрузки на клиента для локального просмотра - самый правильный. Предположим, нужно загрузить 1000 записей по 1000 байт каждая. Получается 1000000 байт, т.е. 1Мб. Даже при ширине канала 10Мбит/с загрузка 1Мб займет около 1с. Активация бровса с локальным dbf - это быстро. Т.е., всё займет меньше двух секунд, я думаю.
Haz: PSP пишет: Можно пользовать не только dbSeek, но и set relation. стесняюсь представить что слишком много придется копировать локально. Твк как это уже не справочники а подчененные базы. PSP пишет: На мой взгляд вариант загрузки на клиента для локального просмотра - самый правильный Возможно да, вопрос в том что именно грузить. Как вариант можно на клиенте поднять реплику и вопрос синхронизации отдать серверу.
Haz: PSP пишет: Даже при ширине канала 10Мбит/с загрузка 1Мб займет около 1с. Это в идеале, в жизни наложится качество канала со своим пингом, время на шифрование и расшифровку трафика, плюс потери и повторную передачу пакетов. Так что можно смело умножать на 3 (если повезло) в более менее реальном случае. Идаже если так то, это отлично.
PSP: Haz пишет: на клиенте поднять реплику и вопрос синхронизации отдать серверу Иногда автоматическая синхронизация не нужна. Достаточно ручного обновления.
PSP: Ну а в идеале: сервер - на то и сервер, чтобы по запросу клиента выдать готовые к отображению данные.
Haz: PSP пишет: Ну а в идеале: сервер - на то и сервер, Вот и я о том же. Ранее не сталкивался с проблемой узкого канала, последний проект заставил задуматься. Получается web решение в этом случае производительнее так как тупо шлет один раз то что надо и кешируют данные на клиенте. Рефреш по запросу. То что предлагает Сергей как раз в логике web
PSP: Да.
Haz: Придётся привыкать делать Рефреш по запросу. Но как же красиво смотрелось изменение данных в реальном режиме. Сосед цифирь поменял, тебе пофиг, но приятно что ты это сразу заметил
SergKis: Haz пишет Сосед цифирь поменял, тебе пофиг, но приятно что ты это сразу заметил Не обязательно жать refresh, листнул - на экране свежие данные, а refresh когда user знает, что клиент\материал\... уже должен быть доступен но не виден или на всякий случай ткнул, чтоб перекурить
Haz: SergKis пишет: на всякий случай ткнул, чтоб перекурить Это нафиг. Плавали, знаем. В 90х один сотрудник так косил от работы. Кнопку нажал и 15 минут перекура заработал. На вопрос чего стоишь резонно отвечал что видишь обмен идет
полная версия страницы