Terminal Server и пропускная способность
Модераторы: Trinity admin`s, Free-lance moderator`s
Terminal Server и пропускная способность
Уважаемый All, часто вопросы про железо для Terminal Server,
а мне интересно:
каков расчет пропускной способности по юзерам для Terminal Server?
Желательно отдельно для протоколов RDP и ICA (думаю, разница есть)
Ну например по обычной цифре 64K скока юзеров рекомендуется?
Спасибо.
а мне интересно:
каков расчет пропускной способности по юзерам для Terminal Server?
Желательно отдельно для протоколов RDP и ICA (думаю, разница есть)
Ну например по обычной цифре 64K скока юзеров рекомендуется?
Спасибо.
по моему опыту для работы 5-6 человек по RDP с MS access интерфейсом достаточно 64кбит.
Наш филиал таким образом работал из москвы с питерской базой данных.
По этому же каналу приходила почта и народ лазил по www
Если приоритезировать RDP трафик, то разница с локальной сетью незаметна. Естественно - никаких картинок!
Важно, чтобы не было больших задержек и потерь пакетов.
__
33.600 по модему это совсем не то, что 33.600 по синхронному каналу с временем распространения 35-40 мс!
Я бы так сравнивать не стал. Работа на 33.600 через модемы, воткнутые в одну офисную АТС (190-220мс), более менее приемлема, а вот в реальности все существенно хуже. Задержки распространения влияют на usability очень сильно.
В то же время, на синхронном канале в 32кбит можно работать двоим. Проверено.
При активной работе с тектовыми данными (листаем страницы) RDP сессия требует 12-16 кбит. При обычной работе (набор текста) 5-8кбит На холостом ходу 800-500 бит. Бывают конечно всплески, но чем больше народу тем ровнее работа.
4 человека на 64к будут трудиться абсолютно комфортно, что не скажешь про двух пользователей на 32кбит.
(только никаких картинок!)
Наш филиал таким образом работал из москвы с питерской базой данных.
По этому же каналу приходила почта и народ лазил по www
Если приоритезировать RDP трафик, то разница с локальной сетью незаметна. Естественно - никаких картинок!
Важно, чтобы не было больших задержек и потерь пакетов.
__
33.600 по модему это совсем не то, что 33.600 по синхронному каналу с временем распространения 35-40 мс!
Я бы так сравнивать не стал. Работа на 33.600 через модемы, воткнутые в одну офисную АТС (190-220мс), более менее приемлема, а вот в реальности все существенно хуже. Задержки распространения влияют на usability очень сильно.
В то же время, на синхронном канале в 32кбит можно работать двоим. Проверено.
При активной работе с тектовыми данными (листаем страницы) RDP сессия требует 12-16 кбит. При обычной работе (набор текста) 5-8кбит На холостом ходу 800-500 бит. Бывают конечно всплески, но чем больше народу тем ровнее работа.
4 человека на 64к будут трудиться абсолютно комфортно, что не скажешь про двух пользователей на 32кбит.
(только никаких картинок!)
у нас в Питере 100мбит до узла обмена трафиком, в Москве было 64к.perlamer писал(а):спасибо! Это намана. Так типа и будет - 64 K Питер-Москва.
Поэтому приоритезацию делали только в Москве.
Просто не знаю. Утверждается, что слегка быстрее. Но, как мне кажется, это касается компрессии битмапов и пр.perlamer писал(а): А как насчет исследований ICA- сильно быстрее?
У ICA куча других преимуществ, но я не пробовал.
Принтерные файлы не слишком экономны. Это действительно проблема.perlamer писал(а): И еще- большая ли перегрузка, когда клиент с терминала на печать
документ бросает? (предполагается работа с правовыми системами - тем же Консультант+ с возможностью печати статей)
Между СПБ и МСК у нас поднят VPN на VTUN с компрессией. Сжимает довольно заметно.В среднем разница за день по RDP протоколу между TUN интерфейсом и реальным - 22-28%. Печатают немало. Видимо печатные задания и жмутся, потому что больше нечему -).
Внутри VPN поднята маршрутизация между питерской и московской приватными сетями. Пропускаем только RDP трафик от сервера из СПБ и трафик VOIP между АТС.
Приоритеты шейпинга (в терминах FreeBSD IPFW)такие:
90 - для VOIP
60 - RDP от клиентов к серверу
50 - RDP от сервера к клиентам
10 - от сервера к сетевому принтеру в Москве
Возможность печати по RDP специально не использовали.
Иначе большие задания на печать тормозят всех остальных, а отличить печатное задание от обычной работы нельзя -(
Важно не делать размер очереди слишком большим, иначе будут задержки. 512 байт вполне приемлемо.
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 11 гостей