Я видел: Производительность терминального сервера по каналам с высокой задержкой
Но у меня есть заказчик, который заинтересован в перемещении своей системной инфраструктуры в центр обработки данных, который имеет задержку ~ 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?
У меня несколько тысяч людей по всему миру, которые ежедневно подключаются и используют бухгалтерское / офисное программное обеспечение. Пока их время ответа составляет менее 300 мс, мы не получаем жалоб, кроме ymmv.
В качестве доказательства концепции я установил один из наших пользовательских коммутаторов, используя Linux / netem box, и продолжал увеличивать задержку / потерю пакетов, пока у меня не появились жалобы. Было намного проще воспроизвести сетевые условия локально, чем дважды перемещать мои приложения.
Я чувствую, что это своего рода субъективное мнение, поскольку некоторые пользователи не будут довольны, если задержка не будет такой же, как у локального рабочего стола, а другие пользователи будут счастливы и не будут жаловаться, даже если задержка составляет 300 мс.
Это правда, что задержка убивает пользовательский опыт, но насколько именно зависит от индивидуального восприятия.
Это довольно хорошее видео от TechEd 2014 о взаимодействии с пользователем в сценариях, подобных этому (это видео о VDI, но похоже на службы удаленных рабочих столов).
https://www.youtube.com/watch?v=CcKAwzebHoc&feature=youtu.be
Можно сказать, никогда не выходите за пределы 300 мс. 62 мс, вероятно, "нормально".
На этот вопрос нельзя ответить действительно универсально и объективно. Результаты действительно зависят от типа нагрузки и требований пользователей. Здесь нет ничего лучше UX-тестов.
Я часто работаю удаленно через RDP из разных мест, большую часть времени подключаюсь через сеть LTE (4G), которая предлагает задержки, близкие к 62 мс. Как раз в это время я нахожусь в отеле с медленным соединением ~ 1 Мбит / с и задержками ~ 27-28 мс - в вашем случае меньше половины значения. Даже с последним значением у меня возникают проблемы с просмотром веб-страниц или крупной графики (особенно без AdBlock, сайты с богатой графикой могут отображаться в течение нескольких секунд в Firefox!). Также попытка написать простой документ с использованием Microsoft Word вызвала некоторое разочарование из-за того, что ответственность за интерфейс ниже среднего (в свою очередь, LibreOffice Writer чувствовал себя намного лучше). Не говоря уже о работе с видео ... То, с чем я могу довольно комфортно работать, - это MMC, почта Outlook (в некоторой степени), просмотр файлов и вообще задачи системного администрирования.
Это значение должно подходить для удаленного администрирования системы и аналогичных задач, которые вы выполняете регулярно и имеете опыт. Но если это полностью заменить локальный экран, я бы ожидал разочарований и жалоб.
Следует добавить: я работаю под Ubuntu с rdesktop 1.7.1 - мой предпочтительный клиент RDP. В исходном клиенте Microsoft (или других) могут быть некоторые оптимизации, которые могут улучшить производительность с ссылками с высокой задержкой.
Задержка менее 100 мс, скорее всего, не будет проблемой, если ваши клиенты игры по этой сети. Но у вас может не хватить пропускной способности в некоторых приложениях с интенсивным использованием графики (особенно при воспроизведении видео), что отрицательно скажется на задержке и приведет к ее значительному превышению 100 мс, раздражая ваших пользователей.
RDP 8 (Server 2012 и более поздние версии) действительно содержит оптимизацию (читай: алгоритмы сжатия с потерями) для этих сценариев. Кроме того, поддержка транспорта UDP улучшит взаимодействие с пользователем по ссылкам со значительно различающейся задержкой или заметными потерями пакетов (> 0,1%). Поэтому, если у вас есть какие-либо из них, вы можете обновить хосты сеансов удаленных рабочих столов.