Considerações sobre Desempenho para Aplicativos usando Serviços
Este tópico discute as otimizações de desempenho ao usar associação, funções, propriedades de perfil, estado de sessão, personalização de Web Parts e navegação de site no ASP.NET.
Associação
Esta seção inclui informações sobre como usar a associação do ASP.NET com eficiência.
Coletar Listas de membros com Eficiência
Ao chamar métodos da classe Membership, chame os métodos sobrecarregados que usam membros PageIndex e PageSize.Esses sobrecargas executam mais rápido porque elas resultam em menos dados sendo transferidos pelo servidor Web.Um exemplo é o método GetAllUsers da classe Membership.Chamar o método GetAllUsers sem nenhum parâmetro retorna todos os usuários da associação.Por outro lado, chamar a sobrecarga GetAllUsers retorna apenas uma página de usuários, reduzindo a quantidade de dados processados pela página.
Armazenar os Resultados em Cache ao Obter o Número de Usuários On-line
Você pode chamar o método GetNumberOfUsersOnline para exibir o número de usuários considerados ativos no site da Web.Este método examina cada linha na tabela de associação cada vez que o método é chamado, o que pode ser uma significativa penalidade de desempenho se o número de usuários no banco de dados for grande.Chamar o método somente quando necessário e armazene em cache o valor por um período de tempo se você não precisar de uma contagem exata.
Funções
Por padrão, a GetRolesForUser método é chamado automaticamente toda vez que uma página é carregada, e retorna as funções de usuário. As funções são armazenadas em um dicionário no RolePrincipal objeto. Enquanto o página da Web é executada, a verificação de funções é feita usando este dicionário.Para impedir o acesso ao provedor para cada página de carregada e assim reduzir o tempo de processamento do servidor, defina o atributo CacheRolesInCookie no arquivo Web.config do aplicativo para true.Isso faz com que a lista de funções do usuário seja armazenada em um cookie.Nos carregamentos de página subsequentes, informações de função podem ser lidas do cookie em vez de usar uma chamada para o provedor.
O método GetRolesForUser, a propriedade IsInRole e o método GetRoles podem ser usados no código para verificar a associação a uma função.Compreendendo como interagem esses métodos, você pode escrever código para o aplicativo que funcione de forma mais eficiente para a tarefa que você precisa executar.
O método GetRolesForUser sempre acessa o provedor.Uma chamada para o método IsInRole sempre resulta em uma chamada para o método GetRolesForUser na primeira solicitação para uma página quando o cache por cookie não está habilitado.Se o cache por cookie estiver ativado, chamadas para o método IsInRole usará as informações de função armazenados no cookie.A primeira chamada para o método GetRoles resulta em uma chamada para o método GetRolesForUser independentemente do cache por cookie estar ou não ativado.Apesar disso, chamadas subsequentes ao método GetRoles em uma página usarão as informações de função armazenadas em cache dentro de RolePrincipal.
.gif "Observação") Observação: |
|---|
Armazenar informações sigilosas em um cookie pode expor essas informações para os usuários.Para obter segurança máxima, não habilite o cache de cookie. |
Propriedades de Perfil
Se o seu código acessar qualquer propriedade de perfil, quando a página for carregada, o provedor de perfil lê todas as propriedades de perfil para o usuário atual.(Especificamente, o provedor lê todas as propriedades que são associadas a esse provedor de perfil.) Se quaisquer valores da propriedade do perfil forem alterados, as novas as informações são gravadas de volta no armazenamento de dados do provedor quando a página descarregar.O ASP.NET pode determinar se tipos intrínsecos, como números inteiros e cadeias de caracteres foram alterados, mas não podem determinar se tipos não intrínsecos foram alterados.
O algoritmo para determinar se as propriedades de perfil foram salvos é o seguinte:
Se todos os tipos de propriedades de perfil são tipos intrínsecos e nenhum deles foi alterado, o perfil não será gravado no armazenamento de dados.
Se todos os tipos de propriedades de perfil são tipos intrínsecos e algum deles foi alterado, todos os valores de propriedade do perfil serão gravados no armazenamento de dados.
Se qualquer propriedade é um tipo não intrínseco, o ASP.NET não pode determinar se um valor foi alterado.Se a propriedade for acessada no código, o valor da propriedade será gravada no armazenamento de dados.
Observação:Em todos os casos, a decisão se aplica a todas as propriedades do perfil para um provedor específico.
Se você estiver usando tipos de propriedades não intrínsecas, gravar os dados de perfil no final de cada solicitação de página leva tempo.Você pode mitigar essa sobrecarga das seguintes maneiras:
Usar apenas tipos intrínsecos nos perfis.
Definir o atributo automaticSaveEnabled no elemento de configuração <profile> como Off e escrever código personalizado para detectar as alterações e salvar os valores de propriedade quando necessário.
Escrever o código personalizado para manipular o evento ProfileAutoSaving e no código do evento, determinar se qualquer alteração ocorreu às propriedades do perfil.Se nenhuma propriedades foi alterada, cancele o salvamento operação automático e defina a propriedade ContinueWithProfileAutoSave do evento como false.
Session State (Estado da sessão)
O desempenho é uma consideração ao usar qualquer modo de estado de sessão fora de processo (out-of-process) (para obter mais informações, consulte Modos de estado de sessão).Esta seção fornece informações sobre como otimizar o desempenho do estado de sessão.
Reduzindo a Sobrecarga gerada pela Leitura e Escrita no Estado da Sessão
Por padrão, as informações do estado da seção são carregadas a cada carregamento de página.O atributo EnableSessionState na diretiva @ Page permite que você controle o carregamento do estado de sessão com as seguintes configurações:
True Dados do estado da sessão são lidos a cada carregamento de página e salvos se eles foram alterados.O ASP.NET pode determinar se tipos intrínsecos como números inteiros e cadeias de caracteres foram alterados.Se todos os valores estado de sessão são tipos intrínsecos e nenhum tenha sido alterado, a sessão não será salva.Se qualquer um do valores for um tipo não intrínseco, e qualquer valor não intrínseco for acessado, então todas as informações do estado da sessão são salvas.Isso é porque o ASP.NET não controla se tipos intrínsecos foram alterados e toma a opção mais segura, salvando todos os dados.
False Dados do estado da sessão não são lidos quando a página for carregada.
ReadOnly Dados do estado da sessão são lidos a cada carregamento de página mas nunca salvos, mesmo se uma alteração é feita no código para valores do estado da sessão.
Evitando Disputas de Bloqueios para Estado de Sessão
Evite utilizar elementos <IFRAME> nas páginas que exigem estado de sessão.Se várias solicitações são feitas ao ASP.NET com o mesmo identificador de estado da sessão, e se as solicitações são todos para páginas ASP.NET onde EnableSessionState é definida como true, então as solicitações paralelas irão competir umas com as outras pelo bloqueio que está associado com o estado de sessão fora de processo.No caso de elementos <IFRAME>, isso significa que páginas ASP.NET exibidas em vários elementos <IFRAME> em uma página podem potencialmente competir pelos mesmos dados de sessão.O resultado é que cada solicitação separada será serializada no servidor.
Personalização das Web Parts
Quando uma página é executada, informações de personalização do ASP.NET são carregadas.Para determinar se as informações de personalização Web Parts foi alterada, o ASP.NET chama o método Equals para comparar os valores antigo e novo de propriedades marcadas com o atributo PersonalizableAttribute.
Se qualquer valor de propriedade de personalização tiver sido alterado, os dados de personalização serão salvos.Para tipos intrínsecos como números inteiros, o método Equals compara os valores antigo e novo da propriedade diretamente.No entanto, para tipos não intrínsecos, ASP.NET compara o valor da referência, mas não necessariamente dos dados mantidos por uma instância do tipo.
Por exemplo, para uma propriedade do tipo ArrayList, o método Equals compara os valores antigo e novo da referência ArrayList, mas não o conteúdo do objeto ArrayList.O método Equals retornaria true se a referência ArrayList não tivesse sido alterada, mesmo que um novo item tivesse sido adicionado à lista.Nesse caso, os dados da ArrayList não poderiam ser salvos.
Esse algoritmo para tipos intrínsecos é eficiente, mas falha na parte de não salvar os dados.Se você desejar salvar os dados de um tipo não intrínsecos como um objeto ArrayList, defina a propriedade IsDirty como true se o controle é derivado de WebPart, ou chame o método SetPersonalizationDirty que leva um controle como um parâmetro.
Navegação do Site
Mapas de sites grandes terão desempenho reduzido quando comparado a mapas de site menores.Por exemplo, em cenários testes, aumentar o número de nós de 100 a 1.000 (um aumento de 10 vezes) pode aumentar o tempo de carregamento de uma página por cerca de um terço.
Restrições de segurança, que filtram os nós com base em funções, tem uma penalidade de desempenho maior que o aumento do número de nós.Por exemplo, um mapa de site com 1000 nós tem 10 vezes mais processamento extra do que um mapa do site com 100 nós.
Algumas recomendações para reduzir esse efeito são:
Quando restrições de segurança estiverem ativadas, o número máximo recomendado de nós é 150.
Defina o atributo Roles em cada nó do mapa do site.Quando esse atributo funções existe, o ASP.NET pode ignorar a URL e autorização de arquivo para a URL que está associado com o SiteMapNode, desde que um usuário pertence a uma das funções que está listada no atributo.No entanto, observe que se um usuário não pertencer a qualquer uma das funções especificadas, então o ASP.NET voltará às verificações de autorização de arquivo e de URL mais lentas.
Criar uma classe que herda da classe SiteMapProvider e substitua o método IsAccessibleToUser para verificar somente o atributo Roles em cada nó do mapa do site.Isso acelera o processo de filtragem já que ela ignora a autorização de URL e de arquivo.No entanto, essa abordagem requer duas definições paralelas de segurança em um aplicativo Web.A primeiro é as informações de autorização no arquivo Web.config (e listas de controle de acesso NTFS para autorização de arquivo se a autenticação do Windows estiver ativada).A segunda é as informações de função no mapa do site.Você deve avaliar a sobrecarga de gerenciamento de segurança ao dividir as informações de segurança contra a melhora de desempenho no processamento do mapa do site.
Para obter mais informações, consulte Cortes de segurança em mapas de site no ASP.NET e Autorização ASP.NET.