Considerações sobre desempenho no modelo de suplemento do SharePoint

As abordagens que você usa para garantir o desempenho ideal com o SharePoint são diferentes no novo modelo de suplemento do SharePoint do que eram com o Código de Confiança Total. Em um cenário típico de FTC (Código de Confiança Total)/Solução de Farm, a maioria das operações de código ocorreu no código do Modelo de Objeto do lado do servidor do SharePoint.

Em um cenário de modelo de suplemento do SharePoint, o CSOM (Modelo de Objeto do Lado do Cliente) do SharePoint e/ou a API REST do SharePoint são usados para executar o código.

A principal diferença entre os dois modelos é o código do lado do servidor versus o código do lado do cliente. No modelo de suplemento do SharePoint, como o código é executado por meio de clientes, ocorre tráfego de rede adicional. Minimizar o número de viagens de ida e volta de chamadas à API para o servidor do SharePoint aumentará o desempenho de seus suplementos do SharePoint e reduzirá a quantidade de recursos consumidos pelo site do SharePoint.

Além disso, no modelo de Suplemento do SharePoint, como o código é executado por meio de clientes, pode haver longos atrasos antes que uma resposta seja recebida. O armazenamento em cache de dados para operações de longa execução (como as APIs de Perfil de Usuário) pode reduzir o tempo necessário para retornar informações ou receber confirmação de que um processo foi concluído.

Diretrizes de alto nível

Como regra geral, gostaríamos de fornecer as seguintes diretrizes de alto nível para garantir o desempenho ideal com o SharePoint no novo modelo de suplemento do SharePoint.

• Minimize as chamadas de API do lado do cliente para o servidor do SharePoint.
• Use técnicas de cache do lado do servidor e do lado do cliente para armazenar informações.
• Não é recomendável armazenar clientIDs, clientSecrets, nomes de usuário, senhas, tokens ou outras informações de segurança confidenciais em caches.

Opções para garantir o desempenho ideal com o SharePoint

Você tem algumas opções para garantir o desempenho ideal com o SharePoint.

• Usar o cache do lado do cliente
• Usar o cache do lado do servidor

Usar o cache do lado do cliente

Nesse padrão, técnicas de cache do lado do cliente, como HTML5 LocalStorage e cookies, são usadas para armazenar dados em cache. As informações armazenadas nesses locais são usadas para determinar se é necessário fazer chamadas de API para um servidor do SharePoint.

• Esse padrão armazena dados retornados de chamadas de API do SharePoint em caches do lado do cliente.
• Esse padrão usa código do lado do cliente (JavaScript) para avaliar os dados armazenados em caches do lado do cliente.
• Os cookies são limitados a armazenar 4095 bytes de dados.
  • Os cookies têm um mecanismo interno de expiração de dados.
• O LocalStorage do HTML5 é limitado a 5 MB de dados.

  • O HTML5 LocalStorage não tem um mecanismo interno de expiração de dados. No entanto, esse mecanismo de expiração pode ser implementado de forma rápida e fácil no JavaScript.

    Consulte as setLocalStorageKeyExpiry funções and isLocalStorageExpired no arquivo JavaScriptApp.js no Performance.LocalStorage (Exemplo de PnP do O365) para obter um exemplo.

    Definindo uma chave de expiração em LocalStorage:

    function setLocalStorageKeyExpiry(key)
    {
        // Check for expiration config values
        var expiryConfig = localStorage.getItem(expiryConfigKey);
    
        // Check for existing expiration stamp
        var existingStamp = localStorage.getItem(key + expiryKeySuffix);
    
        // Override cached setting if a user has entered a value that is different than what is stored
        if (expiryConfig != null)
        {
            var currentTime = Math.floor((new Date().getTime()) / 1000);
            expiryConfig = parseInt(expiryConfig);
    
            var newStamp = Math.floor((currentTime + expiryConfig));
            localStorage.setItem(key + expiryKeySuffix, newStamp);
    
            // Log status to window
            cachingStatus += "\n" + "Setting expiration for the " + key + " key...";
            $('#status').val(cachingStatus);
        }
        else
      {
    
        }
    }
    

    Verifique se a chave de expiração expirou no LocalStorage:

    function isLocalStorageExpired(key, keyTimeStampName)
    {
      // Retrieve the example setting for expiration in seconds
      var expiryConfig = localStorage.getItem(expiryConfigKey);
    
      // Retrieve the example setting for expiration in seconds
      var expiryStamp = localStorage.getItem(keyTimeStampName);
    
      if (expiryStamp != null && expiryConfig != null) {
    
          // Retrieve the expiration stamp and compare against specified settings to see if it is expired
          var currentTime = Math.floor((new Date().getTime()) / 1000);
    
          if (currentTime - parseInt(expiryStamp) > parseInt(expiryConfig)) {
              cachingStatus += "\n" + "The " + key + " key time stamp has expired...";
              $('#status').val(cachingStatus);
              return true;
          }
          else
          {
              var estimatedSeconds = parseInt(expiryStamp) - currentTime;
              cachingStatus += "\n" + "The " + key + " time stamp expires in " + estimatedSeconds + " seconds...";
              $('#status').val(cachingStatus);
              return false;
          }
      }
      else
      {
          //default
          return true;
      }
    }
    

