Problème de performance ASP.NET/SQL 2008

Nous avons développé un système avec un écran de recherche qui ressemble un petit quelque chose comme ceci:

_{(source: Nsourceservices.com )}

Comme vous pouvez le constater, il existe des fonctionnalités de recherche assez graves. Vous pouvez utiliser n'importe quelle combinaison de statuts, de canaux, de langues, de types de campagnes, puis de le réduire ensuite par nom et ainsi de suite.

Puis, une fois que vous avez fouillé et que les câbles apparaissent en bas, vous pouvez trier les en-têtes.

La requête utilise Rownum pour faire un schéma de radiomessagerie, nous ne renvoyons donc quelque chose comme 70 lignes à la fois.

le problème

Même si nous ne retournons que 70 lignes, beaucoup d'IO et de triont. Cela donne un sens bien sûr.

Cela a toujours causé des pointes mineures à la file d'attente de disque. Cela a commencé à ralentir plus lorsque nous atteignons 3 millions de prospects, et maintenant que nous nous rapprochons de 5, la file d'attente de disque piquets jusqu'à une seconde ou deux droite parfois.

Ce serait toujours difficile, mais ce système a une autre zone avec un processus sensible au temps, disons pour la simplicité qu'il s'agit d'un service Web, qui doit servir des réponses très rapidement ou cela entraînera un délai d'attente de l'autre. finir. Les pointes de la file d'attente de disque provoquent cette partie de la tourbière, ce qui provoque des délits en aval. Le résultat final est en fait abandonné les appels téléphoniques dans notre IVR automatisé basé sur voixXML, et c'est très mauvais pour nous.

ce que nous avons essayé

Nous avons essayé:

• Tâches de maintenance qui réduisent le nombre de prospects dans le système au strict minimum.
• a ajouté les indices évidents pour aider.
• a dirigé l'assistant de syntonisation d'index dans le profileur et appliqué la plupart de ses suggestions. L'un d'entre eux allait se reproduire plus ou moins de reproduire toute la table dans un index alors je l'ai modifié à la main pour faire un peu moins que cela.
• a ajouté plus de RAM sur le serveur. C'était un peu bas mais maintenant, il a toujours quelque chose comme 8 gigs inactif, et le serveur SQL est configuré pour ne pas utiliser plus de 8 concerts, mais elle n'utilise jamais plus de 2 ou 3. J'ai trouvé cela impair. Pourquoi ne pas simplement mettre la table entière dans la RAM? Ce n'est que 5 millions de prospects et il y a beaucoup de place.
• a versé des plans d'exécution de requête. Je peux voir qu'à ce stade, les index semblent principalement faire leur travail - environ 90% des travaux se produisent pendant la phase de tri.
• considérés comme partitionnement de la table des prospects à un lecteur physique différent, mais nous n'avons pas les ressources pour cela, et cela semble que cela ne devrait pas être nécessaire.

  en fermeture ...

  Une partie de moi semble que le serveur devrait pouvoir gérer cela. Cinq millions d'enregistrements ne sont pas essentiellement étant donné la puissance de ce serveur, qui est un noyau quadrial décent avec 16 concerts de RAM. Cependant, je peux voir comment la partie de tri provoque des millions de lignes à toucher juste pour renvoyer une poignée.

  Alors qu'as-tu fait dans des situations comme ça? Mon instinct est que nous devrions peut-être réduire certaines fonctionnalités, mais s'il y a un moyen de garder cette intacte qui me sauvera une guerre avec l'unité commerciale.

  Merci d'avance!