Descubra o gargalo do servidor de área de trabalho remota do Windows (servidor de terminal)

Eu tenho o Windows Server 2008 R2 (SP1) instalado no meu host VMware para funcionar como servidor RDS. Às vezes, meus usuários remotos podem ver o atraso / atraso no servidor RDS. Alguém pode me dizer, por experiência própria, quais são as práticas recomendadas para encontrar o gargalo desse servidor?

Como Chris S mencionou, há várias coisas que podem contribuir para o fraco desempenho da área de trabalho remota. Pela minha experiência, essas são as principais causas, em ordem de probabilidade.

Largura de banda
A principal causa de baixo desempenho na área de trabalho remota é a falta de largura de banda. Dependendo exatamente do que está sendo feito, uma sessão pode usar de alguns Kbps a alguns Mbps de largura de banda. Meus próprios testes mostraram que a rolagem de um PDF usará até 3 Mbps. À medida que a largura de banda disponível diminui, o desempenho percebido também diminui.

Você primeiro precisa determinar as necessidades de largura de banda do seu aplicativo. Isso requer testes em um ambiente de LAN controlado e mede o uso da largura de banda à medida que você executa tarefas normais. Pessoalmente, tive sucesso com o NetLimiter em minha estação de trabalho pessoal. Você também pode abordar o problema de outro ângulo e usar o NetLimiter para forçar a velocidade de sua conexão a qualquer que seja sua classificação de WAN. Isso deve dar uma boa indicação do que os usuários remotos estão vendo.

Depois de saber quanta largura de banda seu aplicativo deseja, é necessário determinar se esse é o fator limitante. Primeiro, meça a largura de banda disponível entre o cliente e o servidor. Uma excelente ferramenta para isso é iperf. Suponho que você tenha largura de banda suficiente disponível durante um teste controlado.

Em seguida, você desejará configurar algum tipo de monitoramento de largura de banda para verificar se os problemas relatados pelo usuário se correlacionam com picos no tráfego ou outros indesejáveis. Minha preferência é despejar o tráfego de um switch ou roteador ntop, pois ele fornece relatórios históricos e em tempo real úteis sobre o uso da largura de banda.

Se você estiver com problemas de largura de banda, uma alteração fácil é alterar as configurações de "Experiência" na conexão da área de trabalho remota. Desative estilos visuais e animações, e muitas operações na área de trabalho parecerão magicamente mais rápidas.

Latência
Outro problema comum nas conexões de área de trabalho remota é a latência. É necessário que haja um tempo de ida e volta razoavelmente rápido entre o cliente e o servidor, ou as pessoas poderão perceber um atraso. Como regra geral, a maioria das pessoas começa a perceber problemas entre 50 e 100 ms de tempo de ping.

Felizmente, isso geralmente é fácil de diagnosticar. Você pode configurar ferramentas de monitoramento como o SmokePing ou o PRTG Network Monitor para fornecer relatórios sobre a latência entre o servidor de monitoramento e qualquer outro host arbitrário. Você pode até usar o ping -tcomando interno para sessões curtas. Normalmente, você deseja localizar o servidor de monitoramento na mesma LAN que o servidor da área de trabalho remota e configurar o monitoramento no servidor e nos seus clientes. Tente correlacionar os relatórios de problemas com incidentes com tempo de ping alto.

Se você estiver tendo problemas com altos tempos de ping, use traceroutepara descobrir onde o atraso está sendo introduzido. Se você determinar que o problema reside em sua própria rede, considere introduzir a filtragem de QoS para priorizar o tráfego em tempo real como a Área de Trabalho Remota.

Além disso, tenha cuidado com qualquer pessoa que esteja se conectando por uma mídia sem fio, seja 802.11 (WiFi) ou, pior, uma conexão via satélite. As conexões sem fio são propensas a interferências ambientais que podem causar problemas extremos de latência sob várias condições e por períodos variáveis. E usar a área de trabalho remota através de um satélite sempre é uma merda.

CPU ou memória local E, finalmente, é possível que seu servidor esteja simplesmente sobrecarregado. Monitore o uso da CPU e da memória, especialmente durante o horário de pico, para garantir que o servidor seja capaz de atender solicitações em tempo hábil.

Uma das ferramentas mencionadas acima (PRTG) pode ser configurada para monitorar o uso da CPU e da memória de um servidor ao longo do tempo e pode produzir gráficos que facilitam a correlação de relatórios de problemas com falhas específicas.

Dica de bônus: se seus usuários estiverem tendo problemas para digitar, especialmente no que diz respeito às teclas modificadoras que não estão sendo aplicadas corretamente, tente alterar as configurações do teclado no atalho de conexão da Área de Trabalho Remota para que a opção Aplicar combinações de teclas do Windows esteja definida como On the local computer.

Confira o RDS Best Practices Analyzer .