Cet article a fait l'objet d'une traduction automatique.

Cache AppFabric

Usage et intégration réels

Andrea Colaci

Microsoft Windows Server AppFabric, anciennement baptisé “ Velocity ”, fournit un cache distribué que vous pouvez intégrer dans les applications de bureau et Web. AppFabric peut améliorer les performances, évolutivité et disponibilité lors de la, du point de vue du développeur, se comporter comme un cache de mémoire commune. Vous pouvez mettre en cache tout objet sérialisable, y compris les DataSets, des DataTables, données binaires, XML, entités et les données transfert objets personnalisés.

Le client AppFabric API est simple et facile à utiliser, et l'API serveur fournit un complet Distributed Resource Manager (DRM) qui permet de gérer un ou plusieurs serveurs de cache (avec plusieurs serveurs, comprenant un cluster de cache). Chaque serveur fournit son propre quota de mémoire, la sérialisation d'objets et de transport, regroupement de la région, recherche basée sur la balise et d'expiration. Les serveurs cache prennent également en charge la haute disponibilité, une fonctionnalité qui crée un objet réplicas sur les serveurs secondaires.

Le problème de juin 2009 de MSDN Magazine , inclut une bonne introduction à Windows Server AppFabric par Aaron Dunnington (msdn.microsoft.com/magazine/dd861287 ). Dans cet article, je vais expliquer comment intégrer AppFabric que la mise en cache dans le bureau et applications Web. Tout au long du processus, je vous fournir quelques méthodes conseillées et donner quelques conseils pour tirer parti des nouvelles fonctionnalités dans le Microsoft .NET Framework 4 et 4 de ASP.NET. Vous allez également apprendre à résoudre les problèmes courants qui surviennent lors de l'utilisation d'un cache distribué.

Tous les exemples de code qui suivent proviennent d'une solution de démonstration complète appelée Velocity Shop, disponible sur CodePlex à velocityshop.codeplex.com de .

Notez que Windows Server AppFabric, que j'aborderai dans cet article, est différente de la plate-forme Windows Azure AppFabric. Pour plus d'informations sur la technologie Windows Azure, voir microsoft.com/windowsazure/appfabric .

Mise en route

Vous pouvez installer la version bêta en cours 2 Refresh de Windows Server AppFabric de plusieurs manières pour le développement. Le programme d'installation à la plate-forme Web (microsoft.com/web/downloads ) vous permet de définir facilement de nombreuses applications de développement Web et de structures par l'intermédiaire d'une seule installation configurable. De plus, le programme d'installation de la plate-forme Web est mis à jour pour inclure les nouvelles versions de la prise en charge les applications et infrastructures.

Ceux qui vous voulez seulement installer AppFabric seront trouve un lien vers la dernière version sur la page Windows Server AppFabric du centre de développement de Windows Server à msdn.microsoft.com/windowsserver/ee695849 de .

Après avoir terminé le programme d'installation, la mise en cache AppFabric est presque prêt à utiliser. L'étape suivante consiste à créer un cache nommé, un conteneur logique utilisé pour stocker des données. Pour cela, par le biais de la cmdlet New-cache dans Windows PowerShell :

New-Cache -cacheName Catalog

Pour utiliser AppFabric que la mise en cache dans votre application, vous devez simplement ajouter les références à CacheBaseLibrary.dll, CASBase.dll, CASMain.dll et ClientLibrary.dll dans votre projet Visual Studio.

La bibliothèque cliente est simple. Le code suivant montre comment accéder au cache pour accéder au cache nommé et stocker ou récupérer des objets distribué :

cacheCluster = new DataCacheServerEndpoint[1];
cacheCluster[0] = new DataCacheServerEndpoint(
  "ServerName", 22233, "DistributedCacheService");
DataCacheFactory factory = 
  new DataCacheFactory(cacheCluster, true, false);
DataCache cache = factory.GetCache("Catalog");

// Putting a product in cache
cache.Put("Product100", myProduct);

// Getting Product from cache
Product p = (Product)cache.Get("Product100");

