Éviter les « cold queries » sur son site IIS

Avez-vous déjà remarqué qu’après une longue période d’inactivité votre site internet mettait du temps à répondre ? C’est ce qu’on appelle une « cold query« , c’est à dire une requête qui se verra ajouter un temps d’initialisation de l’application en plus de son temps de traitement habituel.

Avant d’entrer plus en détails sur les différents solutions pour pallier à ce problème, revoyons nos basiques !

AppDomain

Un domaine d’application fournit une couche d’isolement dans un processus. Tout ce que vous pensez habituellement comme «par programme» (variables statiques, etc.) est en fait par AppDomain.
Par exemple Entity Framework utilise l’AppDomain pour mettre en cache :
  • Les métadonnées : contient les infos pour faire le lien entre les value types C# et les types de base de donnée
  • Les vues générées : la transformation nécessaire entre les objets C# et les tables de la base de données
  • Les traductions des requêtes LINQ en SQL

Plus d’infos à ce sujet http://msdn.microsoft.com/en-us/data/hh949853.aspx#2

 Application pool

Un pool d’applications est un mécanisme utilisé par IIS pour isoler les applications Web, cela permet d’avoir différentes configurations (sécurité, utilisation des ressources, etc.) et empêche les applications instables d’interférer avec d’autres applications.

Généralement, chaque pool d’applications correspond à un processus de travail. Un processus de travail est un processus windows (w3wp.exe) qui exécute des applications Web et est responsable du traitement des demandes envoyées à un serveur Web pour un pool d’applications spécifique.

Le pool d’applications peut contenir plusieurs AppDomain, d’où le compteur « Applications » visible dans la liste des pools d’application dans IIS.

Cycle de vie de l’application pool

Un recyclage signifie que le processus de travail qui gère les requêtes pour ce pool d’applications est terminé, et qu’un nouveau a pris le relais. Ceci afin d’éviter des états instables qui peuvent mener à des plantages, blocages ou des fuites mémoire. Les recyclages peuvent notamment se produire si on modifie le web.config ou le dossier bin du site web, et sont affectés par certains paramètres.

Les paramètres avancés du pool d’applications possède une section « Recyclage » où sont répertoriés les différents paramètres influant sur le cycle de vie dont voici la liste :

  • Intervalle de temps régulier (par défaut 29h)
  • Nombre limite de demandes (par défaut pas de limite)
  • Heures spécifiques (par défaut vide)
  • Limite de mémoire virtuelle  (par défaut pas de limite)
  • Limite de mémoire privée (par défaut pas de limite)

Un autre paramètre à ne pas négliger se trouve dans la section « Modèle de processus » :

  • Délai d’inactivité (20 minutes par défaut)

 

Résolution du problème

 

La méthode simple

Afin de régler le problème de « cold query » sur votre site IIS, vous pouvez simplement modifier tous les paramètres ci-dessus pour faire en sorte que le pool d’applications ne se recycle qu’en cas de modification du site web.

Sur une configuration par défaut il suffit de mettre 0 pour « Intervalle de temps régulier » et pour « Délai d’inactivité« . Cependant cette méthode est fortement déconseillée. Le pool d’application DOIT être recyclé à intervalles régulier, sinon la moindre et infime fuite mémoire dans n’importe quelle librairie (ASP.Net inclus) va être source de plantages aléatoires, inexpliqués, et inexplicables.

 

La méthode Preload

Une requête est envoyée une fois que le pool d’applications a été recyclé, cela permet de conserver sa logique au niveau du global.asax, mais si l’initialisation est longue cela peut figer le site. De plus la requête n’est pas déclenchée lorsque l’application est redéployée.

1) Installation du module « Application Initialization »

– Sur un Windows classique : Programmes et fonctionnalités -> Activer ou désactiver des fonctionnalités Windows -> Internet et Information Services -> Services World Wide Web -> Initialisation d’application

