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

Artigo
04/08/2023

As abordagens que você adota para garantir que o desempenho ideal com o SharePoint seja diferente no novo modelo de Suplemento do SharePoint do que com o Código de Confiança Total. Em um cenário típico de FTC (Código de Confiança Total) / Farm Solution, a maioria das operações de código ocorreu no código modelo de objeto do lado do SharePoint Server.

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 chamada de API para o servidor do SharePoint aumentará o desempenho dos suplementos do SharePoint e reduzirá a quantidade de recursos consumidos pelo site do SharePoint.

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

Diretrizes de alto nível

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

Minimizar 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 confidenciais de segurança 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 em cache dados. 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 o JavaScript (código do lado do cliente) para avaliar os dados armazenados em caches do lado do cliente.
Os cookies estão limitados ao armazenamento de 4.095 bytes de dados.
- Os cookies têm um mecanismo de expiração de dados interno.

O HTML5 LocalStorage é limitado a 5MB de dados.

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

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

Configurando uma chave de expiração no 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 do SharePoint ECMA (sp.js) e avaliar dados do lado do cliente para determinar se as chamadas de API precisam ser feitas.

Introdução

O Performance.Caching (Exemplo de PnP O365) demonstra como implementar o cache local do lado do cliente e o cache do lado do cliente baseado em cookie 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 avaliação de cookie do lado do servidor e sessão, 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 o 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 em RAM ou outras tecnologias de cache baseadas em servidor de terceiros.
Esse padrão usa o código do lado do servidor para avaliar os dados armazenados em cookies.
Os cookies estão limitados ao armazenamento de 4.095 bytes de dados.
- Os cookies têm um mecanismo de expiração de dados interno.
Consulte o método CookieCheckSkip na classe Personalizer.aspx.cs no OD4B. Configuration.Async (O365 PnP Sample) para ver como o código do lado do servidor é usado para avaliar cookies.

Implementando sua própria camada de cache 'homem no meio'

À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. As APIs de Perfil de Usuário às vezes levam muito tempo para serem executadas. Para fornecer aos usuários finais uma experiência rápida de interface do usuário, você pode criar um trabalho de temporizador 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 que você consulte 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 têm um desempenho extremamente rápido, como armazenamento de tabelas e armazenamento de blobs. O 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 que um Office 365 locação do SharePoint ou até mesmo um ambiente local do SharePoint com DirSync habilitado.

Quando isso é apropriado?

Quando você precisar usar a API do Modelo de Objeto do lado do cliente do SharePoint Managed Code (Microsoft.SharePoint.Client.dll) e avaliar dados ou cookies do lado do servidor para determinar se as chamadas de API precisam ser feitas.
Quando você tem operações de longa duração, como um Trabalho Web do Azure, que 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.
- Aplicar configurações de OneDrive for Business personalizadas é um bom exemplo desse cenário.

Introdução

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

Artigos de diretrizes 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 Patterns and Practices (PnP)

Aplicável a

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

Partilhar via

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

Diretrizes de alto nível

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

Usar o cache do lado do cliente

Quando isso é apropriado?

Introdução

Usar o cache do lado do servidor

Implementando sua própria camada de cache 'homem no meio'

Quando isso é apropriado?

Introdução

Exemplos de PnP

Aplicável a

Recursos adicionais

Partilhar via

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

Diretrizes de alto nível

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

Usar o cache do lado do cliente

Quando isso é apropriado?

Introdução

Usar o cache do lado do servidor

Implementando sua própria camada de cache 'homem no meio'

Quando isso é apropriado?

Introdução

Links relacionados

Exemplos de PnP

Aplicável a

Recursos adicionais