RAM disponible sur le fournisseur d'hébergement partagé

Question

Je suis en train de créer une application métier qui va contenir entre 50 000 et 150 000 entreprises. Chaque entreprise (ligne db) est représentée avec 4-5 propriétés/colonnes (titre, emplacement, ...). ORM est LINQ2SQL.

Je dois faire un peu de calcul, et pour cela j'ai beaucoup de requêtes pour une société spécifique. Maintenant, je vais à DB chaque fois que j'ai besoin de quelque chose, et il produit 50-200 requêtes, en fonction du calcul complexe. J'ai essayé de mettre toutes les entreprises en cache, et pour 10 000 lignes (entreprises) en db, cela prend environ 5,5 Mo de cache. Dans ce scénario, j'ai une seule requête.

Cette application sera sur le serveur d'hébergement partagé, donc mes ressources sont limitées. Je suis intéressé, que se passera-t-il si j'essaie de charger, disons 100 000 entreprises (lignes, objets)? Ou mettre cela dans la cache?
Existe-t-il une limite de RAM que la société d'hébergement moyenne attribue à l'application ASP.NET? Cela dépend-il du pool d'applications dédié (je peux mettre une application dans un pool dédié)?

Les options sont:
- table entière de charge à des objets C#. Id a fait du profilage de la mémoire, 10 000 objets ont besoin de 5 Mo de RAM
- interroger db pour obtenir des objets référencés en cas de besoin.

La tâche est: pour la société A donnée, construisez l'arborescence des entreprises connectées.

Table et colonnes:
Société: IdCompany, Titre, Adresse, Contact
CompanyConnection: IdParentCompany, IdChildCompany

Answer 1

Votre hébergement mutualisé sera probablement IIS 7 sur Windows Server en cours d'exécution en tant que machine virtuelle. Cette machine se comporte comme n'importe quelle machine ordinaire - elle n'est pas "consciente" d'être partagée ou virtualisée.

Vous devriez vous attendre à ce que Windows commence à paginer sur le disque lorsqu'il est en dehors de la RAM physique et que les erreurs de mémoire insuffisante ne soient levées que lorsque le fichier de page a rempli le disque. Bien sûr, vous ne voulez jamais mettre en page une partie du cache chaud sur le disque. Windows lui-même peut commencer à vous harceler au sujet de la mémoire insuffisante, mais ce n'est pas le même «urgence» et les applications continueront à pouvoir demander de la RAM et continueront à être données (bien que desservies par le fichier de page).

Si votre application peut tomber en panne et laisser un état corrompu ou une transaction partielle, vous devez coder de manière défensive et vérifier que la mémoire est disponible avant d'entreprendre une action.

Créez le nombre attendu d'objets dans une boucle avec des données feintes et observez la consommation de mémoire dans la zone - l'ensemble de travail du processus de travail est celui à surveiller. Vous pouvez le faire dans le Gestionnaire des tâches.

Surveillez les défauts de page. Ce sont des événements lorsqu'une opération de mémoire doit être dirigée vers le disque. De même, de très grands ensembles d'objets peuvent provoquer de longs cycles de récupération de place> 1 seconde. Cela peut être un gros problème dans les applications sensibles au temps comme le commerce et les données du marché.

Espérons que ça aide.

Mise à jour: Je fais un thang de mise en cache similaire pour une application méga data-mining.

Chaque type ORM a une méthode GetObject qui utilise un cache géant ou va sur le disque puis met à jour le cache: Person.GetPerson (vérifier cache des gens, aller à db, ajouter aux gens cache)

Maintenant mes requêtes retourner seulement les clés uniques des résultats. Ensuite, chaque clé est récupérée en utilisant la méthode ci-dessus. Initialement lent jusqu'à ce que le cache soit créé mais ...

Le point étant que chaque résultat de la requête pointe vers la même instance en mémoire! Cela signifie que l'empreinte RAM est beaucoup plus petite en raison du partage.

Les résultats de la requête sont ensuite également mis en cache. Bien sûr. Lorsque les objets ne sont pas immuables, chaque écriture d'objet met à jour sa propre instance dans le cache géant mais provoque également l'annulation de tous les caches de requêtes qui concernent ce type d'objet!

Bien sûr, dans cette application, les écritures sont rares comme ses principales données de référence.