1

イメージ ファイル (単純な静的ファイル) を提供する HttpHandler を作成し、SQL Server テーブルにレコードを挿入する必要があります。(例: http://site/some.img、ここで some.img は HttpHandler です) リクエストごとに項目を追加できるメモリ内オブジェクト (Generic List オブジェクトなど) が必要です (いくつかの要素も考慮する必要があります)。 1 秒あたり数百または数千のリクエスト)、SqlBulkCopy を使用して、このメモリ内オブジェクトを SQL テーブルにアンロードできるはずです。

リスト --> DataTable --> SqlBulkCopy

Cache オブジェクトを使用することを考えました。Generic List オブジェクトを作成して HttpContext.Cache に保存し、毎回新しい項目を挿入します。HttpHandler が新しい項目を追加しようとすると、CacheItemRemovedCallback がすぐに起動するため、これは機能しません。Cache オブジェクトをインメモリ キューとして使用できません。

誰でも何か提案できますか？負荷がさらに大きくなった場合、将来的にスケーリングすることはできますか?

4

5 に答える 5

1

キューに何かを追加すると、CacheItemRemovedCalledbackが発生するのはなぜですか？それは私には意味がありません...それが発火したとしても、ここで何もする必要はありません。おそらく私はあなたの要件を誤解していますか？

私はまさにこの方法でCacheオブジェクトをうまく使用しました。それが設計されたものであり、かなりうまくスケーリングします。すべてのアプリページリクエストでアクセスされ、必要に応じて更新/クリアされるハッシュテーブルを保存しました。

オプション2...本当にキューが必要ですか？DBに直接書き込みたい場合にも、SQLServerはかなり適切に拡張できます。共有接続オブジェクトや接続プールを使用します。

于 2008-12-29T12:44:10.100 に答える
0

あなたの提案をアレックスとブライアンに感謝します。

ブライアン：2番目のリクエストでキャッシュ内のListオブジェクトを置き換えようとすると（現在、カウントは2になっているはずです）、現在のCacheオブジェクトを新しいものに置き換えているため、CacheItemRemovedCalledbackが発生します。当初、これも奇妙な振る舞いと思っていたので、もっと深く調べなければなりません。また、2番目の提案では、（Cached SqlConnectionオブジェクトを使用して）レコードを挿入し、ストレステストを実行したときにどのようなパフォーマンスが得られるかを確認します。I / O操作なので、素晴らしい数字が得られるとは思えません。

その間、私はあなたの提案で最適な解決策を探し続けます。

于 2008-12-29T19:56:44.127 に答える
0

ジェネリックリストを使用してリクエストを保存し、別のスレッドを使用してSqlBulkCopyを実行するのはどうですか？

このように、リクエストをリストに保存しても、応答が長時間ブロックされることはありません。バックグラウンドスレッドは、5分ごとに独自の時間にSQLを更新できます。

CacheItemRemovedCallbackで作業を実行することにより、キャッシュメカニズムに基づいてバックグラウンドスレッドを作成することもできます。

削除時間5分のオブジェクトを挿入し、処理作業の最後に再挿入するだけです。

于 2008-12-29T12:43:12.740 に答える
0

コールバック内に条件付き要件を作成して、削除/置換ではなく、有効期限が切れてヒットしたキャッシュ エントリで作業していることを確認できます (便利なので VB で)。

Private Shared Sub CacheRemovalCallbackFunction(ByVal cacheKey As String, ByVal cacheObject As Object, ByVal removalReason As Web.Caching.CacheItemRemovedReason)
    Select Case removalReason
        Case Web.Caching.CacheItemRemovedReason.Expired, Web.Caching.CacheItemRemovedReason.DependencyChanged, Web.Caching.CacheItemRemovedReason.Underused
        ' By leaving off Web.Caching.CacheItemRemovedReason.Removed, this will exclude items that are replaced or removed explicitly (Cache.Remove) '
    End Select
End Sub

編集ここでは、必要に応じて C# を使用しています。

private static void CacheRemovalCallbackFunction(string cacheKey, object cacheObject, System.Web.Caching.CacheItemRemovedReason removalReason)
{
    switch(removalReason)
    {
        case System.Web.Caching.CacheItemRemovedReason.DependencyChanged:
        case System.Web.Caching.CacheItemRemovedReason.Expired:
        case System.Web.Caching.CacheItemRemovedReason.Underused:
            // This excludes the option System.Web.Caching.CacheItemRemovedReason.Removed, which is triggered when you overwrite a cache item or remove it explicitly (e.g., HttpRuntime.Cache.Remove(key))
            break;
    }
}
于 2008-12-30T15:01:37.577 に答える
0

私の以前のコメントを拡張するには...キャッシュについて誤って考えているというイメージが得られます。ハッシュテーブルなどのオブジェクトがキャッシュに格納されている場合、キャッシュの内容を明示的に変更しなくても、そのハッシュテーブルへの更新/格納は永続化されます。アプリケーションの起動時または最初のリクエスト時に、Hashtable をキャッシュに追加する必要があるのは 1 回だけです。

一括コピーとページ リクエストの更新が同時に発生することが心配な場合は、単純に 2 つのキャッシュ リストを用意することをお勧めします。1 つはページ リクエストが入ってくると更新されるリストで、もう 1 つは一括コピー操作用のリストです。1 つの一括コピーが終了したら、リストを入れ替えて繰り返します。これは、ビデオ ゲームやビデオ アプリのビデオ RAM のダブル バッファリングに似ています。

于 2009-01-12T06:12:05.013 に答える