Avant de vous plonger dans AppFabric mise en cache, il est judicieux de commencer avec un peu de planification. La première étape consiste à prendre en compte la façon dont vous allez configurer le cache. Cela détermine lesquelles de ses fonctionnalités sont disponibles pour votre application.

Pour commencer, vous voudrez définir un cache nommé pour votre projet, comme indiqué plus haut. Ceci en place, vous pouvez définir des stratégies d'expiration et de notification personnalisées. Vos objets ou des collections peuvent nécessiter différentes durées de cache et devez (ou peut-être ne doit pas) être normalement éliminées du cache lorsque la pression de mémoire est élevée. Pour définir le délai d'expiration absolue pour un cache nommé donné, utilisez le paramètre durée de vie avec la cmdlet New-cache.

Ainsi que le cache nommé, vous souhaiterez peut-être configurer des zones. Ils se comportent comme des sous-groupes dans le cache et peuvent être utilisées pour organiser des objets et de simplifier le processus de recherche d'objets dans le cache. Par exemple, que mon application utilise un catalogue des appareils électroniques grand public. Je peux créer un cache du catalogue dans lequel je diviser les produits en ma possession en zones appelées téléviseurs, les appareils photo et les lecteurs MP3. Pour créer des régions que vous pouvez effectuer qu'au moment de l'exécution, utilisez la méthode dataCache.CreateRegion et en fournissant un nom de région :

// Always test if region exists;
try {
  cache.CreateRegion("Televisions", false);
}
catch (DataCacheException dcex) {
  // if region already exists it's ok, 
  // otherwise rethrow the exception
  if (dcex.ErrorCode != DataCacheErrorCode.RegionAlreadyExists) 
    throw dcex;
}

Gardez en tête que si une zone avec le même nom existe déjà, une DataCacheException est levée, vous devez utiliser un bloc try-catch appropriée.

Mais que se passe-t-il si vous avez besoin de rechercher des produits dans une base de fonctionnalité ? Vous trouverez une autre fonctionnalité de AppFabric la mise en cache utile pour ce faire : recherche basée sur la balise. Cette fonctionnalité est disponible uniquement lorsque vous utilisez des régions et il vous permet d'attacher un ou stationnés des balises supplémentaires à chaque élément dans le cache pour les recherches ultérieures.

Par exemple, supposons que je veux rechercher tous les produits de la région de téléviseurs “ voyant-Panneau de configuration ” et “ 46 pouces ” balises. J'utilise la méthode GetByAllTags, en spécifiant une liste de DataCacheTags, et voilà. Voici un exemple de recherche basés sur la balise :

DataCacheServerEndpoint[] cacheCluster = GetClusterEndpoints();
DataCacheFactory factory = 
  new DataCacheFactory(cacheCluster, true, false);
DataCache cache = factory.GetCache("Catalog");
IEnumerable<KeyValuePair<string, object>> itemsByTag = 
  cache.GetObjectsByTag(
  new DataCacheTag("LED-Panel"), "Televisions");

Lors de l'introduction d'une couche de cache dans une application existante ou nouvelle, il existe également des points communs, vous devez prendre en compte. Il aide à identifier et classifier les types de données qui sont de bons candidats pour la mise en cache. Il existe trois catégories :

• Référence aux données, ce qui englobe les données en lecture seule qui changent peu fréquemment, voire — par exemple, une liste de pays, des catalogues des éléments couramment stockés ou feuilles de données de produit.
• Données d'activité, qui inclut toutes les données peuvent être modifiées sur une base par utilisateur ou par session, par exemple un panier d'achat ou une liste de voeu.
• Les données de ressources, c'est-à-dire des informations qui peuvent varier souvent et qui sont soumise à plus d'un type de l'activité des utilisateurs, tels que les modifications apportées au stock produit effectuées après commandes de place aux clients.

Cette classification est utile lors de la spécification de stratégies d'expiration et de notification pour chaque de nommé cache afin que vous pouvez obtenir de l'utilisation des ressources efficace et rationnelle. N'oubliez pas que même si vous pouvez ajouter des serveurs de cache pour le cluster, mémoire reste toujours une ressource limitée.

