A hospedagem de meus sites e bancos de dados com provedores diferentes é uma má ideia?

Question

Estou tentando encontrar um lar para três sites do ASP.NET 3.5 usando três bancos de dados do SQL Server 2008. Eu encontrei uma solução possível onde eu hospedo os sites em um ambiente "semi-dedicado" com um provedor específico. O problema é que a parte do banco de dados deste serviço está faltando. Então, eu encontrei uma solução adicional onde eu hospedo os bancos de dados com um provedor diferente. Isso me mantém dentro do orçamento e com dois provedores eu respeito muito. Infelizmente, nenhum dos provedores me oferece hospedagem de site e banco de dados, como prefiro em um pacote.

Minha pergunta é esta:

1) Existe um downgrade definitivo do serviço se eu separar o site de hospedagem do banco de dados? Como antes de testar a possível latência, isso é uma má ideia? Alguém já fez isso com sucesso?

2) Existe uma boa maneira de testar a resposta do SQL Server entre os bancos de dados hospedados no mesmo provedor versus aqueles hospedados com um provedor diferente? Eu não sou bem versado em testar a resposta do site e do banco de dados pela Internet, então sou vaga sobre por onde começar.

    

Answer 1

1) Is there an definite downgrade of service if I separate the site hosting from the database hosting? As in, before I even test the possible latency, is this a bad idea? Has anyone done this successfully already?

Absolutamente. Eu fiz isso. Por um período de cerca de duas semanas, logo percebi que não ia funcionar.

2) Is there a good way to test the SQL Server response between those databases hosted on the same provider vs those hosted with a different provider? I'm not well-versed in testing site and database response over the Internet, so I'm vague on where to start.

É um pouco difícil fazer isso, a menos que você possa replicar a configuração sem entrar em um contrato. Talvez peça uma avaliação de 30 dias, ou obtenha um contrato mensal e cancele após o primeiro mês. Foi o que fiz com o meu provedor mais recente e ainda estou feliz com eles.

Quanto a como testá-lo, o SSMS tem um recurso interessante chamado "Estatísticas de Execução do Cliente" - é um botão na barra de tarefas quando você abre uma guia de consulta. Ligue, então execute a consulta, e isso lhe dará um ótimo detalhamento de quanto tráfego foi passado, quanto tempo ele gastou esperando que o servidor respondesse, etc.

Faça isso em servidores do site remoto > db e em servidores locais do site > db e compare os números.

    

Answer 2

Ter dois provedores de hospedagem que hospedam uma parte crítica do seu site duplicará as chances de inatividade. Se um deles falhar, seu site estará inativo. Essa é a maior preocupação.

A latência será sua segunda preocupação. Mais e mais dados estão migrando para os modelos de nuvem, portanto, não está fora de questão separar os papéis em provedores diferentes, mas introduz uma latência considerável.

Para entender o desempenho, você pode ver o SSMS local e remotamente. Se você tiver pequenos conjuntos de dados, ele poderá lidar com isso bem, mas, quando você começar a extrair muitos dados ou executar muitas consultas por página, o desempenho poderá cair rapidamente.

Para ferramentas de teste de estresse, as soluções da MS são WCAT ou Visual Studio Team System . Você também pode enviar para a sua página o registro de data e hora antes de fazer uma conexão com o banco de dados, depois e ao recuperar dados do banco de dados. Tente isso com dados de LAN e WAN para comparar.

Por fim, recomendo encontrar um host que possa manipular bem as duas partes. Quando eles podem apoiá-lo de ponta a ponta, eles não apontam os dedos uns para os outros quando você tenta diminuir os problemas de desempenho.