desempenho do IO do Azure

Question

Temos várias máquinas virtuais do Windows Server que usamos para desenvolvimento e controle de qualidade em .NET e Java. Acho Azure atraente pelas razões óbvias, mas principalmente pela oportunidade de reduzir as horas não produtivas gastas em manutenção ambiental.

Funcionalmente, depois de limpar os problemas de ID do sistema com alguns dos aplicativos (licenciamento, et al.) tudo está bem, mas o desempenho é um pouco deficiente:
Nosso sistema leva cerca de 2 minutos para criar sua solução quando executado no Hyper-V ou no ESXi, mas a máquina do Azure A3 leva até 12 minutos para executar a mesma compilação . O monitor de recursos mostra que na maioria das vezes a máquina está em ES lendo o disco.

Existe algo que eu deveria estar fazendo de forma diferente ou devo esperar um melhor desempenho das máquinas locais em todos os casos?

    

Answer 1

As VMs do Azure são dimensionadas com base em seus núcleos de RAM e CPU, mas todos os tamanhos estão visivelmente ausentes no desempenho de armazenamento, que sempre se torna o principal culpado, independentemente de quantos núcleos e memória você joga em uma VM.

Duas soluções:

• Para uso normal, basta anexar o máximo possível de discos de dados à sua VM e configurá-los no RAID 0 no sistema convidado; AE / S é limitada ao nível do disco, portanto, mais discos = mais E / S. Use esses discos para o trabalho real, não coloque nada além do O.S. no disco do sistema (que é uma prática recomendada, de qualquer forma). Essa estratégia não tem custos adicionais, porque o armazenamento do Azure é cobrado com base no espaço real usado: o número de discos virtuais e seu tamanho aparente não importam. (*)
• Se você realmente precisar de desempenho em disco, use armazenamento premium .

(*) Se você está preocupado em usar o RAID 0, não seja assim. Esses são discos virtuais e sua integridade já é garantida pela camada de armazenamento subjacente. O RAID 0 é usado apenas para agrupá-los em um único volume lógico com melhor desempenho.

    

Answer 2

O Azure é um serviço compartilhado. Você deve esperar variações aleatórias de desempenho com base na carga do hipervisor no qual está sendo executado (sobre o qual você não tem absolutamente nenhum controle), e uma série literalmente infinita de outros fatores (sobre os quais você também não tem controle).

Se o desempenho (e consistência) for crítico, hospede seu próprio ambiente, em seu próprio hardware.

    

Answer 3

Você não deve usar sua unidade c para aplicativos:

link

A unidade C é otimizada para o tempo de inicialização, não para alta IO.

Como cada disco é regulado por IOPS (normalmente 500 / disco), você pode usar muitos deles (até 8 em A3) ou usar uma máquina da série D com SSD (D3: 12000IOPS). Note que você tem que usar o d-drive que não garante a persistência dos dados para ter velocidade SSD:

link

Ou você pode pagar $$$ e usar um blob de armazenamento premium (~ 100 $ / mês para 5000 IOPS) para ter um armazenamento persistente.

    

Answer 4

Nós movemos todo o nosso ambiente de produção para o Azure há cerca de 6 meses. Temos um servidor de compilação que executa várias compilações diariamente e, com base na duração das tarefas de compilação individuais, de compilar para compilar, posso dizer que "desempenho" é bastante consistente. Também posso confirmar suas descobertas de que processos que não utilizam vários núcleos (por exemplo, testes de unidade em execução) são executados cerca de 6 vezes mais lentamente em uma VM do Azure em comparação com um PC de desenvolvimento local.

Em resumo, quando você está executando processos em um único núcleo, sua máquina local sempre superará uma VM do Azure. Acho que o Azure é mais adequado para lidar com tarefas que envolvem vários núcleos (por exemplo, um banco de dados ou servidor da Web), porque você pode dimensionar facilmente os núcleos para cima / para baixo conforme necessário.