Projeter requêtes de bases de données simultanées

Question

Je suis après quelques réflexions sur la façon dont les gens vont sur le calcul de la charge de base de données aux fins de la planification des capacités. Je ne l'ai pas mis cela sur le serveur de défaut parce que la question est liée à la mesure que l'application plutôt que de définir l'infrastructure. Dans ce cas, il est quelqu'un d'autre le travail à vous soucier de ce petit!

Je suis conscient qu'il ya un grand nombre de variables ici, mais je suis intéressé par la façon dont les autres vont à obtenir un sentiment d'ordre de grandeur. Ceci est tout simplement un exercice de calcul des coûts au début d'un cycle de vie du projet avant toute conception spécifique a été créé afin de ne pas beaucoup d'informations pour continuer à ce stade.

La question que j'ai mis en avant des gens d'infrastructure est « combien d'utilisateurs simultanés ». Débattons pas la raison d'être de la recherche que celui-ci figure; il est tout simplement ce qui a été demandé dans ce cas!

Ceci est une extrémité avant du web, back-end SQL Server avec une assez fixe, le public facilement quantifiable. Pour clouer cela à des demandes simultanées réelles d'une manière très approximative, la façon dont je le vois, il se résume à des unités de plus en plus granulaires de mesure:

1. public Total
2. sessions simultanées
3. demandes simultanées
4. simultanée des requêtes DB

Cela ne tient pas compte de facteurs tels que la mise en cache de l'application Web, les demandes de pages partielles, le volume d'enregistrement etc et il y a une licence créative nécessaire pour définir la fréquence des requêtes par utilisateur et nombre de hits DB et le temps d'exécution, mais il semble comme un raisonnable point de départ. Je suis aussi conscient de la nécessité d'échelle pour la charge de pointe, mais que quelque chose d'autre qui peut être branché dans les sessions simultanées si nécessaire.

Il est certes très basique et je suis sûr qu'il ya une orientation plus complète sur le marché. Si quelqu'un peut partager leur approche de cet exercice ou me diriger vers d'autres ressources qui pourraient rendre le processus un peu moins ad hoc, ce serait génial!

Answer 1

Je vais essayer, mais évidemment sans connaître les détails, il est assez difficile de donner un avis précis.

Tout d'abord, les gars d'infrastructure aurait pu poser cette question du point de vue des licences (serveur SQL peut être autorisé par utilisateur ou par CPU)

Revenons maintenant à votre question. « Audience totale » est importante si vous pouvez prédire / travail sur ce nombre. Cela peut vous donner le scénario du pire cas lorsque tous les utilisateurs ont frappé la base de données à la fois (par exemple 9 heures lorsque les journaux de tout le monde dans).

Si vous stockez des informations de session, vous auriez probablement au moins 2 connexions par utilisateur (1 séance + 1 DB principal). Mais ce nombre peut être (parfois sensiblement) réduite de mise en commun de connexion (dépend de la façon dont vous vous connectez à la base de données). Utilisez un scénario pire des cas -. Connexion 50 système + 2 * nombre d'utilisateurs

demandes / requêtes simultanées dépendent de la nature de l'application. Besoin de précisions. Les demandes plus simultanées (à votre extrémité avant) ne se traduira pas nécessairement plus de demandes sur la fin arrière.

Après avoir dit tout cela -. Aux fins d'établissement des coûts, vous devez vous concentrer sur une plus grande image

1. licence serveur SQL (si ma mémoire est bonne) vous coûtera ~ 128K AUD (double Xeon). Hot / veille au chaud? Doublez le coût.

2. Stockage disque - la quantité de stockage aurez-vous besoin? Les disques sont relativement pas cher, mais si vous allez utiliser SAN le coût peut devenir perceptible. De plus -. Les plus disques mieux du point de vue de la performance