Eu suspeito que nessa taxa de trabalho, outras partes do sistema começarão a gemer. Esse problema pode ser mais economicamente servido usando um farm de servidores em vez de um único animal.
Recentemente, minha contagem de usuários aumentou e meu servidor atual começou a ficar insuficiente. Estou pensando em comprar CPUs AMD de 4 x 8 = 32 núcleos usando um servidor dedicado. Gostaria de saber como é bom o ASP.NET 4.0 e o MS SQL 2008 Web Server em multithreading.
Eles podem usar 32 núcleos com capacidade de 100% ou eu devo comprar no máximo 24 núcleos ou 16 núcleos?
(Esta máquina será executada no Windows Server 2008 Standard Edition.)
A resposta - tecnicamente 100% da capacidade é um sonho devido à sobrecarga de gerenciar mais trabalho, mas o MS SQL Server 2008 é muito bom em escalar núcleos / processadores ... Aqui está o gráfico de capacidade: link
Eu me arriscaria a adivinhar que você estará perseguindo gargalos ao reforçar um único sistema de tipo caixa grande e é bem possível que as adições de CPU não façam nada se seu gargalo atual for memória ou drive's.
O dinheiro gasto em CPU's (e os correspondentes custos de licença de SQL) provavelmente serão mais bem aproveitados, gastando em maximizar toda a memória disponível primeiro. Então olhe para drives mais rápidos (SSD talvez?) Obviamente, assegure-se de que quaisquer problemas de rede sejam tratados, se ainda não foram examinados. Mas a coisa mais importante é o código / design. O tempo gasto na otimização do código existente provavelmente lhe dará o maior retorno possível.
No entanto, minha principal recomendação - gastar uma quantidade relativamente pequena de dinheiro em uma auditoria de um profissional de SQL. Deixe-os dar-lhe um resumo do que seria a melhor solução para o seu problema único.
Boa sorte!
Você pode fornecer mais informações sobre o número de solicitações que você recebe em uma hora ou dia? Qual hardware você tem atualmente? Onde está o gargalo atualmente? É CPU ou E / S?
O ASP.NET pode usar todos os núcleos. O MS SQL 2008 pode usar todos os núcleos e qualquer quantidade de memória que você permitir.
O problema nunca é com o software Servidor, mas sempre com o código que você escreve (ou seja, o aplicativo ASP.NET) e a maneira como você projetou seu banco de dados (tanto o banco de dados lógico quanto físico) e as consultas que você escreve etc.
A partir da experiência com a otimização de grandes sites de domínio público posso dizer-lhe que o seu servidor web não é onde as coisas estão a abrandar. Geralmente, é como o aplicativo é projetado e codificado e como o banco de dados foi projetado.
Você deve coletar muitos dados sobre o uso do seu hardware atual e criar um perfil do seu aplicativo asp.net e do banco de dados para ver o que causa o estresse.
Uma vez que você sabe o que causa o estresse, a solução pode ser apenas que você precisa limpar seu código / banco de dados um pouco.