2012-01-05 14 views
4

セッション中に大きな配列を格納する必要があります(現在は数kBまで、最大0.25MBに制限しています)。

あなたの意見や練習では、$ _SESSIONまたはデータベースに保存する方が良いでしょうか?

プロセッサ/メモリの使用状況は共有ホスト上にあるため、スピードは重要ですが、リソースを過度に使用してサイトを閉鎖しないようにしたいと考えています。

$ _SESSIONを使用してもうまく動作するという確かなサイズの範囲はありますか? (例:0kb〜100kB、またはあなたの練習/テストが示したもの)。

ありがとうございました。

+1

私はDBを使用することは間違いなく遅くなると仮定します。 250 kbはあまりデータではありません – knittl

答えて

4

セッション数が0.25MBの場合、セッションに保存されるリソースは、DBよりも少なくなります。したがって、セッションオーバーヘッドの可能性は低いです。

2

これは、サイトとサーバーの同時ユーザー数に大きく依存します。それは共有サーバーなので、非常に大きな数のユーザーがいる場合にのみデータベースを使用しますが、$ _SESSIONでより簡単で速く、200kbsではそれほど多くはありません。また、DBを使用しないと、各リクエスト時にDBサーバーとWebサーバーを前後に移動する必要がないため、データの取得に多くの時間を節約できます。

1

セッションは、通常、デフォルトのセッションハンドラを使用するときに、ファイルシステムのセッションファイルに格納された後にメモリにロードされます。セッションを保存するために明示的にメモリを使用している場合を除き、セッションに永続的なメモリの問題はありません。私の意見では、とにかく大規模なセッションを持つことは悪いです。デザインには根本的な欠陥がいくつか存在します。データをユーザーに関連付けるには、通常、データが外部キーを介して正しいユーザーに関連付けられるようにデータベースを設計します。大量のデータをメモリにロードしてフィルタリングするのではなく、このデータの小さなサブセットをクエリできます。セッションは、ユーザー認証に本当に役立ちます。 RESTful APIはセッションをまったく使用しません。私はおそらく、私はステートレスWebに偏っていることに気付くべきです。セッションは要求間で状態を保持します。ブラウザは多目的で安全な代替手段を提供しないため、有効なユースケースとしてのみ認証を受け入れました。

+0

私はデザイン発言の欠陥について非常に興味があります。私がやっていることは、ユーザーが何千もの要素をチェックして処理できるようにすることです。そのため、これらの要素は自然に複数のページに記載されています。ページを移動する際にユーザーがチェックした要素を覚えておく必要があります。あなたはこのアプローチに欠陥があると思いますか?もしそうなら、あなたはそれをどうしますか?返信は大変感謝しています。 – CodeVirtuoso

+1

私はすべてのビューがアドレス可能であることを確実にすることを目指す傾向があります。選択などのデータを保存する必要がある場合は、そのデータをクライアント側(非表示入力、Json、またはアドレスの一部)に保存し、各要求とともにそのデータを返送します。大量のデータがあり、JavaScriptが存在するとは限りません。ユーザーバインディングフィールドとセッションバインドフィールドを含むテーブルを作成し、そのIDでオブジェクトにアドレスすることをお勧めします。複数のページを持っていても、各ページにデータを置く必要はありません。 –

+0

平均的な使用状況では、ユーザーは前のページを再訪しません。だから本質的にあなたがやっていることは、あなたのデータベースに部分的なデータを保存し、そのデータが完成すればデータベースを操作して(それを移動する必要があっても)です。しかし、データをリロードする必要はありません。データベースは、データを照会してアプリケーションに戻すことなく、データベースを操作できます。私が提案したセッション識別子は、単に一定期間後にユーザーが再利用しなかった放棄されたセッションをクリーンアップできるようにするためのものです。 –

2

セッションでの実際のパフォーマンス上のペナルティは、リクエストごとにセッションデータを書き換えます。ディスクへの書き込み(これはほとんどの場合に行われます)は非常に遅いです。これは、認証や小さなデータ構造などの単純なものに対してのみ使用する必要があります。ショッピングカートなどが含まれる。

サーバー上でどのような種類のデータとソフトウェアを使用できるかによって、データベースに格納するか、MongoDB、Redis、CouchDBなどのNoSQLソリューションを使用する必要があります。

最初にセッションを使用することを検討しているため、データの整合性が第1位の優先順位ではないため、これを使用します。データが重要な場合は、MySQLデータベースを使用する必要があります。これはACIDの原則に従い、クライアントが現在のセッションとの関連付けを解除した後もデータを保持します。

整合性が重要でない場合は、Memcachedが利用可能であれば使用することを検討してください。

要約:データベースを使用しますが、必ずしもMySQLである必要はありません(どのデータであるかによって異なります)。

関連する問題