Conseils pour un service Web à fort trafic, c # asp.net sql2000

Question

Je développe un service Web dont les méthodes seront appelées à partir d'une "bannière dynamique". qui affichera une sorte de file d'attente de messages lus à partir d'une table de serveur SQL.

La bannière sera fortement sollicitée dans les pages d'accueil des sites à fort trafic. chaque fois que la bannière sera chargée, elle appellera mon service Web pour obtenir la nouvelle file de messages.

Maintenant: je ne veux pas que tout ce trafic conduise des requêtes à la base de données chaque fois que la bannière est chargée, alors je pense utiliser le cache asp.net (c'est-à-dire HttpRuntime.Cache [cacheKey]) pour limiter la base de données. accès; Je vais essayer de mettre à jour le cache toutes les minutes environ.

Évidemment, je vais essayer d'avoir le moins de messages possible pour limiter le trafic.

Mais il existe peut-être d'autres moyens de faire face à un tel scénario. Par exemple, je pourrais écrire la dernière version de la file d'attente sur le système de fichiers et laisser le service Web accéder à ce fichier. ou quelque chose qui mélange les deux approches ...

La solution est le service Web c #, asp.net 3.5, serveur SQL 2000.

Un indice? D'autres approches?

Merci

Andrea

Answer 1

Cela dépend de beaucoup de choses:

• S'il y a peu de changement dans les données (pensez au backend avec le bouton "Publier" ou les lots quotidiens), j'utiliserais certainement des fichiers statiques (mis à jour via push à partir du backend). Nous avons utilisé cette solution sur quelques grands sites et avons très bien fonctionné.
• Si les données sont suffisamment petites, la mise en cache de la mémoire (c'est-à-dire le cache HTTP) est viable, mais méfiez-vous des problèmes de verrouillage et veillez également à ce que le cache HTTP ne fonctionne pas aussi bien avec une charge de mémoire importante, car les éléments peut expirer tôt si le framework a besoin de mémoire. J'ai été mordu par ça avant! Avec les mises en garde ci-dessus, le cache HTTP fonctionne assez bien.

Answer 2

Je pense que la mise en cache est une approche raisonnable. Vous pouvez aller plus loin et y ajouter une dépendance SQL.

Si vous suivez la route des fichiers, gardez cela à l'esprit.

http://petesbloggerama.blogspot.com /2008/02/aspnet-writing-files-vs-application.html

Écrire un fichier est une meilleure solution, à mon humble avis - son service est assuré par le code du noyau IIS, sans l’énorme surcharge asp.net, et vous pouvez copier le fichier sur un CDN ultérieurement.

L’encaissement de dépendance AFAIK n’est pas très efficace avec SQL Server 2000.

En outre, l'un des moyens de contourner la limitation de mémoire mentionnée par Skliwz est que si vous utilisez ce service en dehors de l'application normale, vous pouvez l'isoler dans son propre pool d'applications. J'ai déjà vu cela auparavant, ce qui aide également.

Merci à tous, car les données sont de petite taille, mais les tables sous-jacentes vont changer, je pense que je vais utiliser la méthode HttpCache: il me faut en fait un moyen de réduire l’accès à la base de données, même si les données changent (donc c’est la raison pour laquelle vous n’utilisez pas de dépendance directe à Sql, comme le suggère @Bloodhound).

Je pense que je vais faire un test de résistance avant de me rendre publique.

Merci encore à tous.

Bien sûr, vous pouvez (devriez) également utiliser les fonctionnalités de mise en cache de la bibliothèque SixPack .

• Cache (normal), basé sur HttpCache, qui fonctionne en attribuant des attributs à votre classe. Le plus simple à utiliser, mais dans certains cas, vous devez attendre que le contenu soit réellement extrait de la base de données.
• Cache préalable, à partir de zéro, qui, après le premier appel, actualisera le cache en arrière-plan et vous garantira un contenu sans attente dans certains cas.

Plus d'informations sur la page d'accueil de la bibliothèque SixPack . Notez que le code (en particulier le cache avant) est testé en charge.

Voici un exemple de mise en cache simple:

    [Cached]
    public class MyTime : ContextBoundObject
    {
            [CachedMethod(1)]
            public DateTime Get()
            {
                    Console.WriteLine("Get invoked.");
                    return DateTime.Now;
            }
    }

Answer 3

Answer 4

Answer 5

Answer 6

Si vous suivez la route des fichiers, gardez cela à l'esprit.

Answer 7

Answer 8

Écrire un fichier est une meilleure solution, à mon humble avis - son service est assuré par le code du noyau IIS, sans l’énorme surcharge asp.net, et vous pouvez copier le fichier sur un CDN ultérieurement.

L’encaissement de dépendance AFAIK n’est pas très efficace avec SQL Server 2000.

Answer 9

En outre, l'un des moyens de contourner la limitation de mémoire mentionnée par Skliwz est que si vous utilisez ce service en dehors de l'application normale, vous pouvez l'isoler dans son propre pool d'applications. J'ai déjà vu cela auparavant, ce qui aide également.

Answer 10

Merci à tous, car les données sont de petite taille, mais les tables sous-jacentes vont changer, je pense que je vais utiliser la méthode HttpCache: il me faut en fait un moyen de réduire l’accès à la base de données, même si les données changent (donc c’est la raison pour laquelle vous n’utilisez pas de dépendance directe à Sql, comme le suggère @Bloodhound).

Je pense que je vais faire un test de résistance avant de me rendre publique.

Merci encore à tous.

Answer 11

Bien sûr, vous pouvez (devriez) également utiliser les fonctionnalités de mise en cache de la bibliothèque SixPack .

• Cache (normal), basé sur HttpCache, qui fonctionne en attribuant des attributs à votre classe. Le plus simple à utiliser, mais dans certains cas, vous devez attendre que le contenu soit réellement extrait de la base de données.
• Cache préalable, à partir de zéro, qui, après le premier appel, actualisera le cache en arrière-plan et vous garantira un contenu sans attente dans certains cas.

Plus d'informations sur la page d'accueil de la bibliothèque SixPack . Notez que le code (en particulier le cache avant) est testé en charge.

Voici un exemple de mise en cache simple:

    [Cached]
    public class MyTime : ContextBoundObject
    {
            [CachedMethod(1)]
            public DateTime Get()
            {
                    Console.WriteLine("Get invoked.");
                    return DateTime.Now;
            }
    }