Évolutivité, performance dans une application web .net

Question

Je travaille sur un portail .net qui aurait beaucoup d'utilisateurs simultanés. donc l'évolutivité, la performance doit être abordée dans la conception et l'architecture. Nous prévoyons d'utiliser l'équilibrage de charge dans l'application. En gardant cela à l'esprit, quelle serait la meilleure façon de communiquer entre le serveur Web IIS (hébergement aspx, fichiers aspx.cs) et le serveur d'applications (hébergement des assemblages .net comme la logique métier et la couche d'accès aux données)? Faut-il utiliser .net remoting ou soap web service? Ou y at-il une autre approche?

Merci.

Answer 1

Y a-t-il une autre approche? Oui - ne distribuez pas vos objets. L'approche la plus évolutive consiste à NE PAS distribuer vos objets les uns aux autres. Demandez-vous, pourquoi voulez-vous déployer une saveur de code sur un "serveur d'application" alors qu'une autre saveur de code va à un "serveur web"? La communication qui se passe entre ces deux couches, si elles sont distribuées, sera beaucoup beaucoup beaucoup (etc etc) plus cher qu'un appel local. Avec les serveurs 64 bits d'aujourd'hui, avec toute cette mémoire et les processeurs à chaud, et avec la gestion de la mémoire supérieure d'ASP.NET, pourquoi ne pas mettre votre logique métier et votre DAL sur la même machine physique que les fichiers ASPX? Pourquoi pas?

Si vous devez effectuer une mise à l'échelle, ajoutez d'autres serveurs. Simple.

Il y a de bonnes raisons, bien sûr, de distribuer. Les bonnes raisons les plus courantes concernent les domaines de propriété - selon plusieurs axes: la gestion de la sécurité, voire le budget et le contrôle. En d'autres termes, si l'équipe est responsable de l'exécution de la logique métier et qu'une équipe distincte est responsable de la création et de l'exécution de la couche Web, il peut être judicieux de distribuer ces deux éléments pour permettre l'indépendance de la gestion. La plupart des bonnes raisons de distribuer du code informatique, ont leurs origines dans les structures des organisations humaines utilisant ou développant le code.

technique raison pour laquelle une page Web ne doit pas s'exécuter sur le même processeur, partageant la même machine virtuelle CLR et le même segment de mémoire, que la couche d'accès à la base de données. Peu importe ce que vous faites avec la distribution, il serait imprudent d'architecturer votre système avec des interfaces moins formelles définissant les connexions entre les couches. Si vous conservez des interfaces formelles, vous ne devriez pas avoir de problème pour mesurer la performance et l'efficacité d'une approche distribuée par rapport à une approche co-localisée.

Answer 2

Avez-vous vraiment besoin d'un serveur d'application? A quel point parlez-vous exactement? Par exemple Stackoverflow.com a ~ 50k uniques par jour et n'a pas de serveur d'application donc je suppose que vous parlez beaucoup plus grand que cela? La plupart des goulots de bouteilles de performance se résument à des problèmes de bases de données, donc je me concentrerais là-dessus.

Answer 3

Je vous suggère de consulter les directives du groupe Patterns and Practices pour la performance, plus précisément Chapter 6 - Improving ASP.NET Performance de la ligne directrice. Je suis d'accord avec Cheeso que vous devriez envisager sérieusement de ne pas diviser physiquement votre couche d'application et votre couche d'interface si vous le pouvez.Le P & directive P a les notes suivantes:

Éviter processus inutiles Houblon

Bien que le houblon de procédé ne sont pas aussi cher que le houblon de la machine, vous devriez éviter processus de houblon, si possible. Les sauts de processus entraînent une charge supplémentaire, car ils nécessitent une communication interprocessus (IPC) et un marshaling. Par exemple, si votre solution utilise les services d'entreprise, utilisez les applications de bibliothèque dans la mesure du possible, sauf si vous devez placer votre application Enterprise Services sur un niveau intermédiaire distant.

Comprendre les implications de performance d'un niveau moyen à distance

Si possible, éviter la surcharge de communication interprocessus et intercomputer. À moins que vos exigences métier ne dictent l'utilisation d'un niveau intermédiaire distant, conservez votre logique de présentation, de gestion et d'accès aux données sur le serveur Web. Déployez vos assemblées d'entreprise et d'accès aux données dans le répertoire Bin de votre application. Toutefois, vous pouvez avoir besoin d'un niveau intermédiaire distant pour l'une des raisons suivantes:

• Vous souhaitez partager votre logique métier entre vos applications Web Internet et d'autres applications d'entreprise internes. Vos besoins de mise à l'échelle et de tolérance aux pannes imposent l'utilisation d'un cluster de niveau intermédiaire ou de serveurs à charge équilibrée.
• Votre stratégie de sécurité d'entreprise stipule que vous ne pouvez pas mettre de logique métier sur vos serveurs Web.

Si vous devez absolument diviser la logique de l'application jusqu'à toute façon, vous pouvez utiliser WCF comme mécanisme de transport. Je ne suis pas sûr de la façon dont il se compare à distance en ce qui concerne la performance. Cependant, il me semble me rappeler que c'est la ligne directrice que Microsoft pousse. Clemens Vasters (responsable technique du Microsoft .NET Service Bus) parle de WCF vs Remoting dans this answer sur les forums MSDN.

Answer 4

Il existe de bons points de performance et d'évolutivité dans ces articles de Omar Al Zabir.
10 ASP.NET Performance and Scalability Secrets
et
99.99% available ASP.NET and SQL Server SaaS Production Architecture
(vérifier aussi son livre Building a Web 2.0 Portal with ASP.NET 3.5)

Answer 5

Voici mes conseils

1) Déplacer tous vos fichiers statiques - images, css, js à un équilibreur de charge comme nginx . Cela réduira considérablement la charge sur le serveur IIS et il aura assez de ressources libres pour servir la requête principale.

2) Pensez à la mise en cache et évitez tout accès à la base de données.

3) Essayez d'implémenter les principes REST autant que possible.

4) Gardez l'état de la session à un strict minimum - évitez-le si possible.

Answer 6

Apprendre à écrire de manière asynchrone.
Explorez l'exécution CCR par exemple.

Chaque thread qui est bloqué en attente de réponses IO est un moins disponible à votre système.

Désactivez la 'journalisation idéalisée' et laissez la possibilité de la rallumer via la console d'administration. Mais l'exploitation forestière est souvent un goulot d'étranglement caché.

CACHE CACHE CACHE!

S'il était coûteux d'obtenir les données la première fois, ne payez pas pour le deuxième!

Évitez l'état de session d'ASP.net - Cela peut sérieusement gonfler et entraîner un ralentissement important de la réactivité de la page.

Modifier les en-têtes HTTP pour indiquer la mise en cache du navigateur court (5sec - 20sec) (dépend de la nature du contenu)

uTiliseRa GZIP pendant que vous y êtes!

ET UTILISEZ BEAUCOUP DE RAM