none
Pb de performance ASP.Net sur Windows Server 2008 x64 RRS feed

  • Question

  • Bonjour,

    Nous avons réalisé une application ASP.NET qui s'appuie sur des assemblies managées développées en C# 4.0. Nous compilons cette application et ses composants avec les options par défaut de VS2010, c'est à dire en mode AnyCPU et optimisation de code.

    Cette application fonctionne depuis pluisieurs année en 32bits. Dernièrement, liée à une montée en charge de l'application nous avons choisi de migrer vers un mode 64bits (charge memoire > 2Go). Nous nous sommes rapidement aperçus qu'elle fonctionnait sans erreur mais que la plus parts des traitements étaient de 3 à 10 fois plus lent.

    Est-ce normal ? Il me semblait que le code compilé en .Net n'était pas dépendant de la plateforme. Les tests de ces derniers jours me montrent le contraire. Que dois-je faire pour retrouver des performances proches des environnements 32bits : Compiler en mode 64 bits  sous VS2010 ?

    Merci pour vos réponses.

    mardi 6 mars 2012 11:19

Réponses

  • Bonjour,

    Avez-vous désactivé l'option "Activer les applications 32-bits" dans les propriétés avancés de votre pool d'applications.

    D'expérience, à 95% les problèmes de performances ne sont pas dû à l'environnement d'exécution (IIS, Windows,...etc) mais à des défauts de conception dans le code (majoritairement dans la BD).

    Quel sont les traitements qui posent problèmes ?

    La compilation 64-bits pur (contrairement à l'option Any CPU) permet juste d'accélerer le démarrage de l'application .

    Cordialement


    Gilles TOURREAU - MVP C#
    Architecte logiciel/Consultant/Formateur Freelance
    Blog : http://gilles.tourreau.fr
    - MCPD : Enterprise Developper / Windows Developper 3.5 / ASP .NET 3.5/4.0
    - MCITP : SQL Server 2008 Developper
    - MCTS : ADO .NET 3.5 / SQL Server 2008 Developper / Windows Forms 3.5 / ASP .NET 3.5/4.0

    mardi 6 mars 2012 11:55
    Modérateur
  • Bonjour,

    Pour trouver facilement et rapidement d'où proviennent les lenteurs dans le code de votre application ASP .NET quand celle-ci est exécutée en mode 64 bits, vous devez la profiler en mode 64 bits. Pour ce faire, vous pouvez utiliser un Profiler comme DotTrace par exemple.

    Vous pouvez aussi tester les performances de votre application sans la profiler et directement depuis IIS en utilisant ASP .NET Perfecto mais vous n'aurez la granularité d'un profiling.

    Cordialement,


    My blog

    Whether you’re a construction worker, a forum moderator, or just someone that likes helping people. I think these guidelines can be helpful in keeping you helpful when being helpful.

    mercredi 7 mars 2012 23:00
    Auteur de réponse
  • J'ai finalement trouver le pb.

    Les lenteurs étaient produites par un appel à la methode IsMatch de la classe Regex. En effet il y a a priori des lenteurs connues dans la gestion des expressions régulières en x64. Ces lenteurs ne sont pas présentes en x86.

    En simplifiant les expressions régulières et en créant des singletons de instance RegExp afin de ne pas systématiquement recréer les instances, les temps de réponses ont convergé entre le x64 et le x86.

    mercredi 11 avril 2012 09:56

Toutes les réponses

  • Bonjour,

    Avez-vous désactivé l'option "Activer les applications 32-bits" dans les propriétés avancés de votre pool d'applications.

    D'expérience, à 95% les problèmes de performances ne sont pas dû à l'environnement d'exécution (IIS, Windows,...etc) mais à des défauts de conception dans le code (majoritairement dans la BD).

    Quel sont les traitements qui posent problèmes ?

    La compilation 64-bits pur (contrairement à l'option Any CPU) permet juste d'accélerer le démarrage de l'application .

    Cordialement


    Gilles TOURREAU - MVP C#
    Architecte logiciel/Consultant/Formateur Freelance
    Blog : http://gilles.tourreau.fr
    - MCPD : Enterprise Developper / Windows Developper 3.5 / ASP .NET 3.5/4.0
    - MCITP : SQL Server 2008 Developper
    - MCTS : ADO .NET 3.5 / SQL Server 2008 Developper / Windows Forms 3.5 / ASP .NET 3.5/4.0

    mardi 6 mars 2012 11:55
    Modérateur
  • Gilles,

    Merci de votre réponse.

    en effet nous avons bien désactiver l'option "Activer les applications 32-bits" pour fonctionner en "pur x64".

    Concernant les problèmes de performances, je veux bien croire que c'est un défaut de code, mais l'application fonctionne parfaitement en mode 32 bits ou sur des environnement web 32bits.

    Si vous me confirmez donc que l'activation lors de la compilation du mode x64 peut accélerer l'application dans ce contexte, je vais essayer de modifier notre système de build pour faire un test dans ce sens.

    mardi 6 mars 2012 12:46
  • Bonjour,

    La compilation x64 accélère uniquement le démarrage de l'application et non la vitesse d'exécution de l'application.

    Si vous rencontrez toujours des problèmes, merci de nous indiquer et de nous décrire les traitements qui posent problème dans votre application.

    Cordialement


    Gilles TOURREAU - MVP C#
    Architecte logiciel/Consultant/Formateur Freelance
    Blog : http://gilles.tourreau.fr
    - MCPD : Enterprise Developper / Windows Developper 3.5 / ASP .NET 3.5/4.0
    - MCITP : SQL Server 2008 Developper
    - MCTS : ADO .NET 3.5 / SQL Server 2008 Developper / Windows Forms 3.5 / ASP .NET 3.5/4.0

    mardi 6 mars 2012 12:56
    Modérateur
  • Bonjour,

    Pour trouver facilement et rapidement d'où proviennent les lenteurs dans le code de votre application ASP .NET quand celle-ci est exécutée en mode 64 bits, vous devez la profiler en mode 64 bits. Pour ce faire, vous pouvez utiliser un Profiler comme DotTrace par exemple.

    Vous pouvez aussi tester les performances de votre application sans la profiler et directement depuis IIS en utilisant ASP .NET Perfecto mais vous n'aurez la granularité d'un profiling.

    Cordialement,


    My blog

    Whether you’re a construction worker, a forum moderator, or just someone that likes helping people. I think these guidelines can be helpful in keeping you helpful when being helpful.

    mercredi 7 mars 2012 23:00
    Auteur de réponse
  • J'ai finalement trouver le pb.

    Les lenteurs étaient produites par un appel à la methode IsMatch de la classe Regex. En effet il y a a priori des lenteurs connues dans la gestion des expressions régulières en x64. Ces lenteurs ne sont pas présentes en x86.

    En simplifiant les expressions régulières et en créant des singletons de instance RegExp afin de ne pas systématiquement recréer les instances, les temps de réponses ont convergé entre le x64 et le x86.

    mercredi 11 avril 2012 09:56
  • Bonjour,

    Grand merci pour votre retour pour en faire profiter la communauté.
    Avez-vous pensé à spécifier l'option "Compiled" (http://msdn.microsoft.com/en-us/library/system.text.regularexpressions.regexoptions.aspx). dans les options du constructeur Regex() ? Cela peut ralentir le démarrer du premier appel à Regex, mais si vous faites un singleton, cela va booster vos IsMatch() suivants...

    Cordialement


    Gilles TOURREAU - MVP C#
    Architecte logiciel/Consultant/Formateur Freelance
    Blog : http://gilles.tourreau.fr
    - MCPD : Enterprise Developper / Windows Developper 3.5 / ASP .NET 3.5/4.0
    - MCITP : SQL Server 2008 Developper
    - MCTS : ADO .NET 3.5 / SQL Server 2008 Developper / Windows Forms 3.5 / ASP .NET 3.5/4.0

    mercredi 11 avril 2012 17:50
    Modérateur
  • Bonjour,

    Nous avons fait des tests avec et sans l'option. Dans notre cas et en x64, il est plus interessant de ne pas mettre l'option compiled.

    A priori, la compilation des RegExp en x64 n'est pas très optimisé. :-(.

    Merci pour votre aide et bonne continuation à tous.

     
    jeudi 12 avril 2012 13:05