Frage

Ich entwickle einen Webdienst, dessen Methoden aus einem "dynamischen Banner" aufgerufen werden, das eine Art Warteschlange von Nachrichten zeigt, die aus einer SQL -Servertabelle gelesen werden.

Das Banner wird auf den Heimseiten hochverkehrsberechtigter Standorte stark unter Druck gesetzt. Jedes Mal, wenn das Banner geladen wird, ruft es meinen Webdienst an, um die neue Warteschlange von Nachrichten zu erhalten.

Jetzt: Ich möchte nicht, dass all diese Datenverkehrsabfragen jedes Mal, wenn das Banner geladen wird, Abfragen in die Datenbank beantragt. Daher denke ich, den ASP.NET -Cache (dh httpruntime.cache [cachekey]) zu verwenden, um Datenbankzugriffe zu begrenzen. Ich werde versuchen, jede Minute oder so einen Cache zu aktualisieren.

Offensichtlich werde ich versuchen, die Nachrichten so wenig wie möglich zu haben, um den Verkehr zu begrenzen.

Aber vielleicht gibt es andere Möglichkeiten, mit einem solchen Szenario umzugehen. Zum Beispiel könnte ich die letzte Version der Warteschlange im Dateisystem schreiben und den Webdienst auf diese Datei zugreifen. oder etwas, das die beiden Ansätze mischt ...

Die Lösung ist C# Web Service, ASP.NET 3.5, SQL Server 2000.

Irgendwelche Hinweis? Andere Ansätze?

Vielen Dank

Andrea

War es hilfreich?

Lösung

Es hängt von vielen Dingen ab:

  • Wenn sich die Daten nur wenig ändern (denken Sie an die Schaltfläche "veröffentlichen" oder tägliche Stapel), dann würde ich definitiv statische Dateien verwenden (aktualisiert über Push aus dem Backend). Wir haben diese Lösung auf ein paar großen Websites verwendet und sehr gut gearbeitet.
  • Wenn die Daten klein genug sind, ist das Speichervorsprung (dh HTTP -Cache) praktikabel, achten Sie jedoch vor dem Sperren von Problemen und achten Sie auch darauf, dass HTTP -Cache vorhanden ist wird nicht Arbeiten Sie so gut unter starker Speicherlast, da Elemente frühzeitig abgelaufen werden können, wenn das Framework Speicher benötigt. Ich wurde schon einmal davon gebissen! Mit den oben genannten Vorbehalten funktioniert HTTP -Cache recht gut.

Andere Tipps

Ich denke, Caching ist ein vernünftiger Ansatz und Sie können es noch einen Schritt weiter gehen und ihm eine SQL -Abhängigkeit hinzufügen.

ASP.NET Caching: SQL -Cache -Abhängigkeit mit SQL Server 2000

Das Schreiben einer Datei ist eine bessere Lösung IMHO - sie serviert vom IIS -Kernel -Code mit dem riesigen ASP.NET -Overhead und Sie können die Datei später auf CDNs kopieren.

Die AFAIK -Abhängigkeitseinzahlung ist mit SQL Server 2000 nicht sehr effizient.

Eine Möglichkeit, die von Skliwz erwähnte Speicherbeschränkung zu umgehen, besteht darin, dass Sie ihn in seinem eigenen App -Pool isolieren können, wenn Sie diesen Dienst außerhalb der normalen Anwendung verwenden. Ich habe das gesehen, was auch vorhanden ist, was auch hilft.

Vielen Dank an alle, da die Daten wenig groß sind, aber die zugrunde liegenden Tabellen werden sich ändern. Ich denke, ich werde die HTTPCache -Art und Weise gehen keine direkte SQL -Abhängigkeit zu verwenden, wie von @bloodhound vorgeschlagen).

Ich werde einen Stresstest machen, bevor ich an die Öffentlichkeit gehe, denke ich.

Nochmals vielen Dank.

Natürlich könnten Sie (sollten) auch die Caching -Funktionen in der Sixpack -Bibliothek .

  • Vorwärts (normaler) Cache, basierend auf HTTPCache, das funktioniert, indem Sie Attribute in Ihre Klasse einstellen. Das einfachste zu verwenden, aber in einigen Fällen müssen Sie warten, bis der Inhalt tatsächlich aus der Datenbank abgerufen wird.
  • Vorab des Cache von Grund auf neu, was nach dem ersten Anruf den Cache hinter den Kulissen neu erfrischt und Sie garantiert Inhalte ohne Wartezeit in einigen Fällen haben.

Weitere Informationen zur Sixpack Library Homepage. Beachten Sie, dass der Code (insbesondere der Vorwärts -Cache) geladen wird.

Hier ist ein Beispiel für einfaches Caching:

    [Cached]
    public class MyTime : ContextBoundObject
    {
            [CachedMethod(1)]
            public DateTime Get()
            {
                    Console.WriteLine("Get invoked.");
                    return DateTime.Now;
            }
    }
Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top