Cycle de vie du cache

Lorsque votre application démarre, le cache est vide. Les utilisateurs seront cependant les atteindre le site Web. Par conséquent, comment vous préchauffer le cache ?

Avec le modèle de mémoire cache ailleurs, applications basées sur le cache doivent être en mesure de basculer vers le stockage persistant, tel qu'une base de données SQL Server, lorsque les données demandées ne sont pas dans le cache. Cela peut être une étape coûteuse dans les scénarios de traitement intensif de données, en particulier lorsque vous traitez avec de grandes quantités de données de référence, ou lors de l'unicité de la charge du cache n'est pas garantie. Il peut y avoir un point lorsque plusieurs threads, après le test d'un objet, le cache essaie de charger des données à partir du stockage et enregistre les données dans le cache pour les demandes suivantes. Par conséquent, vous pouvez subir d'affecter négativement les performances à partir de l'extraction de données non mis en cache et mise en cache de données plus souvent que nécessaire.

C'est lorsque quelque chose comme 7.5 IIS de démarrage automatique du service pourrait s'avérer utile. Avec AppFabric, vous pouvez utiliser un verrou de lecteur pour obtenir des résultats similaires. Pour activer le démarrage automatique du service, vous devez appliquer certaines modifications à applicationHost.config, comme illustré ici :

<serviceAutoStartProviders>
  <add name="PrewarmMyApp" 
       type="MyWebApp.PreWarmUp, MyWebApp" />
</serviceAutoStartProviders>

Ensuite vous chargez les données de référence et des ressources dans le cache nommé en mettant en œuvre de la méthode précharger avec du code personnalisé :

using System.Web.Hosting;
namespace DemoApp {
  public class WarmUp : IProcessHostPreloadClient {
    public void Preload(string[] parameters) {
      // Cache preload code here...
    }
  }
}

Applications Web sont alors disponibles qu'après l'achèvement de la méthode précharger.

Dans les scénarios de batterie de serveurs, telles que celle illustrée dans les de la figure 1 , vous avez également le problème de chaque application démarrage à froid tirant sur le stockage persistant pour charger son cache. Le cache ASP.NET par défaut est lié à l'appDomain dans lequel l'application s'exécute, afin que vous obtiendrez uniquement l'accès de chargement du cache une seule fois. Dans AppFabric, toutefois, le cache est partagé entre les serveurs Web et par conséquent, entre les applications Web, les tentatives de chargement de cache donc simultanées doivent être évitées.

Figure 1 AppFabric Cache dans une batterie de serveurs,

Il n'y a plusieurs options pour la délégation de la charge du cache à un seul serveur. Une fonctionnalité introduite dans AppFabric bêta 1 est le verrou de lecteur. Cela vous permet de verrouiller une clé de l'élément de cache avant d'être ajouté au cache. Le premier code preload qui verrouille la clé sera le seul pour commencer le chargement des données qui lui sont associées. Il s'agit comme les clés de la prise en compte avant de les utiliser lors du chargement du cache. La technique permet également de répartir les opérations de chargement de cache entre les serveurs Web. Vous pouvez configurer chaque serveur à l'avance pour charger les données associées à des touches d'imputation spécifiques.

Savoir quand le cache est chargé est des problèmes de synchronisation avec les ressources distribuées telles que les clusters de la mémoire cache. Avec la mise en cache AppFabric, il existe plusieurs méthodes pour déterminer le moment le cache est prêt. Une technique est que les serveurs à interroger des clés communes après que le chargement de leurs propres comptabiliser des données de la clé. Autres options incluent l'abonnement à une notification de cache prêts ou même la phase de préchargement en cours dans un service distinct ou une application, car le cache est maintenant distribué et accessibles à partir d'applications de bureau et du Web.

En outre, vous pouvez tirer parti de la classe .NET Framework 4 System.Threading.Tasks.Parallel pour paralléliser les opérations de chargement du cache, comme dans de la figure 2 .

Chargement de cache parallèle de la figure 2

