Consideraciones de rendimiento en el modelo de complemento de SharePoint

  • Artículo

Los enfoques que se adoptan para garantizar un rendimiento óptimo con SharePoint son diferentes en el nuevo modelo de complementos de SharePoint que con el código de plena confianza. En un escenario típico de código de plena confianza (FTC) o solución de granja de servidores, la mayoría de las operaciones de código tuvieron lugar en el código del modelo de objetos del lado servidor de SharePoint.

En un escenario de modelo de complementos de SharePoint, el modelo de objetos del lado cliente de SharePoint (CSOM) o la API REST de SharePoint se usan para ejecutar código.

La principal diferencia entre los dos modelos es el código del lado servidor frente al código del lado cliente. En el modelo de complemento de SharePoint, dado que el código se ejecuta a través de clientes, se produce tráfico de red adicional. Minimizar el número de recorridos de ida y vuelta de llamada api al servidor de SharePoint aumentará el rendimiento de los complementos de SharePoint y reducirá la cantidad de recursos que consume el sitio de SharePoint.

Además, en el modelo de complemento de SharePoint, dado que el código se ejecuta a través de clientes, podría haber retrasos prolongados antes de recibir una respuesta. El almacenamiento en caché de datos para operaciones de larga duración (como las API de perfil de usuario) puede reducir la cantidad de tiempo que se tarda en devolver información o recibir confirmación de que se ha completado un proceso.

Directrices importantes

Como regla general, nos gustaría proporcionar las siguientes directrices de alto nivel para garantizar un rendimiento óptimo con SharePoint en el nuevo modelo de complemento de SharePoint.

  • Minimice las llamadas API del lado cliente al servidor de SharePoint.
  • Use técnicas de almacenamiento en caché del lado servidor y del lado cliente para almacenar información.
  • No se recomienda almacenar identificadores de cliente, clientSecrets, nombres de usuario, contraseñas, tokens u otra información de seguridad confidencial en cachés.

Opciones para garantizar un rendimiento óptimo con SharePoint

Tiene un par de opciones para garantizar un rendimiento óptimo con SharePoint.

  • Uso del almacenamiento en caché del lado cliente
  • Uso del almacenamiento en caché del lado servidor

Uso del almacenamiento en caché del lado cliente

En este patrón, se usan técnicas de almacenamiento en caché del lado cliente, como HTML5 LocalStorage y cookies, para almacenar en caché los datos. La información almacenada en estas ubicaciones se usa para determinar si es necesario realizar llamadas API a un servidor de SharePoint.

  • Este patrón almacena los datos devueltos por las llamadas API de SharePoint en cachés del lado cliente.
  • Este patrón usa código del lado cliente (JavaScript) para evaluar los datos almacenados en cachés del lado cliente.
  • Las cookies se limitan a almacenar 4095 bytes de datos.
    • Las cookies tienen un mecanismo de expiración de datos integrado.
  • HTML5 LocalStorage está limitado a 5 MB de datos.

    • HTML5 LocalStorage no tiene un mecanismo de expiración de datos integrado. Sin embargo, este mecanismo de expiración puede implementarse rápida y fácilmente en JavaScript.

      Consulte las setLocalStorageKeyExpiry funciones y isLocalStorageExpired en el archivo de JavaScript deApp.js en Performance.LocalStorage (ejemplo PnP de O365) para obtener un ejemplo.

      Establecer una clave de expiración en 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
  {

    }
}

      Compruebe si la clave de expiración ha expirado en 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;
  }
}

¿Cuándo es una buena opción?

Cuando necesite usar la API de modelo de objetos del lado cliente (sp.js) de ECMA de SharePoint y evaluar los datos del lado cliente para determinar si es necesario realizar las llamadas API.

Introducción

Performance.Caching (ejemplo PnP de O365) muestra cómo implementar localStorage y almacenamiento en caché del lado cliente basado en cookies en el modelo de complemento y proporciona vínculos a varios ejemplos y artículos.

Uso del almacenamiento en caché del lado servidor

En este patrón, se usan técnicas de almacenamiento en caché del lado servidor, como la evaluación de cookies de sesión y del lado servidor, para acceder a los datos almacenados en caché. La información almacenada en estas ubicaciones se usa para determinar si es necesario realizar llamadas API a un servidor de SharePoint.

  • Este patrón almacena los datos devueltos por las llamadas API de SharePoint en cachés del lado servidor.

  • Este patrón usa código del lado servidor para evaluar los datos almacenados en ubicaciones del lado servidor.

    • Las ubicaciones del lado servidor pueden incluir datos basados en sesión, cachés del lado servidor almacenadas en RAM u otras tecnologías de almacenamiento en caché basadas en servidor de terceros.

  • Este patrón usa código del lado servidor para evaluar los datos almacenados en cookies.

  • Las cookies se limitan a almacenar 4095 bytes de datos.

    • Las cookies tienen un mecanismo de expiración de datos integrado.

    Vea el método CookieCheckSkip en la clase Customizer.aspx.cs de OD4B. Configuration.Async (ejemplo PnP de O365) para ver cómo se usa el código del lado servidor para evaluar las cookies.

Implementación de su propia capa de caché "man-in-the-middle"

A veces, tiene sentido crear su propia capa de caché personalizada. Un buen ejemplo es cuando necesita devolver información del perfil de un usuario. Las API de perfil de usuario a veces tardan mucho tiempo en ejecutarse. Para proporcionar a los usuarios finales una experiencia de interfaz de usuario rápida, puede crear un trabajo de temporizador remoto para consultar el servicio de perfil de usuario y almacenar la información en diversos almacenes de datos. A continuación, puede crear un servicio que le permita consultar los almacenes de datos a través de llamadas de JavaScript desde complementos de SharePoint.

Azure tiene muchos mecanismos de almacenamiento diferentes que se pueden usar para almacenar información, muchos de los cuales tienen un rendimiento extremadamente rápido, como Table Storage y Blob Storage. Azure también permite crear una aplicación web para hospedar el servicio y proteger todos los datos y el servicio con el mismo Azure Active Directory que un inquilino de SharePoint Office 365, o incluso un entorno local de SharePoint con DirSync habilitado.

¿Cuándo es una buena opción?

  • Cuando necesite usar la API de modelo de objetos del lado cliente de Código administrado de SharePoint (Microsoft.SharePoint.Client.dll) y evaluar los datos o las cookies del lado servidor para determinar si es necesario realizar las llamadas API.
  • Cuando tiene operaciones de ejecución prolongada, como un trabajo web de Azure, que solo se debe iniciar una vez por período de tiempo determinado, independientemente del número de veces que un usuario intente iniciar una operación.
    • La aplicación de configuraciones de OneDrive para la Empresa personalizadas es un buen ejemplo de este escenario.

Introducción

Performance.Caching (ejemplo PnP de O365) describe cómo implementar localStorage y almacenamiento en caché del lado cliente basado en cookies en el modelo de complemento y proporciona vínculos a varios ejemplos y artículos.

Ejemplos de PnP

Se aplica a

  • Office 365 multiempresa (MT)
  • Office 365 dedicado (D)
  • SharePoint 2013 local