PERFORMANCE DA CONEXAO EM MSSQL CLOUD VIA ADO.NET
Olá, estou desenvolvendo uma aplicação VB.net que utiliza o SQL Server como base.
A estrutura básica é a seguinte:
Existe as camadas de Windows Forms, o projeto de controle e um projeto de acesso a dados usando ADO.net.
Aluguei um servidor Cloud na uol onde instalei o SQL Server e acesso a base na nuvem através da aplicação.
Trabalharei com uma massa razoável de registros listados em um grid em torno de 8mil registros de uma tabela de uns 10 campos.
PERGUNTA:
Como posso estimar a conexão do cliente com o servidor SQL no cloud? Pois as vezes da uma agarrada ao retornar os dados e percebo que o problema é causado pela conexão com a internet.
Testei com 3G para forçar a lentidão e comprovei.
Queria uma forma de mostrar a esta lentidão ao usuário para evitar reclamações de lentidão do sistema, uma vez que é quase certo que a lentidão virá da internet usada.
Espero ter sido claro rs
A estrutura básica é a seguinte:
Existe as camadas de Windows Forms, o projeto de controle e um projeto de acesso a dados usando ADO.net.
Aluguei um servidor Cloud na uol onde instalei o SQL Server e acesso a base na nuvem através da aplicação.
Trabalharei com uma massa razoável de registros listados em um grid em torno de 8mil registros de uma tabela de uns 10 campos.
PERGUNTA:
Como posso estimar a conexão do cliente com o servidor SQL no cloud? Pois as vezes da uma agarrada ao retornar os dados e percebo que o problema é causado pela conexão com a internet.
Testei com 3G para forçar a lentidão e comprovei.
Queria uma forma de mostrar a esta lentidão ao usuário para evitar reclamações de lentidão do sistema, uma vez que é quase certo que a lentidão virá da internet usada.
Espero ter sido claro rs
Citação:
...
Testei com 3G para forçar a lentidão e comprovei.
...
Hehehehe! Vejam que coisa, só aqui no Brasil mesmo. Não foi aqui que inventaram a [Ô]banda apertada[Ô]?
Bem, ao problema. O que ocorre é ausência de infraestrutura mesmo, concordo, mas o problema é que a infra atual sustenta uma demanda ocasional com folga. Em outras palavras, nós estamos [Ô]no meio do caminho[Ô]. Parte do problema é na distribuição, e parte é no uso final, ou seja, além das operadoras, os usuários também tem de melhorar muito ainda para suportar adequadamente os picos de acesso.
Contudo, recebemos o rótulo de suportável á bom, dado que a demanda média ser bem inferior á dos momentos de pico. Assim, em dados momentos, o problema da conexão vai resultar em uma demora alta, em outros, quase não se sentirá demora alguma.
Sim, há formas de efetuar esse nÃvel de testes no aplicativo, mas preste bem atenção: Incluindo esses testes, sua aplicação obrigatoriamente ficará duas vezes mais lenta do que o normal, pois ela irá avaliar a conectividade e depois ainda conectar, ou seja, o dobro do trabalho, sempre. E isso pode dar margens para o usuário questionar a validade do seu argumento, com perguntas como, por exemplo: [Ô]- Se é problema de rede/conexão, porquê o aplicativo XYZ é sempre mais rápido que o seu ?[Ô]
Deste modo, se pretende demonstrar ao usuário que o problema é este, ou seja, a conexão, eu pessoalmente sugiro que realize um trabalho de consultoria, aplicativo especÃfico para esse fim (separado do seu produto) e por um prazo de tempo abrangente, como, por exemplo, entre quatro semanas e dois meses, entre oito e dez horas por dia, coletando e datando dados das taxas de transferência. Com isso, você terá argumentação mais contundente, podendo apontar inclusive as médias, os horários e dias mais [Ô]complicados[Ô] etc.
Sei que conselho bom normalmente custa caro, mas ás vezes, uma dica simples como essa pode até ajudar.
Tópico encerrado , respostas não são mais permitidas