// load catalog items from DB
SQLServerCatalogProvider SQLServerCatalogProvider = 
  new SQLServerCatalogProvider();
itemsInCategory = 
  SQLServerCatalogProvider.GetItemsByCategoryId(categoryId);
_helper.CreateRegion(categoryId);

Parallel.ForEach(itemsInCategory, item =>{
  // put each catalog item in cache with tags
  if (item.Tags==string.Empty)
    _helper.PutInCache(item.ProductId, item, categoryId);
  else
    _helper.PutInCache(item.ProductId, item, categoryId, item.Tags);
});

// Code from Helper class
public void PutInCache(string key, object value, 
  string region, string tags) {

  List<DataCacheTag> itemTags = new List<DataCacheTag>();

  foreach (var t in tags.Split(',').ToList())
    itemTags.Add(new DataCacheTag(t.ToLower()));
  _cache.Put(key, value, itemTags , region);
}

Une fonctionnalité de cache est prévue pour une future version de la mise en cache AppFabric. Ceci permettrait d'exécuter automatiquement un code personnalisé pour charger le cache lorsque les données n'est pas présentes et à l'inverse, pour enregistrer des données dans un stockage persistant lors de l'information a été mis à jour dans le cache.

Intégration ASP.NET

Le modèle de fournisseur ASP.NET permet aux développeurs de choisir parmi trois fournisseurs de session : InProc et StateServer, SQL Server AppFabric mise en cache, un fournisseur de session quatrième est techniquement disponible, mais faites attention à ne pas confondre session avec un cache. Mémoire cache sur l'amélioration des performances, la session est sur la définition d'un état de l'application.

Le fournisseur de session de mise en cache AppFabric pour ASP.NET utilise son distribués — et potentiellement hautement disponible, cache comme un référentiel pour les sessions ASP.NET. Ceci est transparent et disponibles sans casser le code existant. Permet à une session ASP.NET de survivre si le serveur Web tombe en panne ou passe en mode hors connexion, car les sessions sont stockées out-of-process dans le cache AppFabric ayant ce type de fournisseur.

Une fois la mise en cache AppFabric est installé et configuré, vous devez créer un cache nommé pour le stockage des sessions ASP.NET. Vous pouvez ensuite activer DataCacheSessionStoreProvider en modifiant Web.config, comme dans de la figure 3 .

La figure 3 activation sessions ASP.NET dans le Cache AppFabric

<?xml version="1.0"?>
<configuration>
  <configSections>
    <section name="dataCacheClient" 
      type="Microsoft.Data.Caching.DataCacheClientSection, CacheBaseLibrary" 
      allowLocation="true" allowDefinition="Everywhere"/>
    <section name="fabric" 
      type="System.Data.Fabric.Common.ConfigFile, FabricCommon" 
      allowLocation="true" allowDefinition="Everywhere"/>
    <!-- Velocity 1 of 3 END -->
  </configSections>
  <dataCacheClient deployment="routing">
    <localCache isEnabled="false"/>
    <hosts>
      <!--List of services -->
      <host name="localhost" cachePort="22233" 
        cacheHostName="DistributedCacheService"/>
    </hosts>
  </dataCacheClient>
  <fabric>
    <section name="logging" path="">
      <collection name="sinks" collectionType="list">
        <!--LOG SINK CONFIGURATION-->
        <!--defaultLevel values: -1=no tracing; 
            0=Errors only; 
            1=Warnings and Errors only; 
            2=Information, Warnings and Errors; 
            3=Verbose (all event information)-->
        <customType 
          className="System.Data.Fabric.Common.EventLogger,FabricCommon" 
          sinkName="System.Data.Fabric.Common.ConsoleSink,FabricCommon" 
          sinkParam="" defaultLevel="-1"/>
        <customType 
          className="System.Data.Fabric.Common.EventLogger,FabricCommon" 
          sinkName="System.Data.Fabric.Common.FileEventSink,FabricCommon" 
          sinkParam="DcacheLog/dd-hh-mm" defaultLevel="-1"/>
        <customType 
          className="System.Data.Fabric.Common.EventLogger,FabricCommon" 
          sinkName="Microsoft.Data.Caching.ETWSink, CacheBaseLibrary" 
          sinkParam="" defaultLevel="-1"/>
      </collection>
    </section>
  </fabric>
