Sistema de CRM / CMS / SCM / Call Center mal projetado, desenvolvido usando C # / ASP.NET / MS SQL Server.
O problema que tenho com isso é que o cliente está usando este sistema em produção e está se aproximando de um período muito ocupado. O negócio é semi-sazonal e isso significa que é fundamental que o sistema esteja ativo durante esse período. Todos os acima mencionados executar a partir de um banco de dados núcleo usando o SQL server e por causa de instruções SQL ridiculamente mais complicadas / grandes o banco de dados sever está levando esforço grande.
O servidor em si é bastante impressionante 16GB Ram e 16 poder de processamento do núcleo. No momento, isso mal dá conta. Então, durante o período agitado, ele vai cair. Basicamente não há tempo para corrigir programaticamente o problema. Precisamos lançar hardware no problema.
Isso me leva à minha pergunta, para implementar o balanceamento de carga SQL. Preciso fazer algum trabalho de desenvolvimento ou há uma maneira de balancear a carga sem fazer nenhum desenvolvimento? O ISP que hospeda o servidor avisou que precisaremos fazer algum desenvolvimento.
O maior gargalo em um sistema de banco de dados arbitrário é sempre o disco I / O *.
16 núcleos? pffft. Você também tem 16 discos sendo executados no raid-10?
Se não, pegue-os.
-
* É claro que você não mostra absolutamente nenhuma métrica de desempenho, portanto, caso esteja curioso sobre os conselhos que podemos dar, comece a coletar dados de desempenho e mostre-os.
De fato, até que você faça, você não pode provar que existe um problema
Não há armazenamento persistente de balanceamento de carga. Você pode particionar o armazenamento (sharding), que funciona apenas para domínios problemáticos muito restritos ou para aplicativos projetados explicitamente para scale-out desde o início, você pode dimensionar leituras usando stand-by legível (replicação, envio de log, espelhamento + snapshots, AlwaysOn), que funciona para relatórios com atraso aceitável de back-in-time, e existem até mesmo de esquemas de replicação master-master complicados, que não funcionam.
Portanto, a opção somente é para corrigir o aplicativo ou reforçar o banco de dados. A correção de aplicativo sempre gera os melhores resultados, mas requer que você tenha acesso a um recurso muito raro (bons desenvolvedores) e a tempo. A outra alternativa, que nunca corresponderá ao resultado de consertar o aplicativo, é reforçar o banco de dados. O que requer que você identifique o gargalo. Esperas e filas é uma excelente metodologia, comprovada para produzir resultados quando aplicada corretamente. Se você não tem ideia de como fazer isso, entre em contato com um profissional respeitável e peça ajuda.