Desempenhos terríveis usando um Banco de Dados SQL do Azure remoto

Question

No momento, estamos avaliando o serviço Banco de Dados SQL do Azure (vs instalação local) porque gostaríamos de ter o recurso "Sempre Criptografado" integrado em nosso aplicativo (baseado em java).

O problema é que as performances são terríveis.

Estou conectando de um servidor físico localizado na mesma área (Paris) para o banco de dados criado na região "France Central".

Eu escrevi um aplicativo java muito simples que faz 5.000 inserções (instruções preparadas) em uma tabela muito simples, usando o driver jdbc da Microsoft e a string de conexão fornecida pelo Azure.

Demora quase um minuto para ser concluído, qualquer que seja o tipo de Banco de Dados SQL que eu uso (último teste com S6 Standard). O aplicativo java foi executado em um servidor de produção (8 núcleos). Eu esperaria alguma latência de usar um banco de dados remoto, mas não a este nível. (o mesmo teste está sendo executado em 5 segundos com o SQL Server no servidor local).

É o que é esperado? Eu pensei que o nosso caso foi o caso abordado pelo serviço de banco de dados SQL (servidor SQL remoto). Eu também criei uma VM na mesma região, conectando-me através do IP público do banco de dados, e foi quase tão ruim quanto. Eu tentei criar bancos de dados SQL em outros países europeus, e foi pior.

    

Answer 1

Parece razoável. Especialmente se as inserções estiverem sendo executadas em série. Quebrando:

Digamos que haja RTT de 30 ms entre o aplicativo e o servidor de banco de dados. Como o SQLServer é um banco de dados compatível com ACID e o driver de banco de dados o homenageia, a quantidade máxima teórica de TPS é de 33 por segundo, pois o driver bloqueará até receber um ACK do banco de dados. (1000ms / 30ms = ~ 33 TPS)

Você está atingindo cerca de 83 TPS, por isso acredito que a latência entre o servidor de aplicativos e o banco de dados seja de cerca de 12 ms.

No servidor local, você provavelmente tem intervalos de sub milissegundos.

Bancos de dados remotos são apenas uma má ideia. Mas se você tiver que fazer isso, tente agrupar as operações em uma única transação, pois você pode compactar mais dados em um salto RTT. Com isso dito, isso significa que uma falha é muito mais cara (tentar novamente 1 inserir vs repetir todos os 100). Leve tudo em consideração, mas qualquer coisa que você possa fazer para reduzir a latência (ou aumentar o paralelismo) fará uma diferença substancial.