Discussion :

[Matth_S]

Bonjour à tous,

Je ne sais pas si je suis sur la bonne section du forum, car mon problème concerne la config de mon serveur dans sa globalité (IIS / SQL Server / .NET etc)

Voila, la config de mon serveur est la suivante :
IIS 5
Windows 2000 Server
SQL Server 2000 SP4

J'ai récemment fait activé l'HTTP compression de IIS pour réduire le poids des pages, ainsi qu'une DLL qui gère le rewriting d'URL.

Depuis quelques jours, le serveur charge beaucoup trop (CPU occupé à 95%), et j'essaye de résoudre ce problème. J'ai activé la mise en cache d'une partie de l'appli, mais apparemment, cela a saturé la RAM (systemOutOfMemory exception).
Je vais tenter de mettre une plus petite partie de l'appli en cache en espérant trouver le juste milieu entre libérer le CPU et sans trop charger la RAM, mais j'essaye de trouver d'autres pistes à tester.
- Voyez-vous d'autres critères que je pourrais modifier au niveau de l'appli ?
- si la charge persiste, pensez-vous qu'en passant sur un IIS 7 / Windows Serveur 2008 / SQL Serveur 2008 cela va résoudre mon problème (la version 2000 a plus de 10 ans, je me dis que la dernière version doit surement mieux gérer les ressources non ?).

Merci !

[Nicolas Esprit]

Bonjour,

Il te faudrait déjà identifier la cause du problème avant d'envisager un changement de serveur (au passage si tu as les moyens et la possibilité, mieux vaut toujours séparer le serveur Web du serveur SQL... enfin ça dépend de la taille de l'application aussi).

Bref, as-tu fait un peu de monitoring ? Est-ce IIS qui consomme beaucoup ? Si oui pour combien d'utilisateurs connectés ? Est-ce que l'utilisation de la RAM est constante ou fonction du nombre d'utilisateurs ?
Est-ce SQL Server ? Si oui, quelles requêtes, que peux-tu optimiser ? Etc...

Sinon, combien de RAM as-tu pour faire tourner conjointement IIS et SQL Server ?

Il y a encore beaucoup de questions de ce type à se poser.

[Matth_S]

Merci pour ta réponse !

Malheureusement, je n'ai que peu d'informations, je ne suis pas administrateur de la machine, mon serveur web est en infogérance chez mon hébergeur.
J'ai fait redémarrer le serveur ce matin, donc la charge est descendue, mais j'ai demandé à mon hébergeur de surveiller le processus qui consomme en CPU à la prochaine charge du serveur.

Ce que je sais c'est que la machine a 4 Go de RAM, le trafic mensuel est de 300 000 VU/mois, en moyenne lorsque ça charge, on est entre 600 et 700 VU sur une heure, mais je n'ai pas le nombre de connexions simultanées.

On ne peut malheureusement pas séparer le serveur SQL du serveur web, comme on est en infogérance, cela ferait trop grimper le coup de l'hébergement. C'est d'ailleurs pour cela que si l'on arrive pas à résoudre le problème de charge en jouant sur les paramètres de l'application, j'hésite à louer un 2e serveur + load balancer car c'est couteux, ou à basculer sur du 2008, car ce sera peut être couteux pour acheter les licences, mais le coup de l'hébergement devrait rester le même. Je ne sais juste pas si basculer sur du 2008 aura vraiment un impact sur les perfs, ou si ce sera négligeable par rapport à l'investissement.

Sais-tu si il existe des logs des slow Query sur SQL Server ? Il y a effectivement beaucoup de requêtes qui tournent, j'ai limité le plus possible le nombre de requête mais il y a tout de même des requêtes lourdes et j'aimerais savoir lesquelles.

[Nicolas Esprit]

