Planification de la capacité du serveur Web: plus de cœurs que plus de mémoire

Question

Nous avons un projet ASP.NET (40 formulaires Web, 50 tableaux, de très jolis objets IO standard avec le souci de minimiser autant que possible) qui vont bientôt devoir être déployés. Il y aura environ 100 utilisateurs simultanés sur le système, mais seulement environ 20 à la fois le battent. Nous allons le déployer sur Windows Server 2008, 32 bits initialement. En considérant la spécification de serveur de production, qu'est-ce qui devrait nous préoccuper davantage, obtenir plus de cœurs et moins de mémoire (4 cœurs et 4mb, par exemple) ou plus de mémoire et moins de cœurs (2 cœurs et 8mb)?

Accroître l'aide de Windows Server 64 bits avec l'utilisation de la mémoire?

Answer 1

Windows Server 32 bits ne peut traiter que 3 Go de mémoire. Obtenez 64 bits, 2 cœurs et 4 Go. Ou si l'argent n'est pas un problème, obtenez 8 cœurs et 24 Go. Le point est de ne jamais deviner. Si vous devinez que vous aurez tort. Surveiller la pression de la mémoire et la charge du processeur, et acheter plus/mise à niveau si nécessaire. Il est impossible, et stupide, d'essayer de deviner quel sera le goulot d'étranglement de la performance. Le seulement est de mesurer, mesurer, mesurer et répondre en fonction de cela.

Answer 2

Une information importante qui n'est pas incluse est la quantité de données que les bases de données vont contenir et combien chaque utilisateur utilisera. Cela déterminera la quantité de cache que vous voulez, et si elle va tous dans le cache ou si vous allez beaucoup plus sur le disque.

Utilisation? Seulement si vous photographiez pour> 3.5GB de RAM. Et avec 20 utilisateurs actifs simultanés, vous aurez besoin de tous les 4 cœurs et d'un cache important, car la dernière chose que vous voulez, c'est que les données des utilisateurs actifs soient effacées du cache pour charger d'autres données d'utilisateurs actifs, seulement pour frapper le disque pour obtenir les premières données des utilisateurs quand ils passent à l'action suivante, en envoyant une autre donnée des utilisateurs actifs du cache ... (lire: thrashing).