– Sur un Windows Server : Server Manager -> Ajouter des rôles ou fonctionnalités -> Rôle serveur -> Internet et Information Services -> Services World Wide Web -> Initialisation d’application

2) Configuration du pool d’applications

– Sur la liste des pools d’applications -> sélectionner le pool d’application

  • Paramètres de base -> cocher « Démarrer automatiquement le pool d’applications »
  • Paramètres avancés -> section Général : mettre « Mode de démarrage » à « Always Running« 

3) Configuration du site Web

Dans la page d’accueil du serveur ouvrir l’éditeur de configuration:

1 EditeurConfigurationServeur

Sélectionner la section « sites» sous « applicationHost » via le menu déroulant « section » :

2 choisirApplicationHost

Ouvrir la collection :

3 OuvrirCollectionApplication

Sélectionner votre site web :

  • Mettre serverAutoStart à true

4 OuvrirCollectionAppPool

Dans les paramètres de la nouvelle fenêtre mettre :

  • preloadEnabled à true

5.1 OptionAppPool

Fermer les fenêtres. De retour sur l’éditeur de configuration, vous pouvez faire « Générer le script » afin de rendre la tâche répétable 😉 Sinon, faites appliquer.

6 AppliquerChangement

Dans le web.config de l’application, ajouter :

<system.webServer>
     <applicationInitialization doAppInitAfterRestart="true"/>
</system.webServer>

A noter qu’il y a deux attributs optionnels :

  • remapManagedRequestsTo : Permet de spécrediriger les requêtes vers une page statique pendant l’initialisation du site web.
  • skipManagedModules : Spécifie si les modules managés de IIS sont chargés durant l’initialisation.

Checklist :

  • Pool d’Application
    • Démarrage automatique
    • Mode de démarrage à AlwaysRunning
  • Site web
    • serverAutoStart à true
    • Application du site web
      • preloadEnabled à true
  • Web.config :
    • Avoir ajouté la clé applicationInitalization
  • Global asax ou dans Startup.cs
    • Mettre votre logique d’initialisation : par exemple si vous utilisez Entity Framework, faire une query qui charge un objet complexe afin de mettre en cache un maximum de choses au niveau de l’AppDomain.

 

La méthode serviceAutoStart

La méthode Preload d’une classe implémentant « System.Web.Hosting.IProcessHostPreloadClient » est appelée (ne déclenche ni l’Application_Start du Global.asax ni la classe « Startup » de Owin). C’est la méthode recommandée pour garder son application up tout le temps mais la plus contraignante.

1) Créer votre classe implémentant « System.Web.Hosting.IProcessHostPreloadClient »

Exemple :

public class MvcMusicStoreApplicationPreloadClient : IProcessHostPreloadClient
{
    public void Preload(string[] parameters)
    {
        var service = new TopSellingAlbumsService();
        HttpRuntime.Cache["TopSellingAlbums"] = service.GetTopFiveSellingAlbums();
    }
}

2) Installation du module « Application Initialization »

– Sur un Windows classique : Programmes et fonctionnalités -> Activer ou désactiver des fonctionnalités Windows -> Internet et Information Services -> Services World Wide Web -> Initialisation d’application

– Sur un Windows Server : Server Manager ->Ajouter des rôles ou fonctionnalités -> Rôle serveur -> Internet et Information Services -> Services World Wide Web -> Initialisation d’application

3) Configuration du pool d’applications

– Sur la liste des pools d’applications -> sélectionner le pool d’application

  • Paramètres de base -> cocher « Démarrer automatiquement le pool d’applications »
  • Paramètres avancés -> section Général : mettre « Mode de démarrage » à « Always Running« 

4) Ouvrir l’éditeur de configuration

Dans la page d’accueil du serveur ouvrir l’éditeur de configuration:

1 EditeurConfigurationServeur

5) Ajouter le service à IIS

Sélectionner la section « serviceAutoStartProviders» sous « applicationHost » via le menu déroulant « section » :

