Coloque seu SQL Server em um host dedicado. Você tem duas gerações de sistema operacional convidado executando aqui antes de obter acesso a um recurso físico. Você tem o hipervisor como o SO base, o Child Guest é o host do Windows Server, o sistema operacional do Grandchild é o SQL Server que captura blocos de disco e RAM e os gerencia com seu próprio namespace. Você pode atenuar parte disso se tiver discos dedicados e rede dedicada. Não permita que a VM seja relocável.
Você terá alguma arbitragem sobre recursos compartilhados, pois terá 32 GB alocados entre seus dois hosts, o que deixa precisamente zero para o hipervisor, para que o hipervisor comece a arbitrar o acesso para compartilhar segmentos enquanto deixa um bloco para si mesmo. Você teria um desempenho muito melhor se instalasse os dois componentes na mesma instância do sistema operacional e usasse um canal nomeado local para toda a comunicação entre o SQL Server e o SQL Server. Atualmente, você está cultivando muita sobrecarga para uma assinatura excessiva do host físico hipervisor, duas instâncias do SO e o sistema operacional neto em execução.
"Um único usuário faz 380 solicitações HTTP ..."
Presumivelmente, estes não são todos elementos dinâmicos e há muito fluff estático aqui na forma de imagens, folhas de estilo, JavaScript, fontes e afins. Obtenha um CDN na frente desses elementos estáticos, para que a carga caia para quase NIL na origem dos componentes estáticos. Você quer que os recursos e a carga sejam destinados exclusivamente à parte dinâmica, ao formulário enviado aos dados e não ao tratamento geral de arquivos. Porra, eu sugeriria que você deseja que a idade do cache no cliente seja pelo menos tão longa quanto a duração da implantação da sua compilação. Implante no sábado e meia-noite toda semana, depois faça a idade do cache expirar à meia-noite de sábado, mais uma semana a cada compilação. Isso manterá seu CDN bem distribuído e você poderá evitar os acessos, a carga da rede e a carga do servidor.