Planification de la capacité des serveurs Web: plus de cœurs que de mémoire

Question

Nous avons un projet ASP.NET (une quarantaine de formulaires Web, une cinquantaine de tableaux, de jolies choses IO standard avec soin de minimiser autant que possible) qui devra bientôt être déployé. Il y aura environ 100 utilisateurs simultanés sur le système, mais seulement environ 20 à la fois le bousilleront. Nous allons le déployer sur Windows Server 2008, initialement 32 bits.

Lorsque nous examinons les spécifications du serveur de production, devons-nous nous inquiéter davantage en obtenant plus de cœurs et moins de mémoire (4 cœurs et 4 Mo par exemple) ou plus de mémoire et moins de cœurs (2 cœurs et 8 Mo)?

Souhaitez-vous utiliser l’aide Windows Server 64 bits pour l’utilisation de la mémoire?

Answer 1

Windows Server 32 bits ne peut s’adresser qu’à environ 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 but est de ne jamais deviner. Si vous pensez que vous aurez tort Surveillez la pression de la mémoire et la charge du processeur, puis achetez-en davantage / mettez à niveau si nécessaire Il est impossible, et idiot, d'essayer de deviner quel sera le goulot d'étranglement des performances. La seule méthode consiste à mesurer, mesurer, mesurer et répondre en fonction de cela.

Answer 2

Un élément d’information important qui n’est pas inclus est la quantité de données que les bases de données vont contenir et la quantité d’utilisation par chaque utilisateur. Cela déterminera la quantité de cache que vous allez vouloir, et si tout ira dans le cache ou si vous allez utiliser beaucoup plus de disques.

Utilisation? Seulement si vous tirez pour plus de 3,5 Go de RAM. Et avec 20 utilisateurs actifs simultanés, vous allez vouloir disposer des 4 cœurs et d'un cache volumineux, car la dernière chose que vous souhaitez est que les données d'un utilisateur actif soient vidées du cache pour charger d'autres données d'utilisateurs actifs. pour obtenir les premières données des utilisateurs lors de leur prochaine action, envoyer à un autre utilisateur actif les données du cache ... (lire: thrashing).