実際に保持できるアプリケーションセッションデータの量は?
-
02-07-2019 - |
質問
現在、1日20,000人以上のユーザーにヒットするアプリケーションがあり、ほとんどが1つのデータテーブルを参照しています。このデータテーブルには約20行が格納されていますが、「データテーブル」から取得されます。テーブル内に200,000〜600,000の情報レコードを持つdb内。 編集:これらの20行は「動的」です。ユーザーがテキストボックスから情報を入力した場合は変更します。
現在、プロファイルデータとともにユーザーデータも保持しています。
現在、データテーブルが表示されるたびに約4回のコールバックを行っていますが、1回のコールに戻すことはできません。
質問: 5秒ごとに200,000から600,000行のデータでアプリケーションの状態を実際に満たすことができるかどうか疑問に思っていましたが、実際にシステムを高速化しますか? 編集:ユーザーまたは他のユーザーが入力した動的な行に対して行う、コンテンツは頻繁に更新する必要があります。
質問2:アプリケーションのキャッシュを実際にどれだけ保持し、それでも高速で逃げることができますか?
編集: 20,000人以上のユーザーがこれらの200,000行にアクセスするため、それらすべてをキャッシュする必要があります。少なくとも、ベストプラクティスとしては考えます。ユーザーが私のサイトを訪れたとき、これは彼らが見るメインページの1つであり、おそらく訪問ごとに2〜5回戻ってきます。
編集:ユーザーには、他の20行とは異なる可能性がある 20行の一意のセットが表示されます。これは非常に動的なサイトであり、2、3の異なる行が1秒ごとに更新されます。
編集:セッション状態で保存されている場合、ユーザーがページを表示する回数のみが高速化されます。人がページを一度しか表示できずに去ることができるため、全体的なアプリケーションではありません。
解決
技術的には、あなたがやりたいことは可能だと思いますが、お勧めしません。この道を進む前に考慮しなければならないいくつかの要因があります。
-
それをサポートするハードウェアはありますか?そのような構成用のメモリがなく、ページスワップが必要な場合、メモリにキャッシュしておくことによる速度上のメリットのほとんどが失われる可能性があります。プロセス外の状態サーバーを使用している場合、システムにはシリアル化を処理するオーバーヘッドがあります。
-
そのように多くの行で何かを検索する予定はありますか?データベースサーバーは、多くの検索と並べ替えをバックグラウンドで処理します。 Webサーバーにデータをキャッシュすると失われる、かなり複雑なアルゴリズムが使用されています。
メモリ内ではなく、データベース内で何かが高速になった場合、実際に難しい高速ルールはありません。アプリケーションのセットアップ方法とデータの保存方法に大きく依存します。
他のヒント
彼らはほとんどが1つのテーブルを見て、そのテーブルは200から60万行から取り出されると言います。そのテーブルはどれくらいの頻度でプルされますか?これは「ホームページ」ですか?ユーザーがデータの最初のページを見ているタイプのシナリオ? 20万行すべてをキャッシュするのはなぜですか、最初の20行をキャッシュしないのはなぜですか?
それをセッション状態で保存してもよろしいですか?同じデータベースを使用する場合は、アプリケーションの状態を選択します。この方法では、1つのデータセットのみがメモリに保存されます。
メモリ制限はIISによって制御されていると思います。 最大仮想メモリと最大使用メモリの制限があります。 データの可用性を確認することを忘れないでください。
明確にすることができます-ユーザーは、そのユーザーに固有の20レコードのデータテーブルを取得し、600Kテーブルを照会した結果だと言っていますか?ユーザーのレコードは静的ですか?
ユーザーに関連付けられた静的なレコードが20個しかない場合、リクエストに応じてユーザーにストリーミングできるシリアル化されたオブジェクトを作成できますか?つまり、DBにアクセスする必要がないように、準備が整った状態にします。