<appSettings/>
<connectionStrings/>
<system.web>
  <sessionState mode="Custom" customProvider="Velocity">
    <providers>
      <add name="Velocity" 
        type="Microsoft.Data.Caching.DataCacheSessionStoreProvider, ClientLibrary" 
        cacheName="session"/>
    </providers>
  </sessionState>
...

Vous pouvez intégrer AppFabric mise en cache dans les applications ASP.NET 3.5 existantes, car seule la partie serveur requiert le 4 du Framework .NET, mais la bibliothèque cliente fonctionne avec .NET Framework 3.5 et 4.

Un autre point d'extensibilité de ASP.NET 4 est le cache de sortie. Depuis ASP.NET 1.0, il a été en mesure de stocker la sortie de pages et contrôles générée dans un cache en mémoire. Les demandes suivantes peuvent obtenir ce résultat de la mémoire au lieu de générer à nouveau. ASP.NET 4 prend en charge la configuration d'un ou plusieurs fournisseurs de cache de sortie personnalisée. Un fournisseur de cache de sortie AppFabric seront disponible après la parution de ASP.NET 4, et vous pouvez déployer vos propres en étendant la classe OutputCacheProvider et en modifiant Web.config pour l'activer.

Intégration ORM

Structures de mapping objet-relationnel (ORM) les plus populaires fournissent une fonctionnalité appelée le cache de second niveau, un référentiel qui stocke des entités, les collections et les résultats de la requête pour une durée configurable. Lorsqu'une entité doit être chargée à partir d'un stockage persistant, l'ORM vérifie tout d'abord le cache de second niveau pour vérifier si l'entité est déjà chargée. Dans ce cas, une instance de l'entité demandée est passée au code appelant sans cliquer sur la base de données.

Chaque implémentation ORM a sa propre stratégie de traitement des associations d'entité, les collections et les résultats de la requête, et c'est tout aussi vrai du cache de second niveau. En fonction de l'ORM que vous employez, vous pouvez trouver que les options de personnalisation et l'utilisation du cache de second niveau sont limitées, et vous contraindre à une approche particulière en consommant les modifications du cache. Par exemple, si les dépendances de cache et de la stratégie d'expiration sont difficiles à personnaliser, objet conflits peut augmenter et diminue l'efficacité du cache.

NHibernate et Entity Framework peuvent utiliser la mise en cache AppFabric comme un cache de second niveau. Nhibernate Active cette fonctionnalité via nhibernate.caches.velocity (sourceforge.net/projects/nhcontrib/files/NHibernate.Caches/ ). Entity Framework qu'il permet par le biais de EFCachingProvider par Jaroslaw Kowalski (code.msdn.microsoft.com/EFProviderWrappers ).

Placer AppFabric au travail

Comme vous l'avez vu, la mise en cache de Windows Server AppFabric, facile d'activer la mise en cache à l'échelle de cluster dans n'importe quelle application nouvelle ou existante. Pour obtenir le meilleur parti d'un cache, vous devez identifier les objets de données de candidats de droite, mais peut est déjà fait que la mise en cache du serveur local. Vous aurez également besoin d'une stratégie d'expiration et de notification.

AppFabric est disponible avec une licence de Windows Server 2008 et est également disponible en téléchargement (msdn.microsoft.com/windowsserver/ee695849 ). Il va également être présente en tant que rôle de cache dans Windows Azure.

Télécharger AppFabric, configurer votre cluster de cache unique ou plusieurs serveurs et si vous le souhaitez, téléchargez et exécutez Velocity Shop sur CodePlex à évaluer et à profiter de toutes les fonctionnalités AppFabric présentées à l'intérieur de la solution.

Andrea Colaci est consultant et formateur chez de plus de 10 ans d'expérience. Il a une curiosité forte et une passion pour les langues plus récents et de développement outils.

Grâce à l'expert technique suivante pour la révision de cet article: Scott Hanselman