0

HTTP セッション Cookie に関連付けられたデータを保存および読み取る最速の方法を探しています。

現在、ファイルでいっぱいのディレクトリがあり、ファイル名はセッション cookie (ランダムな ~150 文字) で、内容はバイナリ blob で、通常は数バイト、場合によっては 1 ～ 2 キロバイトです。また、atime (最終読み取りタイムスタンプ) を使用して、古いセッション データを見つけて削除します。

ディレクトリ内のこのファイル数は数百万に急増する可能性があり、サーバーはファイルが存在するかどうか、現在の時刻を常にチェックし、読み取り/書き込み、そしてもちろんファイルの削除/作成を行っています。ext3 は、この使用パターンに対する理想的なアプローチではないと思いますか?

この種のデータを保存する最良の方法は何ですか? MySQL をテストしましたが、ext3 よりも桁違いに遅いです (何も間違っていないと思いますか?)。接続を確立するだけでも、一般的なファイルシステムの存在/時間/fread サイクルを実行するよりも時間がかかります。

経験のある方は大歓迎です。関連性のない小さなデータからなる巨大なデータベースを管理する最速の方法は何ですか?

ハイエンドサーバーハードウェアでCentOSを使用してPHPを使用しています（ほぼ最高のお金で購入できます）。クラスタリングやロード バランシングは必要ありません。中～低トラフィックの Web サイトでリクエストごとのレイテンシを削減しようとしています。私たちの状況では動作しないため、PHP の組み込みセッション API は使用していません。

4

2 に答える 2

2

PHP が一流で最適化されていると仮定して、ファイル システムを ext4 に変更してみます (または、セッション データ用に ext4 マウントを作成します)。ext3 は比較すると非常に遅いため、ボトルネックになる可能性があります。

ext4 をサポートできない場合は、ext2 もオプションになります (ただし、ext4 は既にリリースされているので問題ありません)。ただし、ext2 を使用する場合は、信頼性が低く、ジャーナリングがないため、セッション データ専用の別のマウントがあることを確認してください。

ext4 は ext2 よりも読み取りで優れたパフォーマンスを発揮しますが、ext2 は ext4 の書き込みで優れたパフォーマンスを発揮します (ほとんどの場合、「いくらかの」オーバーヘッドを作成するジャーナリングがないためですが、それは私の理由です。間違っている可能性があります)。

編集：小さなディレクトリは1つの大きなディレクトリよりも優れていることに言及する価値があるかもしれないとも思いました。ただし、カスタム コンパイル済みカーネルを使用して、ext3 のデフォルトとしてディレクトリあたりの 32000 ファイルの制限を増やしている場合を除き、とにかくこれを行っている可能性があります。ただし、i ノード (ディレクトリ内のすべてのファイルのインデックス) を小さくしておくと、パフォーマンスが向上します。最初の x 文字数に基づいてファイルをディレクトリにソートするのと同じくらい簡単なことで、セッション ファイルを選択する前に正しいディレクトリを見つけるという処理オーバーヘッドを追加することなく、これを実現できます。

于 2012-09-07T14:41:21.067 に答える
2

インメモリデータベースを見たことがありますか？操作ごとにディスクに触れる必要がないため高速であり、永続化するために時々ディスクにデータを書き込むオプションがあるものもあります。

データが単純な場合、キーと値のストアはより軽量であるため、さらに高速である必要があります。たとえば、Redisや、ディスクに永続化するオプションを備えたキャッシュ ソリューションなどです (PHP についてはわかりませんが、 Java のEHcacheなどの例があります)。 ）。

于 2012-09-07T16:46:56.777 に答える