Удаленное подключение к AOS

[shurik]

Возможно ли использование тонкого клиента axapta при условии что поключение к AOS будет осуществляться по модемному соединению (28.8) или такая скорость недостаточна?

[Peter Savintsev]

Теоретически подключиться можно. На работать это будет СТРАШНО медленно. С помощью настроек (отключить кэширование таблиц) можно чуть ускорить загрузку, но все равно тормозить будет сильно. Даже соединения на 56 маловато, работать можно, но с большим трудом.

[Михаил Андреев]

Тестировал в свое время работу с Аксаптой через AOS и терминальный доступ Windows 2000. Удивительно, но быстрее показался именно последний.
Хотя, в принципе вариант через AOS должен работать лучше. Видимо, нужно было чего еще настроить Узнаете, скажите, всем будет интересно...

[GeorgeVk]

Я пробовал на 40К через VPN соединение. Аксапта грузилась, но при попытке открыть форму (например, журналы тек. операций), после довольно большой паузы приложение вышибало.
Разбираться с этим времени не хватило, хотя возможность такой работы очень интересна.
На форуме были сообщения, что тонкий клиент локализованной версии работает гораздо медленее оригинальной (точнее, создает гораздо больший трафик).

[mazzy]

На скорости 28.8 работать можно. Проверено.
Мало того в ходе нормальной работы канал постоянно недозагружен.

Но первая загрузка объектов, форм, отчетов в кеш происходит очень медленно. У меня было около 10 минут. Чтобы свести это время к приемлимому, надо поотрубать startup процедуры, доставки dll-ек на клиента, проверки файлов и т.п.

О реокмендациях на AOS см. документ
Technical Information\Object Server Environment.doc

Там спецаильно предупреждается, что AOS предпочитает передать один раз большой кусок, нежели несколько маленьких. Это надо учитывать.

Практически, на очень медленных каналах передача больших кусков выражается в том, что клиент работает в "рваном" ритме. Работаем-работаем, жде-е-ем, опять работаем-работаем, снова жде-е-ем. Такой ритм раздражает. Терминальный режим на сильно тонком канале эргономичнее, поскольку нагрузка размазывается по времени и время реакции всегда примерно одинаково небыстрое.

Для AOSа рекомендуется учитывать не столько ширину канала, сколько задержки (латентность).

AOS не рассчитывался на работу одного пользователя на тонком канале. AOS рассчитывался на работу нескольких пользователей (10 и больше) на средней паршивости канале. Например, в рекомендациях к каналу говорится о минимальных 64Кбитах для 10 пользователей. Подумайте над этой рекомендацией. Это вовсе не значит, что 28.8 для 1 будет хорошо Но работать такая конфигурация будет. Удовольствия правда совсем никакого. Подход к каналу четко прослеживается и в ценообразовании.

[glibs]

К сожалению, я про реальную работу сказать пока ничего не могу.

Тестировал на качественном соединении 33.6К, средняя задержка 190 мс (в рамках офисной телефонной сети). Приложение грузится действительно долго. Последний раз тестировал 3.0 международную версию. По-моему загрузка приложения с главным меню занимала около 2-х минут. Завтра уточню. Больше 5 мин. ничего вообще не грузилось. На скорость загрузки больше всего влияет Главное меню (ГМ). Отключение для пользователя открытия ГМ на первой загрузке позволяло мне сократить время загрузки примерно в 2 раза (возможно 2 мин. — это и есть первая загрузка без ГМ). Если приложение закрыть и снова открыть без разрыва связи, то система грузилась в среднем за 45 сек. (если не удалять кэш на клиенте).

Общее впечатление от работы не очень приятное. Первый раз форма открывается довольно долго. Потом из кэша существенно быстрее, почти удовлетворительно. Если вам в системе нравится «хлопать окнами», то такая конфигурация вас доведет до безумства очень быстро.

Если же открыть план счетов, к примеру, и начать создавать новые счета, то на втором-третьем счете скорость работы становится весьма приемлемой. Захочется понажимать на кнопки — опять будет тормозить.

В общем я сделал такие выводы. Если для конкретного пользователя, который занимается конкретными однотипными операциями (в идеале — ввод строк в журнале) и не перепрыгивает постоянно из одной формы в другую, создать профильное минимально-достаточное меню и подточить формы, то вполне можно работать и в таком режиме.

На скорость выполнения операций (не путать с комфортностью работы) вляют следующие вещи. Использование отчетов вместо запросов и форм (возможно, с преднастроенными фильтрами). Отчеты строятся в несколько раз быстрее, нежели отрабатываются формы. Для некотрых отчетов можно настроить пакетный режим с отправкой по электронной почте (это offline с выпонение на сервере и минимальная нагрузка на канал). Сокращение до минимума количества элементов управления на формах (лишние закладки, лишние поля, особенно расчетные). Максимальное использование пакетной обработки. Например, Заказ можно инвойсить в пакетном режиме! К сожалению, МБС эти вещи далеко не всегда в своих разработках учитывает, поэтому некоторые из них потенциально могут не работать по слишком тонкому каналу.

Возможно, имеет смысл пересмотреть технологию работы пользователей: чтобы они по возможности вводили информацию пакетами (несколько строк в одной форме, а не туда–сюда–обратно), больше специализировать (типизировать операции) пользователей.

Могу подтвердить слова Mazzy о том, что один клиент канал существенно недогружает, что при росте канала комфортность работы повысится даже при адекватном росте числа пользователей, что при увеличении задержки работать становится совсем грустно. Возможно, на каналах с высокой задержкой проще будет работать через Web (Enterprise Portal).

А что, реально Аксапту никто на тонких каналах не эксплуатирует?

Sorry за правки. Толи связь, толи форум, но что-то глюконуло. К счастью уже вошло в привычку текст сохранять на диске.

[mazzy]

Цитата:

Изначально опубликовано glibs
На скорость загрузки больше всего влияет Главное меню (ГМ).

Согласен с тем, что видимый эффект дает Главное меню.
Но, по-моему, задержку дает не само меню, а какая то предварительная подгрузка объектов, которые из меню вызываются. Но пока это только предположение.

Согласен с тем, что если меню сократить, то в качестве видимого эффекта получится значительное сокращение времени первой загрузки.

[mazzy]

Вот прямая ссылка на документ про ширину канала для AOS с формулой для расчета необходимой ширины
http://technet.navision.com/default....put&NEWSID=408

[mazzy]

Вот прямая ссылка на документ про ширину канала для AOS с формулой для расчета необходимой ширины
http://technet.navision.com/default....put&NEWSID=408

[glibs]

Цитата:

Изначально опубликовано glibs
...По-моему загрузка приложения с главным меню занимала около 2-х минут. Завтра уточню...

Вчера забыл посмотреть. Честно говоря, ожидал найти больше записей. Вот что нашел:

Первоначальная загрузка с Главным меню 3:45
Повторная загрузка с Главным меню 1:25, 1:29
Первоначальная загрузка без Главного меню 2:15, 2:00
По повторной загрузке без Главного меню записей нет, но точно помню, что было в среднем 0:45. Один раз даже за 0:29 загрузилась (это записано).

Не быстро, но работать можно. Скорее всего, скорость работы будет существенно зависеть от администратора системы.

Mazzy, спасибо за ссылку. Насчет Главного меню: оно ведь само по себе тоже не маленькое. По моим наблюдениям на TCP/IP на 33.6к полезный трафик за минуту не превышает 164к. Возможно оно просто грузится (там же полным-полно menuitems, в котрых тоже много параметров).