2 choisirSercice

Ouvrir la collection :

3 OuvrirCollection servicesAutoStart

Ajouter votre service :

4 Ajouter serviceProvider

Pour le champ type, mettre le nom complet du type implémentant IProcessHostPreloadClient par exemple : « MvcMusicStore.MvcMusicStoreApplicationPreloadClient, MvcMusicStore » (MvcMusicStore est la DLL). Fermer la fenêtre.

6) Configurer le site web

Sélectionner la section « sites» sous « applicationHost » via le menu déroulant « section » :

2 choisirApplicationHost

Ouvrir la collection :

3 OuvrirCollectionApplication

Sélectionner votre site web :

  • Mettre serverAutoStart à true

4 OuvrirCollectionAppPool

Dans les paramètres de la nouvelle fenêtre mettre :

  • serviceAutoStartEnabled à true
  • serviceAutoStartProvider : mettre le nom de votre service

5.1 OptionAppPool

Fermer les fenêtres. De retour sur l’éditeur de configuration, vous pouvez faire « Générer le script » afin de rendre la tâche répétable 😉 Sinon, faites appliquer.

6 AppliquerChangement

Checklist

  • Pool d’Application
    • Démarrage automatique
    • Mode de démarrage à AlwaysRunning
  • Service Provider
    • Ajouter votre service en utilisant le nom complet pour le type
  • Site web
    • serverAutoStart à true
    • Application du site web
      • serviceAutoStartEnabled à true
      • serviceAutoStartProvider attribué au service précédemment ajouté
  • Web.config :
    • Avoir ajouté la clé applicationInitalization

 

 

Conclusion

Vous avez maintenant toutes les clés en main pour résoudre votre problème avec la solution la plus adaptée ! Même si cela peut sembler compliqué la 1ère fois, les méthodes « Preload » et « serviceAutoStart » sont finalement assez rapide à mettre en place une fois qu’on a pris le coup de main.

Enfin, notez que même si rien n’empêche d’utiliser les deux dernières solutions simultanément, cela est déconseillé car ça peut entrainer des instabilités (notamment des initialisations s’effectuant plusieurs fois).

 

Ressource :

http://www.iis.net/configreference/system.webserver/applicationinitialization

http://www.iis.net/configreference/system.applicationhost/serviceautostartproviders

[Build 14] – Building a Single Page Application with ASP.NET and AngularJS

Mail de Mehdi
Jeudi 3 avril 2014 16:42

Building a Single Page Application with ASP .NET and AngularJS

// Speakers:
David Catuhe, Jon Galloway

Session un peu décevante, niveau 300 mais plutôt destinée aux personnes n’ayant jamais fait d’AngularJS.

Les démos sont là pour attirer ces gens sur ce framework.

On débute avec la façon avec laquelle on intègre Angular dans une page HTML => nous avons besoin que d’un seul fichier
«angular.min.js»

Trois solutions sont possibles pour ajouter AngularJS à un projet => soit on télécharge les fichiers, soit on utilise NuGet ou un CDN (le plus conseillé par David).
// Début de la démo :

Initialisation du controller de la vue, David ajoute comme injection $scope pour accéder au scope de la vue. Il initialise une variable avec un tableau de deux éléments qui seront bindés dans la vue avec un repeater, il lance la page, et voilà ! ça marche très simplement.

Ensuite on nous introduit les différentes façon d’accéder à de la data, avec $http qui est basé sur une version light de jQuery, et $resource qui est un objet spécifique fait pour du restful api (qui sera utilisé un peu plus tard dans la démo pour interroger le serveur au lieu d’avoir la data en local)

Pour les utiliser depuis le controller, il faut les ajouter dans les injection de dépendance de celui-ci.

On nous présente comment créer un service pour rendre transparent l’accès aux données.

Démo de comment on peut créer un filtre dans un repeater.

Une petite démo du Two-Way Data Binding avec enregistrement en local des données.

