CONEXÕES ABERTAS API
Boa tarde,
Tenho uma API escrita em ASP.NET CORE e uso a biblioteca dapper e MYSQL. Tenho tipo 200 solicitações acontecendo simultaneamente, é correto abrir várias conexões no banco de dados ou teria que ter apenas uma?
A performance do meu banco está baixa, ele fica ai com média de 130 conexões. Por exemplo abre uma conexao, no banco ela tem o ID 400, se eu monitorar, eu vejo que várias pessoas diferentes conseguem utilizar essa mesma conexão, porém não entendo o motivo que a API fica abrindo essas conexões, ao meu entendimento todas deveriam usar a conexao de nº 400.
Não sei se é normal, só queria esclarecer.
Obrigado
Tenho uma API escrita em ASP.NET CORE e uso a biblioteca dapper e MYSQL. Tenho tipo 200 solicitações acontecendo simultaneamente, é correto abrir várias conexões no banco de dados ou teria que ter apenas uma?
A performance do meu banco está baixa, ele fica ai com média de 130 conexões. Por exemplo abre uma conexao, no banco ela tem o ID 400, se eu monitorar, eu vejo que várias pessoas diferentes conseguem utilizar essa mesma conexão, porém não entendo o motivo que a API fica abrindo essas conexões, ao meu entendimento todas deveriam usar a conexao de nº 400.
Não sei se é normal, só queria esclarecer.
Obrigado
Se voce está preocupado com isso( e sim, acho que pode afetar performance), veja isso
Pelos "jobs" que passei ao longo desses anos...Dapper era sempre o quebra galho para coisas complexas que LINQ e EF nativamente não resolvem.
Não se aplica nesse cenário usar o feijão com arroz ?
Desculpa pela ignorancia, mas sempre foram bds sql server, não sei se o EF sofre para realizar as mesmas tarefas no MySQL a ponto de só usar DAPPER
Não se aplica nesse cenário usar o feijão com arroz ?
Desculpa pela ignorancia, mas sempre foram bds sql server, não sei se o EF sofre para realizar as mesmas tarefas no MySQL a ponto de só usar DAPPER
Dando minha pequena contribuição.
GERENCIAMENTO DE CONEXÃO NO DAPPER
O dapper possui dois modos de gerenciamento de conexão: Automático e Manual.
O Manual é quando voce mesmo abre a conexão e depois usa os métodos de extensão do Dapper. No automático voce não abre a conexão, o Dapper internamente faz isso no método de extensão usado - porém, nesse caso - como ele mesmo abriu a conexão, ele também vai fechar logo depois de receber o retorno do banco de dados.
Então o primeiro ponto é:
Se voce for executar uma consulta isolada e quiser fechar a conexão, não precisa abrir a conexão manualmente;
Se voce for executar uma série de consultas sequenciais, voce provavelmente vai querer usar a mesma conexão, logo o ideal é abrir a conexão manualmente e evitar esse abre-e-fecha de conexões sequenciais.
TODOS OS USUÃÂRIOS DEVERIAM USAR A MESMA CONEXÃO COM O BANCO?
Primeiro ponto, estou supondo que voce está usando um provedor ADO.NET - e com isso, está com o pooling de conexões habilitado. Ele vem habilitado por padrão, a não ser que voce explicitamente desativou - e isso é bom. O motivo de ser bom é que voce não terá todo aquele processo lento de handshake ao estabelecer uma nova conexão, pois voce poderá usar uma conexão pré-estabelecida no pooling. Se voce desativou essa opção, eu recomendaria a reativação na grande maioria dos casos.
Mas mesmo reaproveitando uma conexão aberta do pooling, isso não significa que voce usará a mesma conexão em toda a aplicação. A quantidade de conexões abertas vai depender da concorrencia da sua aplicação ao abrir novas conexões. Vamos supor que voce abriu 10 novas conexões ao mesmo tempo. Se são 10 conexões simultâneas, voce fatalmente vai acabar estabelecendo 10 conexões de socket com seu banco de dados. Agora vamos supor que após essas 10 conexões, mais 5 usuários concorrentemente solicitam novas conexões com o banco. Possivelmente o ADO.NET pegará 5 conexões do seu pooling (das 10 usadas anteriormente) - mas voce ainda teria essas 5 conexões abertas paralelamente.
Repare então que para voce ter uma conexão ativa por vez na sua aplicação voce não pode ter concorrencia no banco de dados, logo, diminuiria extremamente a escalabilidade da sua aplicação - possivelmente voce teria que ficar controlando a concorrencia através de um Mutex, Semaphore Slim, lock, entre outros ... a conexão com o banco. E isso criaria uma fila que não pararia de aumentar - até sua aplicação começar a pipocar erro.
Então a resposta é Não. Voce provavelmente não quer limitar sua aplicação a usar sempre a mesma conexão.
QUANDO A QUANTIDADE DE CONEXÕES ABERTAS É PREOCUPANTE?
Como falei, se voce possui 200 requisições paralelas ao banco de dados, é inevitável que a quantidade de conexões esteja também nessa faixa. Agora, se voce está executando apenas 10 requisições e existem 100 conexões ativas, isso pode ser um problema. Pois pode significar que voce está abrindo várias conexões dentro de uma mesma requisição (que possivelmente poderiam aproveitar a conexão já aberta) ou voce pode estar esquecendo conexões abertas em algum lugar.
Por isso é bom analisar o tempo de vida da conexão também. Mas tenha em mente que o pooling poderá deixar uma conexão ativa ociosa por baixo dos panos de 4 a 8 minutos.
GERENCIAMENTO DE CONEXÃO NO DAPPER
O dapper possui dois modos de gerenciamento de conexão: Automático e Manual.
O Manual é quando voce mesmo abre a conexão e depois usa os métodos de extensão do Dapper. No automático voce não abre a conexão, o Dapper internamente faz isso no método de extensão usado - porém, nesse caso - como ele mesmo abriu a conexão, ele também vai fechar logo depois de receber o retorno do banco de dados.
Então o primeiro ponto é:
Se voce for executar uma consulta isolada e quiser fechar a conexão, não precisa abrir a conexão manualmente;
Se voce for executar uma série de consultas sequenciais, voce provavelmente vai querer usar a mesma conexão, logo o ideal é abrir a conexão manualmente e evitar esse abre-e-fecha de conexões sequenciais.
TODOS OS USUÃÂRIOS DEVERIAM USAR A MESMA CONEXÃO COM O BANCO?
Primeiro ponto, estou supondo que voce está usando um provedor ADO.NET - e com isso, está com o pooling de conexões habilitado. Ele vem habilitado por padrão, a não ser que voce explicitamente desativou - e isso é bom. O motivo de ser bom é que voce não terá todo aquele processo lento de handshake ao estabelecer uma nova conexão, pois voce poderá usar uma conexão pré-estabelecida no pooling. Se voce desativou essa opção, eu recomendaria a reativação na grande maioria dos casos.
Mas mesmo reaproveitando uma conexão aberta do pooling, isso não significa que voce usará a mesma conexão em toda a aplicação. A quantidade de conexões abertas vai depender da concorrencia da sua aplicação ao abrir novas conexões. Vamos supor que voce abriu 10 novas conexões ao mesmo tempo. Se são 10 conexões simultâneas, voce fatalmente vai acabar estabelecendo 10 conexões de socket com seu banco de dados. Agora vamos supor que após essas 10 conexões, mais 5 usuários concorrentemente solicitam novas conexões com o banco. Possivelmente o ADO.NET pegará 5 conexões do seu pooling (das 10 usadas anteriormente) - mas voce ainda teria essas 5 conexões abertas paralelamente.
Repare então que para voce ter uma conexão ativa por vez na sua aplicação voce não pode ter concorrencia no banco de dados, logo, diminuiria extremamente a escalabilidade da sua aplicação - possivelmente voce teria que ficar controlando a concorrencia através de um Mutex, Semaphore Slim, lock, entre outros ... a conexão com o banco. E isso criaria uma fila que não pararia de aumentar - até sua aplicação começar a pipocar erro.
Então a resposta é Não. Voce provavelmente não quer limitar sua aplicação a usar sempre a mesma conexão.
QUANDO A QUANTIDADE DE CONEXÕES ABERTAS É PREOCUPANTE?
Como falei, se voce possui 200 requisições paralelas ao banco de dados, é inevitável que a quantidade de conexões esteja também nessa faixa. Agora, se voce está executando apenas 10 requisições e existem 100 conexões ativas, isso pode ser um problema. Pois pode significar que voce está abrindo várias conexões dentro de uma mesma requisição (que possivelmente poderiam aproveitar a conexão já aberta) ou voce pode estar esquecendo conexões abertas em algum lugar.
Por isso é bom analisar o tempo de vida da conexão também. Mas tenha em mente que o pooling poderá deixar uma conexão ativa ociosa por baixo dos panos de 4 a 8 minutos.
Faça seu login para responder