Каково пороговое значение задержки для запуска сервера терминалов (RDS) по глобальной сети?


11

Я видел: производительность сервера терминалов по каналам с высокой задержкой

Но у меня есть заказчик, который заинтересован в перемещении своей системной инфраструктуры в центр обработки данных с задержкой ~ 62 мс от своего главного офиса.

Среда состоит из трех серверов RDS Windows Server 2008 R2, файловых служб и служб печати, а также Microsoft Exchange 2010. В настоящее время все они виртуализированы в кластере vSphere 5.5. Всего 80 пользователей подключаются локально к системам RDS с помощью тонких клиентов HP.

Из-за проблем с оборудованием и увеличения числа удаленных и удаленных пользователей наблюдается стремление переместить системы в центр обработки данных. На новом сайте будут представлены высокопроизводительные хосты vSphere и флеш-хранилище.

Подключение к средству совместного размещения будет установлено через VPN типа «сеть-сеть» с несколькими провайдерами и отказоустойчивым устройством.

Это плохая идея, хотя? Я часто подключаюсь к этому сайту для обслуживания по RDP и SSH, производительность вполне приемлема для моего случая использования. Пользователи используют базовый пакет MS Office и несколько легких приложений ERP на основе SSH-терминала.

Целесообразно ли 62 мс для этого типа пользовательской нагрузки и Microsoft RDS?


2
62ms не звучит ужасно, но задержка - убийца опыта для TS / RDS. Если пользователи начинают жаловаться на задержку при наборе текста, это может указывать на проблему с задержкой. У моего клиента, который управляет фермой RDS на 300 пользователей, есть клиенты по всему миру, и самые большие проблемы с производительностью связаны с задержкой. Пользователи, которые находятся дальше всего и имеют наибольшую задержку, жалуются на производительность. Можно ли протестировать всего несколько пользователей, чтобы почувствовать их производительность?
Joeqwerty

1
Я раскручиваю тестовую ВМ ... И, возможно, попробую подключить подмножество пользователей.
ewwhite

1
Обязательно отключите «ненужные анимации» в Windows, что устраняет необходимость явно отключать его и в MS Office. Анимации делают проблемы задержки намного более очевидными и тратят ценную пропускную способность, лучше используются для отправки соответствующих обновлений экрана. Office 2013 ужасен на RDS / XenApp из коробки в этом отношении! Кроме того, отключение графического ускорения HW в Office иногда может повысить производительность и уменьшить количество проблем.
Абстраск

Ответы:


11

У меня есть несколько тысяч человек по всему миру, которые ежедневно подключаются и используют бухгалтерское / офисное программное обеспечение. Пока их время отклика не превышает 300 мс, мы не получаем жалоб, кроме ммм.

В качестве подтверждения концепции я настроил один из наших пользовательских коммутаторов, используя окно linux / netem, и продолжал увеличивать задержку / потерю пакетов, пока у меня не начались жалобы. Намного проще было реплицировать сетевые условия локально, чем перемещать мои приложения дважды.


Как вы изменили задержку / потерю пакетов?
Ewwhite

@ewwhite Я добавил старый сервер в режиме моста между пользовательским коммутатором и маршрутизатором и настроил параметры netem.
Тим Бригам

1
Я использовал TMNetSim для имитации взаимодействия с пользователем с определенной задержкой. По сути, вы настраиваете его, используя опцию «развернут на клиенте», и указываете цель на 127.0.0.1. Симулятор перенаправляет его на цель после подключения с пропускной способностью сети. tmurgent.com/appv/index.php/en/resources/tools/…
Грег Аскью

1
+10 за эксперименты с живыми пользователями
Патрик

10

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

Это правда, что латентность - это убийца пользовательского опыта, но именно то, насколько это зависит от индивидуального восприятия.

Это довольно хорошее видео от TechEd 2014 о пользовательском опыте в сценариях, подобных этому (это видео о VDI, но оно похоже на службы удаленных рабочих столов).

https://www.youtube.com/watch?v=CcKAwzebHoc&feature=youtu.be

Таким образом, вы можете сказать, никогда не превышать 300 мс. 62 мс, вероятно, «ОК».


5

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

Я часто работаю удаленно через RDP из разных мест, большую часть времени подключаясь через сеть LTE (4G), которая обеспечивает задержки, подобные 62 мс. В это самое время я нахожусь в отеле с медленным соединением ~ 1 Мбит / с и задержками ~ 27-28 мс - менее половины значения в вашем случае. Даже с последним значением мне трудно работать с веб-браузером или просматривать крупную графику (особенно без AdBlock, сайты с богатой графикой могут рендериться в течение нескольких секунд в Firefox!). Также попытка написания простого документа с использованием Microsoft Word вызвала некоторое разочарование из-за ответственности за интерфейс ниже среднего (в свою очередь LibreOffice Writer чувствовал себя намного лучше). Не говоря уже о работе с видео ... С вещами, с которыми я могу довольно комфортно работать, являются MMC, почта Outlook (в некоторой степени), просмотр файлов и в целом задачи системного администрирования.

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

Одна вещь, которую нужно добавить - я работаю под Ubuntu с Rdesktop 1.7.1, который является моим предпочтительным RDP-клиентом. В оригинальном клиенте Microsoft (или других) могут быть некоторые оптимизации, которые могут улучшить производительность с ссылками с высокой задержкой.


4

Задержка менее 100 мс, вероятно, не будет проблемой, если ваши клиенты не будут играть в этой сети . Но в некоторых приложениях с интенсивной графикой (особенно при воспроизведении видео) вам может не хватить полосы пропускания, что отрицательно скажется на задержке и увеличит ее длительность свыше 100 мс, что раздражает ваших пользователей.

RDP 8 (Server 2012 и более поздние версии) поставляется с оптимизацией (читай: алгоритмы сжатия с потерями) для этих сценариев. Кроме того, поддержка транспорта UDP улучшит взаимодействие с пользователями по каналам связи со значительно изменяющейся задержкой или заметными потерями пакетов (> 0,1%). Поэтому, если у вас есть какой-либо из них, вы можете обновить хосты сеансов удаленных рабочих столов.


Это определенно вариант. Я не осознавал, что 2012 год принес эти преимущества. Будут ли эти преимущества применимы, если исходные устройства - это тонкие клиенты HP Linux?
Ewwhite

@ewwhite, только если тонкие клиенты действительно поддерживают RDP8. Rdesktop (популярный RDP-клиент для Linux) в настоящее время не поддерживает FreeRDP (разветвитель Rdesktop), утверждая, что поддерживает RDP8 , но более внимательный взгляд на список возможностей показывает, что в основном это RDP7. YMMV, так как я не знаю, что HP использует в конце концов. Клиенты Windows поддерживают RDP8, начиная с Embedded Standard 7
the wabbit

ThinPro от HP - это rdesktop. Обидно, потому что многие из этих клиентов были куплены за эти годы. Клиент только что купил любой тонкий клиент был самым дешевым.
ewwhite

@ewwhite Я понимаю, почему - у клиентов Windows Embedded есть серьезные требования к оборудованию и стоимость лицензирования. Принимая во внимание общую стоимость покупки, вы с таким же успехом могли бы покупать рабочие столы для Windows бизнес-класса и использовать их в качестве RDP-клиентов.
заместитель Wabbit
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.