INF: Cliente efeitos na taxa de transferência do SQL Server

Traduções deste artigo Traduções deste artigo
ID do artigo: 180775 - Exibir os produtos aos quais esse artigo se aplica.
Este artigo foi arquivado. É oferecido "como está" e não será mais atualizado.
Expandir tudo | Recolher tudo

Neste artigo

Sumário

Na avaliação de áreas gerais que afetam o desempenho, mais comumente considerados aspectos são velocidade do processador, E/s de disco e memória no servidor. Embora o desempenho dessas partes do servidor sejam crucial para desempenho adequado, você também deve considerar a latência da rede e tempo de processamento de cliente como fatores que também pode ter um impacto significativo no desempenho geral do sistema.

Este artigo discute as áreas último e fornece diretrizes para avaliar o impacto que podem ter no servidor.

Mais Informações

O exemplo a seguir será usado em todo o documento. As etapas para as duas conexões de executar a mesma atualização com apenas uma pequena diferença na sintaxe do Transact-SQL.

Conexão 1

use pubs
go
select convert(char(30), GetDate(), 9) "Start Time"
go

            Begin transaction

   Go   ==>   Send to SQL Server and process results

            Update authors set au_lname = au_lname

   Go   ==>   Send to SQL Server and process results

Commit / Rollback transaction

   Go   ==>   Send to SQL Server and process results

select convert(char(30), GetDate(), 9) "End Time"
go
				

Conexão 2

use pubs
go
select convert(char(30), GetDate(), 9) "Start Time"
go
begin transaction
if(0 = @@ERROR)
begin
   update authors set au_lname = au_lname
   if(0 = @@ERROR)
   begin
      commit transaction
   end
   else
   begin
      rollback transaction
   end
end
go    ==>   Send to SQL Server and process results
select convert(char(30), GetDate(), 9) "End Time"
go
				

Rede Round Trips

Conexão 1 requer três viagens ao computador do SQL Server:
  • Iniciar transação
  • Atualização
  • Confirmar / Reverter transação
Conexão 2 requer uma única viagem para concluir a atualização.

Cancelamento de consulta

Biblioteca de banco de dados e as APIs ODBC oferecem suporte processamento de consultas assíncronas. Por exemplo, a biblioteca do banco de dados usa a função dbdataready para permitir que o cliente pesquisar o status de conclusão da consulta.

Na biblioteca de banco de dados, a função dbdataready é controlada pelo valor DataReadySleep. Para obter informações adicionais sobre a chave do Registro DataReadySleep, consulte o seguinte artigo na Base de dados de Conhecimento da Microsoft:
159234: INF: como alterar o valor de suspensão usado pelo Dbdataready

Como horas de suspensão afetam os intervalos

Por padrão, o valor de suspensão é 250 milissegundos.

Conexão 1 faz três viagens arredondadas para o SQL Server. Por padrão, o cliente encontra um mínimo de 750 milissegundos do tempo de espera, não contando o tempo para a transferência de rede real. O tempo de espera é calculado a partir (250 milissegundos * 3) = 750 milissegundos.

Conexão 2 faz uma única viagem e encontra um mínimo de 250 milissegundos do tempo de espera, não contando o tempo de transferência de rede real.

Você pode alterar a velocidade deste exemplo por um fator de três, simplesmente, aproveitando a sintaxe do Transact-SQL e removendo dois rede viagens de ida e volta.

Como viagens de ida e volta pela rede afetam outros usuários

Conexão 1 contém uma transação aberta para um mínimo de 500 milissegundos. Depois que a transação for aberta, leva 500 milissegundos para concluir a atualização e, em seguida, confirmar ou reverter a transação. Simultaneidade de banco de dados impede que outros usuários acessem os registros que você está modificando.

Conexão 2 mantém a transação aberta somente desde conforme necessário para concluir a operação. Em um computador único processador do Pentium 133-MHz com SQL Server e ISQL/w, os intervalos a seguintes são vistos.

Observação: A E/s de rede final não é mostrado em um dos exemplos a seguir. Após a confirmação ou reversão foi concluída os bloqueios são lançados, mas a E/s final não é computadas.
   Begin transaction                5 milliseconds
   Update                          20 milliseconds
   Commit/Rollback transaction      7 milliseconds
      TOTAL                        32 milliseconds
				

Conexão 2 será concluída em aproximadamente 32 milissegundos, enquanto Connection 1 requer uma janela de processamento muito maior e estende bastante o tempo de latência de transação.
   Begin transaction                5 milliseconds
   Network I/O                    250 milliseconds
   Update                          20 milliseconds
   Network I/O                    250 milliseconds
   Commit/Rollback transaction      7 milliseconds
      TOTAL                       532 milliseconds
				

Como mostrado anteriormente, o tempo de rede é um simples fator de três. No entanto, o impacto de bloqueio que impõe o exemplo em outros usuários de banco de dados é um fator de 16 (532/32 = ~ 16).

Agora vamos dizer que esse exemplo simples é de um computador portátil remoto se conectar com um modem de 28,8. Além do atraso de milissegundos 250 impostas pelo parâmetro dbdatareadysleep, o tempo gasto para transmitir, na verdade, as informações sobre o link lento é appreciable. Conexão 1 afetaria outros usuários do banco de dados por um fator ainda maior, enquanto a conexão 2 seria afetado principalmente pela velocidade do computador cliente. O comando é enviado uma vez, processados no SQL Server em 32 milissegundos. O único usuário do sistema que apresenta uma lentidão é o usuário remoto, que é como esperado, devido a modem lento.

