Problema:
Tentando obter o mesmo (ou melhor) desempenho com um servidor SQL Server 2017 e IIS 7.5 separado do que com os dois na mesma máquina.
Tentando avançar para a escalabilidade para crescimento futuro.
Usando o WebSurge para testar o avanço na mesma caixa que executa o IIS e o SQL Server 2017 Developer com 32 GB de RAM em 6 núcleos e 12 processadores lógicos, não há grandes problemas de desempenho na máquina. Podemos executar o código abaixo no WebSurge a uma taxa de 4000 solicitações por segundo com grande velocidade.
O problema:
Assim que executamos o mesmo código em uma caixa separada do IIS e em um SQL Server separado na mesma conexão gigabit na LAN local, só podemos obter cerca de 350 solicitações por segundo no IIS sendo executado em sua própria caixa. Observação: o SQL Server está usando < 1% da CPU na caixa em que está sendo executado com essas 350 solicitações, portanto, não é um problema com a consulta ou o desempenho do SQL Server, pois o mesmo código é executado em 4000 com o IIS na mesma máquina .
Os cabos da LAN estão conectados ao mesmo switch e o PING é sempre < 1ms do IIS para o SQL Server.
O que estamos fazendo errado quando os pedidos concluídos diminuem drasticamente, mas quando são executados novamente na mesma caixa do IIS / SQL Server ... são mais de 4000 por segundo.
Estamos planejando criar um serviço grande em breve, pois o tráfego da Web excederá bem mais de 4.000 solicitações por segundo, portanto, precisaremos de servidores adicionais, balanceadores de carga etc. Atualmente, estamos tentando entender por que só podemos atender a 350 solicitações por segundo. uma caixa do IIS, não na mesma máquina que o servidor.
Também indicarei que a CPU não está em nenhum lugar acima de 50% em nenhum cenário.
O SQL Server consome apenas aproximadamente 10% ao executar este código.
<%
rangedb="Provider=SQLOLEDB;" & _
"Data Source=10.10.1.220,1433;" & _
"Initial Catalog=xxxxxxx;" & _
"Network=DBMSSOCN;" & _
"User Id=xxxxxx;" & _
"Password=xxxxxx"
set cnn = Server.CreateObject("ADODB.Connection")
set rst = Server.CreateObject("ADODB.RecordSet")
cnn.open rangedb
sqltext = "SELECT page_content,template_id FROM master_templates_data where (template_id='165' or template_id='166' or template_id='167' or template_id='168' or template_id='169' or template_id='170' or template_id='171' or template_id='172' or template_id='173' or template_id='182' or template_id='183' or template_id='184' or template_id='185' or template_id='186' or template_id='187' or template_id='188' or template_id='189')"
rst.CursorLocation=2
rst.CursorType=0
rst.LockType=1
rst.Open sqltext,cnn
dataArray = rst.GetRows()
rst.close
cnn.close
%>
Nós procuramos em toda a Internet e não conseguimos encontrar uma razão para isso.
Qualquer ajuda seria apreciada!
(Sim, sabemos que o ASP clássico não é o caminho a percorrer para um projeto como este, mas gostaríamos de resolver este problema para as nossas situações atuais)
Se houver uma alternativa melhor, como MySQL e PHP / Linux, estaremos abertos para saber como o desempenho seria melhor.
Esta é a nossa primeira vez postando aqui, então seja gentil:)
Além disso, tentamos executar o SELECT 1 como a consulta e ele aumenta para cerca de 800 rps na caixa separada do IIS, mas passa para 14.000 na caixa onde o IIS e o SQL residem juntos.
Tentando descobrir onde a quebra de velocidade está ocorrendo, já que estamos em uma intranet de gigabit, as caixas estão conectadas ao mesmo switch e o ping é < 1ms
Nenhum vírus ou firewall estão ativados atualmente para esse teste para descartá-los também.
ATUALIZAÇÃO:
Eu segui em frente e liguei 2 computadores diretamente uns aos outros e também os coloquei no mesmo switch e executei um teste de throughput e consegui atingir pouco menos de 1gb de velocidade com transferência de dados (sem transferência de arquivos) par parece.
Eu também reran o teste do servidor da Web e obtive cerca de 900 solicitações por segundo processadas com o IIS em uma caixa separada usando outro computador.
Parece que o IIS ASP e o SQL em duas máquinas diferentes estão sendo executados 4 vezes mais lentamente usando o mesmo script e software de quando estão sendo executados na máquina local.
O banco de dados está puxando de uma unidade de estado sólido, portanto a velocidade da unidade não deve ser o problema, pois também seria o problema localmente (o driver reside na máquina do servidor SQL e não em um servidor de arquivos)