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


11

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?


1
O que você fez para tentar rastrear a latência? Os clientes estão em uma rede local? Composição do equipamento de rede? Todos eles ficam ao mesmo tempo? Recursos do servidor; processador (es), RAM, disco? Monitor de desempenho? Versões do cliente, extensão, RemoteFX?
Chris S

Se você estiver executando um TS, como uma VM, quantas CPUs virtuais você atribuiu? Você pode se sair melhor com várias VMs com um número menor de CPUs.
Zoredache

Obrigado pelas sugestões. Eu não fiz nada para rastrear a latência. Vai tentar descobrir passo a passo ...
Hemal

Respostas:


16

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.


Boa resposta. Eu gerencio um farm de 20 servidores TS e as 2 causas mais comuns de problemas de desempenho que vemos são as 2 que você listou primeiro em sua resposta: largura de banda e latência. Esses 2 fatores têm o maior impacto no desempenho (ou desempenho percebido) na minha opinião. Meus próprios testes mostraram que um usuário executando vários aplicativos do Office, IE, e abrindo arquivos PDF consumia uma média de 100Kbps em um período de 8 horas. É esse o nosso número de planejamento em termos de alocação de largura de banda por usuário e é o que recomendamos que nossos clientes tenham para ter sessões de "bom desempenho".
joeqwerty

Olá Nic, Muito obrigado pela resposta detalhada e agradável. Vou passar por isso e vou tentar descobrir .. Muito obrigado pela resposta. Graças à Joeqwerty também para comentários ..
Hemal

Eu administro uma pequena fazenda e concordo. Também usamos o PRTG para verificar se os dados históricos correspondem aos problemas relatados. Nosso número dois problemas são de banda (problemas locais / ISP) e CPU (programas ruins em servidores com baixa contagem de núcleos). A melhor maneira de ver rapidamente se a largura de banda é perguntar aos usuários se a entrada de texto parece estar atrasada.
Gomibushi

Você mencionou muitas ferramentas excelentes, mas quanto de uma sessão os requisitos de largura de banda podem ser coletados por meio do WMI? ou contadores de desempenho ainda melhores? Eu sou novo no TS, mas fui incumbido de apresentar várias estatísticas em uma sessão. Agradecemos antecipadamente pelo seu tempo.
codeputer

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.