Tempo de latência do cliente

Tempo de latência do cliente é o período de tempo decorrido enquanto o cliente processa os resultados que ele recebeu. Se você olhar novamente Connection 1, você pode ver rapidamente como isso pode afetar o processo. Se um extra 10 milissegundos são necessários para o cliente lidar com um conjunto de resultados, você poderá adicionar outra milissegundos 30 ao tempo de transação geral e outra 20 milissegundos do tempo de latência de transação.

Vamos alternar exemplos novamente. Nesse caso é uma tabela de estoque de um sistema online. Você gastou meses desenvolvendo e instalar o que deve ser o sistema de processamento de pedidos on-line mais rápidas no histórico. Os usuários podem pesquisar, comprar e manter um carrinho de compras, entre outras opções. Esta é a tabela tbllnventory:
   tblInventory
      iProductID       int
      strTitle         varchar(50)
      strDescription   varchar(255)
      iSize            int
      iInStock         int
      iOnOrder         int
      iType            int
				

Desejo algumas cereal de compra. No entanto, eu gostaria de ver o que está disponível. Podemos definir cereal digitar 2, para que o aplicativo emite a consulta a seguir. Neste exemplo, o banco de dados contém 750 cereal-itens relacionados.
   Select strTitle, strDescription, iSize, iInStock from tblInventory
   where iType = 2
				

O SQL Server irá compilar e analisar a consulta e, em seguida, começar a retornar os resultados. Compartilhada bloqueios são adquiridos em páginas apropriadas. Lembre-se de que compartilhada bloqueios bloco de atualização, inserir e excluir operações.

Ao mesmo tempo, como seu aplicativo é usado em todo o país, seis outras pessoas estão tentando colocar cereal ordens.

SQL Server preenche o primeiro pacote fluxo (TDS) tabular data, ele envia ao cliente e aguarda, em seguida, o cliente processar os resultados. Durante o tempo que o cliente está processando os resultados (tempo de latência de cliente), SQL Server continua manter um bloqueio de página compartilhada da página onde estava processando. Esse bloqueio compartilhado pode bloquear um usuário que está tentando concluir um pedido.

Ele parece uma simples ação. Selecione um conjunto de resultados do SQL Server e inserir os valores em uma caixa de lista. Um computador Pentium de 133-MHz pode adicionar 750 itens a uma caixa de listagem em pouco mais de um segundo. Desativar a caixa de listagem ao arquivamento ele leva apenas um terço de um segundo. Você pode diminuir significativamente o tempo de latência do cliente, simplesmente desabilitando a caixa de listagem.

Você mesmo pode ser decidido alterar a operação de seleção para reduzir ainda mais o bloqueio. Limite a exposição de bloqueio compartilhado alterando a consulta para o seguinte.
   Insert * into #tblSelect from
   Select strTitle, strDescription, iSize, iInStock from tblInventory
				

   Select * from #tblSelect
				

A consulta é isolada no SQL Server e não será iniciado retornando resultados até que eles foram movidos para a tabela temporária e todos os bloqueios compartilhados são liberados de tabela de estoque. Isso limita o tempo que bloqueios compartilhados são mantidos na tabela de estoque para o tempo necessário para o SQL Server mover os resultados para tempdb. O controle é novamente com o banco de dados e não no cliente.

Outra maneira de realizar comportamento semelhante é fazer com que um cliente "inteligente". Em vez de preencher uma caixa de listagem, pode ser mais rápido carregar uma matriz. No entanto, você ainda tem preocupações sobre sendo vinculados por taxa de transferência da rede. A tabela temporária é uma solução melhor nessas situações.

Como você pode ver, o cliente pode executar um rolo essencial na taxa de transferência banco de dados. Você deve estar especialmente cuidado ao trabalhar com sistemas remotos e relatórios. O período de tempo que o cliente usa para processar resultados mantendo bloqueios tem o potencial de afetar a taxa de transferência banco de dados. Esses tipos de problemas podem ser difícil ver com o procedimento armazenado sp_who e disco rígido ver como os períodos de latência podem ser intervalos de 100 milissegundos. Use um vínculo lento para ver rapidamente o comportamento. Execute o aplicativo de um link RAS e ver o comportamento geral como. Você também pode se beneficiar do utilitário de rastreamento SQL para perfil cuidadosamente o aplicativo.

Para obter informações adicionais, leia os seguintes artigos na Base de dados de Conhecimento da Microsoft:
165951: INF: resultado processamento para o SQL Server

172117: INF: como perfil código de Transact-SQL em procedimentos armazenados e disparadores

162361: INF: Noções básicas sobre e resolvendo problemas de bloqueio do SQL Server

167610: INF: Avaliando degradação de desempenho de consulta

48712: INF: manipulação tempos limite corretamente na biblioteca de banco de dados

117143: INF: quando e como usar dbcancel() ou sqlcancel()

Propriedades

ID do artigo: 180775 - Última revisão: segunda-feira, 7 de outubro de 2013 - Revisão: 3.0
A informação contida neste artigo aplica-se a:
  • Microsoft SQL Server 6.5 Standard Edition
Palavras-chave: 
kbnosurvey kbarchive kbmt kbinfo KB180775 KbMtpt
Tradução automática
IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine Translation ou MT), não tendo sido portanto traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 180775

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com