none
PageMethods, Linq to SQL, stopper les requettes SQL RRS feed

  • Question

  • Bonjour,

    J'ai une question concernant AJAX et l’exécution de longues requêtes SQL.

    Sur notre application web (c#, ASP.Net) nous avons choisi d'utiliser les PageMethods pour charger le contenu (les données) de certaines interfaces de manière asynchrone. L'utilisateur peut donc avoir un affichage rapide de ses pages, les données étant chargées l'une après l'autre après le chargement complet du squelette de la page. L'utilisateur peut ainsi changer de page rapidement sans avoir a attendre le chargement complet des données qui est assez long car il y a derrière de grosse requêtes sql qui prennent entre 10 et 60s voir plus. Une question me vient donc à l'esprit y a t-il un mécanisme qui stoppe automatiquement les requêtes SQL une fois exécutées via les PageMethods et Linq to SQL si l'utilisateur recharge la page? Sinon l'utilisateur peut lancer de nombreuses fois la page en faisant F5 et ainsi surcharger le serveur sql?

    Deuxième question s'il n'y pas de mécanisme qui gère ceci, est-ce possible de stopper les requêtes  si l'utilisateur change de page ou recharge la page?



    mercredi 23 octobre 2013 09:32

Réponses

  • Bonjour

    Essayez d’optimiser les requêtes SQL et faites les calculs avec SQL. Utiliser des mécanismes de cache pour ne pas sur charger la BD vous sera aussi utile.  A la limite, séparer les tables de reportant de ceux d'utilisation normale, et avoir les données traitées dans des tables dédiées aux reports. 

    Par exemple vous voulez afficher la consommation d'énergie, une solution c’est d’avoir une table qui contient la consommation d’énergie par jour/par groupe de batiments et pour la rapporter faire le select directement sur cette table.  Vous pouvez le remplir avec un SQL Task qui est exécutée chaque quelques minutes , une fois par jour , avec des triggers etc…., selon vos besoins.

    En plus, dans votre cas, je dirais que utilizer  un  Entrepôt de données sera utile.

    Cordialement,


    Aurel BERA, MSFT
    MSDN Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE.
    S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votre problème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.



    jeudi 24 octobre 2013 10:12

Toutes les réponses

  • Bonjour,

    car il y a derrière de grosse requêtes sql qui prennent entre 10 et 60s voir plus
    Il faut absolument éviter de faire ce genre de requête SQL car vous allez saturer :

    • L'utilisation mémoire/disque dur de votre SGBD
    • Les blocages relativement long au niveau de certaines table de votre SGB
    • L'utilisation réseau entre votre SGBD et votre serveur ASP .NET
    • L'utilisation mémoire + CPU de votre ASP .NET

    Vous multipliez ces problèmes par 5 utilisateurs simultanés et c'est toute votre infrastructure qui est a genoux... J'interviens au moins une fois par mois chez des clients sur ce genre de problème (le plus souvent en urgence car l'application est passé en prod). Le plus souvent les clients pensent que les problèmes de performances proviennent du fait que les technologies Microsoft c'est "pipi-caca", ou alors il suffit de multiplier le nombre de serveur par 10 pour pouvoir supporté 100 utilisateurs simultanés....

    Ce problème est à remédier en amont au niveau de votre requête SQL :

    • Votre requête ne doit récupérer CE QUE VOUS AVEZ REELLEMENT BESOIN. Donc ce n'est pas la peine de télécharger un million de lignes pour en afficher que 10 à l'utilisateur ! Récupérer donc que les 10 lignes qui vous intéresse.
    • Si votre requête retourne 10 lignes, mais elle prend 10 à 60 secondes pour s'exécuter, c'est que votre requête nécessite une optimisation (au niveau de son écriture, index, schéma de la base de données,...)
    • Si vous affichez un million de lignes à l'utilisateur, votre application se trouvera dans la catégorie des applications de type "merdique" au niveau ergonomie. Au 21 siècle ces applications n'ont plus aucun succès pour être utilisé par des utilisateurs. Essayez de rechercher un élément dans un tableau de 1 million d'éléments.... C'est donc à vous de proposer une IHM plus simple qui affiche que ce que l'utilisateur souhaite récupérer !

    Donc oubliez vos bricolages au niveau de ASP .NET...

    Une question me vient donc à l'esprit y a t-il un mécanisme qui stoppe automatiquement les requêtes SQL une fois exécutées via les PageMethods et Linq to SQL si l'utilisateur recharge la page?
    Non.

    Sinon l'utilisateur peut lancer de nombreuses fois la page en faisant F5 et ainsi surcharger le serveur sql?
    L
    'utilisateur lambda peut-être pas.... Mais les utilisateurs mal intentionnés oui ! Et il ne feront pas qu'appuyer sur F5, il essayeront d'envoyer 1000 requêtes simultanées...

    Cordialement


    Gilles TOURREAU - MVP C#
    Architecte logiciel/Consultant/Formateur Freelance - P.O.S Informatique
    Blog : http://gilles.tourreau.fr - Suivez-moi sur Twitter
    - MCPD : Enterprise Developper / Windows Developper 3.5 / ASP .NET 3.5/4.0
    - MCSA : SQL Server 2012
    - MCITP : SQL Server 2008 Developper
    - MCTS : ADO .NET 3.5 / SQL Server 2008 Developper / Windows Forms 3.5 / ASP .NET 3.5/4.0 / TFS 2010 / Windows Azure

    mercredi 23 octobre 2013 16:10
    Modérateur
  • Il y'a bien des millions de lignes de facturation, mais il ne s'agit pas de récupérer 10 lignes dedans, il s'agit de requêtes qui récupère des milliers de lignes voir centaines de milliers de lignes de facturations pour ainsi faire des restitutions graphiques de consommation sur des mois, des années sur des milliers de bâtiments. On affiche donc pas un millier de lignes, mais on a besoin de ce millier de lignes pour afficher un graphique de consommation d'énergie ou d'émission de CO2




    jeudi 24 octobre 2013 07:18
  • Bonjour

    Essayez d’optimiser les requêtes SQL et faites les calculs avec SQL. Utiliser des mécanismes de cache pour ne pas sur charger la BD vous sera aussi utile.  A la limite, séparer les tables de reportant de ceux d'utilisation normale, et avoir les données traitées dans des tables dédiées aux reports. 

    Par exemple vous voulez afficher la consommation d'énergie, une solution c’est d’avoir une table qui contient la consommation d’énergie par jour/par groupe de batiments et pour la rapporter faire le select directement sur cette table.  Vous pouvez le remplir avec un SQL Task qui est exécutée chaque quelques minutes , une fois par jour , avec des triggers etc…., selon vos besoins.

    En plus, dans votre cas, je dirais que utilizer  un  Entrepôt de données sera utile.

    Cordialement,


    Aurel BERA, MSFT
    MSDN Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE.
    S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votre problème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.



    jeudi 24 octobre 2013 10:12
  • Bonjour

    Avez-vous des nouvelles pour nous?

    Merci!

    Cordialement, 


    Aurel BERA, MSFT
    MSDN Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE.
    S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votre problème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.

    vendredi 25 octobre 2013 12:45