Une démo sur les animations (avec le repeater , angular ajoute des classes spécifiques quand un element est ajouter/supprimer/modifier dans la liste et on peut donc facilement faire des animations en css).

Présentation de comment créer des routes dans Angular avec le template de la « page » qui va avec.

Mehdi

What’s New in .NET Development (2-303)

Session animée par Habib Heydarian

Asp.net est maintenant délivré par NuGet plutôt qu’avec .net. Les outils Visual Studio évoluent à un rythme différent.

On revient sur l’évolution de asp.net et le fait qu’il n’y a qu’un seul asp.net avec différentes briques, d’où le nouveau wizard de création de projet.

Une autre grosse nouveauté concerne le mode d’authentification qui va maintenant être base sur OWIN.

On voit ensuite une quantité de, petites démos sur les différentes parties et sur vs 2013.

Session agréable mais un peu creuse.

Guillaume Leborgne

Microsoft Dev Camp : Réussir la partie serveur de vos applications Windows 8 et Windows Phone Jeudi 2 mai 2013

Microsoft Dev Camp : Windows 8 et Windows Phone

Microsoft Dev Camp : Windows 8 et Windows Phone

Rendez-vous le Jeudi 2 mai 2013 à partir de 13h30 !

Qu’est-ce qu’un Dev Camp ?

Le Dev Camp est un événement destiné aux développeurs professionnels comme non professionnels animé par les experts Microsoft et ses partenaires.

Au programme 4 heures de :

  • Formation
  • Démo
  • Code

L’objectif de ce Dev Camp est de vous montrer comment développer, sécuriser, et optimiser les API et les services qui vous permettront d’exposer vos données pour des applications mobiles.

Les intervenants :
Cet après-midi sera animé par des intervenants MCNEXT :

  • John Thiriet, consultant DotNET et MVP Expression Blend
  • Guillaume Leborgne, chef de projet et expert DotNET

Ils ont développé de nombreuses applications Windows 8 et Windows Phone 8 présentes dans le Microsoft Store. Ce sont leurs retours d’expériences autour de Windows 8 et Windows Phone 8 qu’ils souhaitent vous apporter.

Lieu  :
Campus de Microsoft – Issy les Moulineaux

Pour en savoir plus : http://www.mcnext.com/evenements/microsoft/Pages/microsoft-dev-camp-reussir-la-partie-serveur-de-vos-applications-windows-8-et-windows-phone.aspx

Building Real-Time Web Apps with ASP.NET SignalR par Guillaume

SignalR est une librairie permettant de faire du temps réel et du push en http, avec des mécanismes de fallback pour des navigateurs anciens.

SignalR fait maintenant partie de ASP.Net, sera bientôt déployé avec ASP.Net, et est décomposé en 2 API (client + serveur)

Côté serveur ont fait une classe héritant de Hub, dans laquelle on met des méthodes qui seront accessibles cote client, sur le même modèle que MVC. Cote client, on va utiliser la librairie javascript associée, créer des méthodes et se connecter sur le hub. Le hub peut appeler les méthodes déclarées dans le client et vice versa. Un système de projection expose automatiquement les entites et methodes du serveur, dans l’API client.

On voit ça applique à une appli dans laquelle on peut déplacer un élément, et voir le résultat en temps réel sur un autre navigateur.

SignalR peut être utilisé pour des apps de monitoring, travail collaboratif, suivre la progression de traitements longs, …

On voit ensuite un jeu (shootr.signalr.net). On est invite a se connecte et a jouer tous ensembles sur nos tablettes ^_^

Des guidances seront publiées très prochainement pour approfondir les concepts.

SignalR peut utiliser websocket, a condition que le browser le support, et que le serveur et l’infra réseau le supporte. Si ce n’est pas le cas, SignalR va utiliser des messages par iframe ou du http long polling.

SignalR a plusieurs librairies clientes (javascript, .Net, iOS, etc) et d’autres sont en cours.

