1

おそらくダミーの質問ですが、私にはわかりません。それは概念の質問です。私は、ユーザーが約500の同時接続で多くのものを保存するWebプラットフォームを持っています。パフォーマンス/セキュリティの観点から、最善のアプローチは何ですか:

  • データを取得する必要があるたびに(ユーザーが別のページに移動するたびに)ユーザーをDBに接続し、取得した後に接続を閉じますか?または
  • ログイン時にユーザーをDBに一度接続し、DBへのリンクを保持し($ _SESSIONのように)、ログアウト時に接続を切断しますか?または
  • ログイン時に、ユーザーテーブル、そのプロファイル1つ、および他のすべてのプロファイルからほとんどすべてを取得し、それらを$ _SESSIONに配置し、更新/挿入が必要な場合にのみDBに接続しますか?

接続自体には時間がかかるので、私は最良のアプローチを探しています。しかしその一方で、私はいつも「データベース接続をできるだけ早く閉じる」と聞いています。

ご協力いただきありがとうございます。

4

1 に答える 1

0

特定のユースケースとサーバーのセットアップに大きく依存していると思います。確実に知る唯一の方法は、さまざまなソリューションを試してコードをプロファイリングすることです。

通常、最初に選択したソリューションをプロファイリングすると、遅延の原因と、待機時間/処理時間の最大の原因についてのヒントが得られます。そうすれば、次の (そして改善された) 解決策をより適切に推測できるようになります。

一般に、遅延評価を行い、可能な限りキャッシュするのは良い方法です。Web アプリケーションの場合、Memcached や Redis などの非リレーショナル データベースは、事実上の標準のようなものです (少なくとも私の経験では)。

データベース接続を開いたままにしておく場合は、DB が処理するように設定されている数の同時クエリしか実行できないことに注意してください。できるだけ早く接続を閉じると、DB の同時実行性が低下します。接続の確立で多くの遅延が発生する場合は、関連するすべてのデータを時々取得してキャッシュすることを検討する必要があります。確実に知る唯一の方法は、アプリケーションをプロファイリングすることです。

アップデート:

お返事をありがとうございます。これをプロファイリングして、何が改善されるかを確認します。MemCached を見てみましょう。後で見たいと思っていたのですが、ちょうどいいタイミングだと思います。– fperr

私も最初は MemCached に気が進まなかったのですが、まったく複雑ではありません。これは (ハッシュ) マップ/辞書として機能し、通常は MemCached インスタンスにセッション データを保存し、セッション ID などでインデックスを付けるだけです。

あなたのプロジェクトで頑張ってください:)

于 2013-02-12T12:14:04.720 に答える