Quando isso é apropriado?

Quando você precisar usar a API de modelo de objeto do lado do cliente (sp.js) do ECMA do SharePoint e avaliar os dados do lado do cliente para determinar se as chamadas à API precisam ser feitas.

Introdução

O Performance.Caching (Exemplo de PnP do O365) demonstra como implementar o LocalStorage e o cache do lado do cliente baseado em cookies no modelo de suplemento e fornece links para vários exemplos e artigos.

Usar o cache do lado do servidor

Nesse padrão, técnicas de cache do lado do servidor, como sessão e avaliação de cookie do lado do servidor, são usadas para acessar dados armazenados em cache. As informações armazenadas nesses locais são usadas para determinar se é necessário fazer chamadas de API para um servidor do SharePoint.

• Esse padrão armazena dados retornados de chamadas de API do SharePoint em caches do lado do servidor.

• Esse padrão usa código do lado do servidor para avaliar os dados armazenados em locais do lado do servidor.

  • Os locais do lado do servidor podem incluir dados baseados em sessão, caches do lado do servidor armazenados na RAM ou outras tecnologias de cache baseadas em servidor de terceiros.

• Esse padrão usa código do lado do servidor para avaliar os dados armazenados em cookies.

• Os cookies são limitados a armazenar 4095 bytes de dados.

  • Os cookies têm um mecanismo interno de expiração de dados.

  Consulte o método CookieCheckSkip na classe Customizer.aspx.cs no OD4B. Configuration.Async (Exemplo de PnP do O365) para ver como o código do lado do servidor é usado para avaliar os cookies.

Implementando sua própria camada de cache "man-in-the-middle"

Às vezes, faz sentido criar sua própria camada de cache personalizada. Um bom exemplo é quando você precisa retornar informações do perfil de um usuário. Às vezes, as APIs de perfil de usuário levam muito tempo para serem executadas. Para fornecer aos usuários finais uma experiência de interface de usuário rápida, você pode criar um trabalho de timer remoto para consultar o serviço de perfil de usuário e armazenar as informações em uma variedade de armazenamentos de dados. Em seguida, você pode criar um serviço para permitir consultar os armazenamentos de dados por meio de chamadas JavaScript de Suplementos do SharePoint.

O Azure tem muitos mecanismos de armazenamento diferentes que podem ser usados para armazenar informações, muitos dos quais são extremamente rápidos, como armazenamento de tabelas e armazenamento de blobs. Azure também permite que você crie um aplicativo Web para hospedar o serviço e proteger todos os dados e o serviço com o mesmo Azure Active Directory de uma locação do SharePoint Office 365 ou até mesmo um ambiente do SharePoint local com o DirSync habilitado.

Quando isso é apropriado?

• Quando você precisar usar a API de modelo de objeto do lado do cliente (Microsoft.SharePoint.Client.dll) do Código Gerenciado do SharePoint e avaliar os dados ou cookies do lado do servidor para determinar se as chamadas à API precisam ser feitas.
• Quando você tem operações de longa execução, como um Trabalho Web do Azure, isso só deve ser iniciado uma vez por determinado período de tempo, não importa quantas vezes um usuário tente iniciar uma operação.
  • A aplicação de configurações personalizadas do OneDrive for Business é um bom exemplo desse cenário.

Introdução

O Performance.Caching (Exemplo de PnP do O365) descreve como implementar o LocalStorage e o cache do lado do cliente baseado em cookies no modelo de suplemento e fornece links para vários exemplos e artigos.

Links relacionados

• Artigos de orientação em https://aka.ms/OfficeDevPnPGuidance
• Referências no MSDN em https://aka.ms/OfficeDevPnPMSDN
• Vídeos em https://aka.ms/OfficeDevPnPVideos

Exemplos de PnP

• Exemplos e conteúdo no Microsoft 365 Padrões e Práticas (PnP)

Aplicável a

• Office 365 Multilocatário (MT)
• Office 365 dedicado (D)
• SharePoint 2013 local