Le cœur de SignalR a été reecrit pour ameliorer les perfs, et peut traiter au moins 100000 messages/secondes/serveur, et supporte du scaling horizontal avec un système de service bus géré soit avec azure, soit reddis, soit sql server.

SignalR utilise maintenant des perfcounters pour faire du tracking, et dans les sources de SignalR, on trouve un outil de loadtest.

Guillaume

Building Real-Time Web Apps with ASP.NET SignalR par John

SignalR est une libraire permettant une communication en temps réel entre un client et un serveur (COMET, HTTP Streaming, WebSockets). C’est une abtraction d’une connexion  temps-réel en HTTP pour .NET

Après une courte introduction la session commence par une démonstration de la création d’un projet ASP.NET SignalR et de la mise en place d’un Hub et d’un client en Javascript.

Quelques exemples de jeux dont ShootR (shootr.signalr.net) qui est un jeu en temps réel où le serveur maintient la boucle de jeu.

SignalR utilise un API très simple à deux niveaux. Le bas niveau s’occupe des connections, déconnections et du broadcast sur tous les clients. Le haut niveau, les Hubs, construits au-dessus de la couche bas niveau s’occupe de la génération automatique de proxy Javascript.

Ensuite une démo de la création d’une connexion persistante avec à la fois les Connection et les Hubs.

Quid des websockets ?

Elles marchent si :

  • Le server est ASP;nET 4.5 sur Windows 2012
  • Le client utilise IE10 ou Chrome, Safari, Firefox
  • Votre proxy de load balancing le supporte
  • Votre NAT le supporte
  • Tout le monde entre le client et le supporte le supporte
  • Vous aimez coder des sockets pures
  • Vous gérez le scaling vous-même

SignalR lui fonctionne partout et essaie les websockets en cas d’échec les connections suivantes sont essayées :

  • Server Sent Event
  • Forever Frame
  • Long Polling

Ensuite on a une petite démonstration montrant comment avec le débuggeur inclus dans IE10, voir les connections entre le client et le serveur.

Il existe des clients SignalR pour :

JS, .NET SL5, Windows Store App, iOS (community), MonoTouch (community)

Dans le futur il y aura :

WP8, MonoTouch, MonoDroid et autres…

S’ensuit une démonstration montrant plusieurs types de clients connectés au même hub.

Quelques informations sur la performance ensuite.

Très grande performance sur une seule machine (100 000 messages par seconde avec une empreinte mémoire faible).

Tout étant asynchrone dans SignalR il fait une bonne utilisation des ressources.

On a aussi la possibilité de faire du scaling grâce à l’intégration d’un bus permettant de faire dialoguer différents nœud (serveurs) entre eux. Ce bus peut tourner dans le service bus azure.

Ensuite ils nous ont présenté la façon qu’ils utilisent pour faire des tests de performance sur SignalR.

Nouvelles fonctionnalités de la version 1.0.0 alpha 1

  • Meilleurs performances
  • Refonte de l’API d’invocation du client
  • Autenthification sur les HUB
  • Modules pour les HUB
  • Keep-alive sur le client

Version finale fin 2012.

Une session bien sympathique permettant de découvrir SignalR et ses capacités.

John

Angle Brackets, Curly Braces, One ASP.NET and the Cloud retranscrit par Pierre-Yves

Même en attendant le début de la session on ne s’ennuie pas avec Scott Hanselman….

http://www.youtube.com/watch?v=RwMvW9cAIZg

http://www.youtube.com/watch?v=NeTeU1frA6k

C’est parti :

Le cloud c’est cool, c’est simple, c’est rapide, ça monte en charge en 2 clics, on peut choisir son langage…

Mais le navigateur est aussi devenu une machine virtuelle avec javascript (http://contrejour.ie) et la puissance du html et des CSS (http://cssdeck.com),

A voir ne serait-ce que pour passer un bon moment !!

Pierre-Yves