2011-05-10 3 views
1

J'ai une page qui appelle une procédure stockée pour lire 3 à 4 millions de données, faire des calculs et retourner une petite table de données. Le SP est lent env. De 20 à 30 secondes par conséquent, le chargement global de la page est lent.millions de transactions - améliorer les performances du site Web

Est-ce que je re-factoriser le SP? mais le problème est que tout ce que je fais mon résultat final sera le petit Datatable.

Y a-t-il une suggestion pour améliorer les performances?

+4

Plus de détails? Pourquoi la procédure doit-elle lire 3 à 4 millions d'enregistrements? Quelle est la structure de la table et la requête en cours d'exécution? –

+3

Vous n'avez même pas publié le moteur de base de données utilisé. Comment sommes-nous censés vous aider? –

+1

lire 3-4 millions de lignes * va * prendre du temps - Est-ce que les lignes peuvent vraiment lire ou est-ce le nombre de lignes dans le tableau? Peut-être qu'un index aiderait? Veuillez poster quelle base de données vous utilisez. – vidstige

Répondre

1

Si la table n'est pas mise à jour, créez souvent une table "agrégée" avec de meilleures performances.

+0

table agrégée? – Magnus

+0

J'ai utilisé SQL Server 2008. Le script SP est créé pour agréger les données de plus de 5 tables. le curseur est évité et j'ai besoin du groupe par toutes les données pour faire le petit tableau de données. C'est en fait une matrice comme une table de données. – Shuvra

+0

mais je peux exécuter ce sp en arrière-plan avant de charger cette page. Serait-ce une bonne idée d'utiliser SOAP? – Shuvra

1

Si vous tournez à travers 3 ou 4 millions de lignes de données et que vous réalisez un vrai travail, 20 ou 30 secondes sont des performances assez décentes, à mon humble avis. Vérifiez le plan d'exécution de votre procédure stockée. Dans le monde idéal, chaque table serait frappée par des recherches d'index plutôt que par des scans de table. Consultez votre DBA si vous ne savez pas comment interpréter les résultats de showplan. Je suppose que vous utilisez SQL Server.

Assurez-vous que vos tables ont des index appropriés et que les statistiques sont à jour. Mettez-les à jour si non. Recompilez la procédure stockée. Les paramètres passés à la procédure stockée peuvent augmenter le plan d'exécution mis en cache, s'il s'agit de valeurs impaires. Vous pouvez éviter cela en coder votre procédure stockée comme ceci:

create proc myProc 

    @p1 varchar(32) 

as 

    declare 
    @p1Local varchar(32) 

    set @p1Local = @p1 

    ... 
+0

J'ai l'index d'utilisation dans les tables et le plan de requête semble correct. mais je peux courir ce sp dans le fond avant de charger cette page. Serait-ce une bonne idée d'utiliser SOAP? – Shuvra

+0

Qu'est-ce que SOAP a à voir avec le temps d'exécution d'une procédure stockée? –

+0

Désolé, j'ai une très petite idée de WCF/SOAP. En fait, je travaille sur une application web. par conséquent, je pense, la page où ce SP devrait appeler et charger l'ensemble de données. Au lieu de le faire si j'appelle le SP dans la page précédente, alors l'utilisateur peut voir que la page actuelle se charge plus vite que la normale. le paramètre SP est sélectionné à l'ouverture de session. De cette façon, je peux améliorer slaidly la performance. Est-ce que c'est une bonne idée? plus de suggestion. Merci beaucoup pour votre aide. – Shuvra

0

Si vos données ne soit mise à jour trop souvent, vous pouvez créer une vue indexée.

http://msdn.microsoft.com/en-us/library/dd171921(v=sql.100).aspx:

vues indexées offrent des avantages supplémentaires qui ne peuvent être obtenus en utilisant des index standard. Les vues indexées peuvent augmenter les performances des requêtes de la manière suivante: Les agrégations peuvent être précalculées et stockées dans l'index afin de minimiser les calculs coûteux lors de l'exécution de la requête. Les tables peuvent être jointes et l'ensemble de données résultant peut être stocké. Des combinaisons de jointures ou d'agrégations peuvent être stockées.

Questions connexes