Configuration ASP.NET hautes performances

Question

Je voudrais vous demander quelle est la meilleure configuration pour une application suivante:

Site Web ASP.NET 3.5 - utilisé comme couche de présentation, beaucoup d’AJAX et de JS. Ne frappe pas beaucoup le serveur.

ASP.NET WCF - Service fournissant toutes les données à l’application. Il est responsable de la validation, de la modélisation / préparation des données et de la communication avec le serveur de base de données.

Base de données - SQL Server 2005 Std, certaines logiques sont codées côté serveur en tant que procédures stockées. Une partie de la logique peut prendre un peu de temps. À mon avis, c'est la partie de l'application qui consomme le plus de ressources.

Le site Web peut avoir jusqu'à 1 000 utilisateurs par minute. Nous pouvons avoir jusqu'à 4 serveurs dans la configuration suivante: Intel Bi Xeon Quad 8x, fréquences supérieures à 2,00 GHz, 16 Go de RAM, disques SSD ou RAID.

Quel est le meilleur moyen de placer des parties de l’application sur les serveurs physiques? Vont-ils supporter ce genre de charge?

Answer 1

Dans l’application que vous décrivez, je soupçonne que la gestion des threads sera un gros problème. Lancer le matériel sur le problème peut ne pas être la meilleure approche.

En termes de partitionnement, cela dépend si vous pouvez utiliser des éléments tels que la mise en cache et les notifications de cache. Si chaque appel de l'application doit accéder à la base de données et exécuter une longue procédure stockée, vous souhaiterez peut-être disposer de plus de machines à base de données et de moins de serveurs Web frontaux.

C'est un gros sujet. Pour tenter de fournir une réponse assez complète à ce type de question, j'ai fini par écrire un livre à ce sujet: Ultra-Fast ASP.NET: créez des sites Web ultra-rapides et très évolutifs à l'aide d'ASP.NET et de SQL Server .

Answer 2

L’endroit le moins évolutif dans une application est le serveur de base de données. Vous pouvez ajouter davantage de serveurs Web et d’applications, mais vous ne pouvez pas répliquer la base de données avec la même facilité. Vous pourrez donc en tirer profit à long terme si la base de données ne contient aucune logique, en particulier aucune. longue logique. Dans la plupart des applications, le facteur limitant n’est pas le processeur, mais la mémoire pense aux sessions utilisateur. Si vous stockez 1 Mo de données par utilisateur, vos applications pourront prendre en charge 64 000 sessions utilisateur avec vos machines. Cela peut être suffisant ou non. Les deux problèmes peuvent être atténués en utilisant la mise en cache au niveau de l'application, mais cela peut entraîner son propre ensemble de problèmes, car vous avez maintenant affaire à des données obsolètes. Pour redimensionner les sites basés sur des sessions, vous devez utiliser une solution d'équilibrage de charge intelligente prenant en charge les sessions collantes. Pour vos charges, vous aurez probablement besoin d'un équilibreur de charge matérielle.