OK, il est sûr que sur un hébergement en infogérance on ne peut tout faire (ni tout s'offrir surtout...).

Déjà, pour surveiller ta base tu peux utiliser SQL Server Profiler et faire un tour sur le forum SQL Server. De nombreux DBA plus expérimentés que moi dans ce domaine pourrait te guider.

Ensuite concernant la compression ce n'est pas la solution à tout. Ok, la taille des pages renvoyée du serveur Web au client est réduite, mais si le résultat n'est pas mis en cache il y a compression à chaque requête. Et qui dit compression dit consommation CPU :

La compression des réponses d'applications dynamiques peut affecter les ressources processeur, car IIS ne met pas en cache les versions compressées de sortie dynamique. Si la compression est activée pour les réponses dynamiques et qu'IIS reçoit une demande pour un fichier qui contient un contenu dynamique, la réponse qu'IIS envoie est compressée à chaque demande. Dans la mesure où la compression dynamique consomme une quantité importante de temps processeur et de ressources mémoire, utilisez-la uniquement sur les serveurs qui ont des connexions réseau lentes, mais du temps processeur de libre.

Le problème de conso CPU est intervenu après l'activation de la compression ou ça n'a rien à voir ?

Si c'est la cause du problème et que tu souhaite la gardée activée, tu devrais surtout penser à la mise en cache de sortie. 600 pages vues par heure donne une moyenne d'une page vue toutes les 6 secondes, c'est plus que gérable avec un serveur de base.

En espérant t'avoir aidé.

[Matth_S]

Merci pour ta réponse !

Le problème de la conso CPU est intervenu peu de temps après l'activation de la compression HTTP (dans la même semaine mais pas immédiatement après).
En fait j'ai besoins de l'HTTP compression pour diminuer le poids des pages car elles sont vraiment lourdes. Même le webmaster tools de Google me dit de Gziper mes pages pour les alléger. Vu que poids des pages + temps de chargement est un critère de référencement, j'essaye de ne pas me pénaliser en ayant des pages trop lourdes. Il faudrait donc que j'arrive à la conserver sans trop prendre sur le CPU.

Qu'entends tu pars "mise en cache de sortie". Tu veux dire qu'actuellement j'ai

- Execution -> mise en cache -> GZip : En gros, le Gzip se fait à chaque consultation

et ce que tu me suggères c'est :

- Execution -> GZip -> mise en cache ?

C'est bien ça ? Si c'est ça, ce sera effectivement super par contre, je n'ai aucune idée de comment je peux gérer ça. J'utilise la mise en cache "basique" des pages .NET (balise Outputcache). Tu as des pistes sur lesquelles je pourrais me renseigner ?

En attendant, je vais déjà regarder SQL Profiler ! Merci pour ton aide

[Nicolas Esprit]

Bonjour,

Il existe plusieurs techniques de cache (Output Cache, Data Cache, etc.), et également plusieurs façons de les mettre en œuvre : avec IIS ( pour cela la version 7 est toujours mieux que la 6 qui est toujours mieux que la 5. Un article intéressant qui compare IIS 7 et 6), ou ASP.NET.

Côté IIS je ne suis pas expert. Travaillant surtout sur des projets où les serveurs Web sont gérés par des admins, je me concentre généralement sur la partie ASP.NET.

Ce que j'ai l'habitude de faire c'est de mettre en place des HttpModules ou HttpHandler pour gérer plusieurs choses : la compression, le minifying, et la mise en cache. Exemple : combiner plusieurs fichiers javascript en un seul pour éviter les aller-retours client/serveur, puis minifier celui-ci, puis compression du fichier combiné, pour enfin le mettre en cache. Même chose pour les fichiers .css. Ou encore un HttpHandler pour gérer les différents types d'images (compression si possible selon le format, puis mise en cache).

J'ai appris de très nombreuses choses en lisant les très bons articles d'Omar Al Zabir, MVP depuis plusieurs années et créateur de dropthings. Je t'invite à consulter ceux-ci :

• 10 ASP.NET Performance and Scalability Secrets
• HTTP Handler to Combine Multiple Files, Cache and Deliver Compressed Output for Faster Page Load

Plus généralement, il y a pas mal de petites choses utiles à mettre en place pour améliorer les performances d'une application ASP.NET. Ces deux billets en listent une partie mais il existe pas mal d'autres blogs qui donnent des conseils à ce sujet. Évidemment, dans certains cas les performances ne sont pas améliorées voire le contraire. Cela dépend bien entendu de l'application, du type traitements, du serveurs, etc.

• 50 Tips to Boost ASP.NET Performance – Part I
• 50 Tips to Boost ASP.NET Performance – Part II

J'envisage depuis quelques temps de mettre en place une série d'articles sur les performances d'une application ASP.NET, la mise en cache, le load balancing, les stress test et scénarios de validations, etc. Mais... faut trouver le temps

Autre chose, les webmaster tools de Google c'est bien, mais il y a beaucoup mieux. Tu peux par exemple utiliser des extensions Firefox qui fonctionnent avec Firebug (ou l'équivalent pour d'autres navigateurs) de ce type :

• Yahoo! YSlow
• Page Speed de Google
  

Voilà, N'hésite pas si tu as d'autres questions.

En espérant t'avoir aidé.

[Matth_S]

Merci pour ta réponse et pour les liens ! Ils sont très intéressants, cela me donne pas mal de pistes à essayer. Il ressort également que IIS5 est assez mauvais pour la compression HTTP, il faut donc impérativement que je bascule sur du IIS6 ou 7. Je pense d'ailleurs qu'un article qui explique tous les éléments d'optimisation des perfs serait une mine d'or pour les développeurs.

Par contre, il y a des choses que j'ai lu dans les articles sur lesquels j'avais déjà lu le contraire ou sur lesquelles j'aurais bien aimé un exemple concert.

Store Cacheable Files in a Different Domain

It's always a good idea to put static contents in a different domain. First of all, the browser can open other two concurrent connections to download the static files. Another benefit is that you don't need to send the cookies to the static files. When you put the static files on the same domain as your Web application, browser sends all the ASP.NET cookies and all other cookies that your Web application is producing. This makes the request headers unnecessarily large and waste bandwidth. You don't need to send these cookies to access the static files. So, if you put the static files in a different domain, those cookies will not be sent. For example, put your static files in www.staticcontent.com domain while your website is running on www.dropthings.com. The other domain does not need to be a completely different Web site. It can just be an alias and share the same Web application path.

Cela implique que je peux coller mes CSS et JS sur un domaine différent ? Mais ce que je ne comprends pas c'est que cela me rajoute des résolutions DNS, d'ailleurs le webmaster tools de google m'avait signalé un point à optimiser la dessus.

Besides the processModel, there's another very important section with the system.net where you can specify the maximum number of outbound requests that can be made to a single IP.
Collapse

<system.net>
<connectionManagement>
<add address="*" maxconnection="100" />
</connectionManagement>
</system.net>

Default is 2, which is just too low. This means you cannot make more than 2 simultaneous connections to an IP from your Web application. Sites that fetch external content a lot suffer from congestion due to the default setting. Here I have set it to 100. If your Web applications make a lot of calls to a specific server, you can consider setting an even higher value.

La je ne vois pas concrètement de quoi il s'agit ? De quel type de connexion il s'agit ? Une bête connexion entre un client et mon serveur ? Ce qui veut dire que par exemple un robot ne peut pas établir plus de 2 connexions simultanées, c'est mal pratique. Ou alors, ce sont les connexions que j'établis dans le code avec des objets WebRequest et WebResponse ? Ci c'est le cas, cela me gène beaucoup moins car j'utilise ça très rarement.

[Nicolas Esprit]

Cela implique que je peux coller mes CSS et JS sur un domaine différent ? Mais ce que je ne comprends pas c'est que cela me rajoute des résolutions DNS, d'ailleurs le webmaster tools de google m'avait signalé un point à optimiser la dessus.

Là dessus je ne saurais dire. Peut être a-t-il dans l'idée de mettre en place un Content Delivery Network avec plusieurs domaines et donc serveurs différents ?

La je ne vois pas concrètement de quoi il s'agit ? De quel type de connexion il s'agit ? Une bête connexion entre un client et mon serveur ? Ce qui veut dire que par exemple un robot ne peut pas établir plus de 2 connexions simultanées, c'est mal pratique. Ou alors, ce sont les connexions que j'établis dans le code avec des objets WebRequest et WebResponse ? Ci c'est le cas, cela me gène beaucoup moins car j'utilise ça très rarement.

Disons que lorsqu'un explorateur web télécharge une page (on va dire ASP.NET), il doit télécharger la page HTML, les images, les javascripts, les css, etc.. A chaque objet téléchargé correspond une requête HTTP. Les browsers le font en parallèle et non en séquentiel. Par défaut les applications ASP.NET acceptent 2 connexions simultanées. L'idée ici est d'augmenter cette limite. Du moins c'est comme ça que je le comprend.
Toutefois je suis étonné que la limite soir fixée à 2 par défaut. Il faut voir aussi comment IIS gère les connexions de son côté aussi. Bref, je vais me renseigner.

En espérant t'avoir aidé.

[Nicolas Esprit]

MSDN est plus clair :

HTTP Two-Connection Limit

The HTTP specification indicates that an HTTP client should make a maximum of two simultaneous TCP connections to any single server. This keeps a single browser from overloading a server with connection requests when it browses to a page with, say, 120 embedded thumbnail images. Instead of creating 120 TCP connections and sending an HTTP request on each, the browser will only create 2 connections and then start sending the 120 HTTP requests for the thumbnail images on those two pipes. The problem with this approach on the middle tier is that your middle tier may have 50 simultaneous users. If you have to make a MapPoint .NET Web service call for each of those users, then you will have 48 users sitting around waiting in line for one of those two pipes to free up.

The default two-connection limit for connecting to a Web resource can be controlled via a configuration element called connectionManagement. The connectionManagement setting allows you to add the names of sites where you want a connection limit that is different than the default. The following can be added to a typical Web.config file to increase the default value for all servers you are connecting, to a connection limit of 40.

<configuration>
<system.net>
<connectionManagement>
<add address="*" maxconnection="40" />
</connectionManagement>
</system.net>

<system.web>
...

It should be noted that there is never a limit to the number of connections to your local machine, so if you are connecting to localhost, this setting has no effect.

[Matth_S]

Merci pour tes réponses et explications !

C'est beaucoup plus clair, je n'ai pas encore mis en place la totalité des recommandations, mais j'observe déjà une bonne amélioration des perfs.

Par contre, je suis en train de tester le Gzip, ça tourne aussi mais je voudrais éviter de Gzipper à chaque consultation de page. Tu parlais du "cache de sortie", j'ai été regarder les différents types de cache sur plusieurs sites dont msdn, et quand ils parlent de cache de sortie, c'est l'outputcache que j'utilise déjà (qui est d'ailleurs le plus simple à mettre en place). Est-ce que cela veut dire que le page mise en cache est déjà Gzippée ? Ou est-ce que ce n'était pas ça dont tu parlais.

[Nicolas Esprit]

Content de voir que ces quelques infos te sont utiles

Concernant la compression et le cache. Si tu compresses toutes tes réponses (via par exemple le Global.asax ou un HttpModule) et que tu activess le cache dans IIS, alors IIS gardera le contenu déjà zippé. A chaque nouvelle requête il n'y aura pas de nouvelle compression vu que ça proviendra tel quel du cache.

Sinon, concernant les HttpHandlers pour les ressources statiques commes les images, les scripts, les css, l'idéal est de les zipper puis de les mettre en cache comme dans les exemples d'Omar Al Zabir. A chaque nouvelle requête sur un telle ressources, plus de compression non plus.

En espérant t'avoir aidé.

[Matth_S]

Merci pour tes explications !

Je vais regarder comment activer le cache dans IIS. Pour le moment, je mettais en cache la totalité des pages via "outcache" (qui est d'ailleurs la seule façon de mettre en cache que je connaisse en .NET). Par contre, ça ne semble effectivement pas mettre en cache le Gzip puisque l'application_BeginRequest du global.asax est toujours exécuté (j'ai testé pour vérifier) et que c'est dans cet évènement que je Gzippe.

EDIT :
Arg, la mise en cache de sortie dans IIS ne se fait que sur IIS 7
J'en viens au même problème, je ne peux rien faire avec IIS 5, il faut absolument que je passe sur un Server 2008.


Un truc étonnant que j'ai remarqué :
- si une page contient un contrôle avec un "postBackUrl", alors l'application_BeginRequest est appelé 2 fois. C'est bizarre, cela veut dire que je double tous les traitements qui s'exécutent dedans