私は（携帯電話から）特定のタスクを実行するために呼び出すことができるPHP webserviceを持っています。これらのタスクを実行するには、発信者が「ログイン」している必要があります。認証を処理する最善の方法は何ですか？Webサービスのログインを実装する最良の方法は何ですか？
現在、私はセッションを使用しています。クライアントはログインAPIを呼び出し、その他のAPIは必要です。しかし、私は20万人がこのサービスを全部呼び、そのすべてのセッションを持っていることの影響について懸念しています。サーバーがどのように応答するかはわかりません。任意のヒント？これは通常どのように処理されますか？ facebook、flickrなどのように。
ブラウザではなくカスタムクライアントプログラム（つまり携帯電話）によって呼び出されているのはなぜですか？むしろ、HTTP認証（SSLに行く場合はDIGESTまたはBASIC、または独自のスキーム）を使用し、毎回「ログイン」します。
次に、セッション、ロードバランシング、フェイルオーバーなどについて心配する必要はありません。ステートレスにしておいてください。
補遺：
は確かに、DBへの少数のヒットが優れている、それだけの一般的なルールです。しかし同時に、DBへの多くのヒットは、DBサーバー上のキャッシュされたページ、または場合によってはDBサーバーに到達しないようにアプリケーションキャッシュによって処理されます。そのため、インデックス付きカラムに対する単一行クエリの場合、DBヒットは非常に安価になることがあります。
ここでは、両方が格納されていて簡単にアクセスできるかどうか、実際にはデータベースのキャッシュビットと一意のユーザーセッションの違いが考えられます。
さて、主に違いはデータとの契約にあります。キャッシュされたアイテムの寿命は、使用しているメモリー量とキャッシュされていないアクティビティーの量に比例します。それには少量のメモリを与え、キャッシュされたアイテムは非常に短い寿命を持つ可能性があります。それには多くの記憶を与え、キャッシュされたアイテムははるかに良いチャンスがあります。キャッシュされたデータのメモリー量が十分に大きい場合、そのデータの繰り返しアクティビティーが引き続きキャッシュを使用する場合、キャッシュは大きな勝利です。キャッシュがすばやくリサイクルされている場合、キャッシュ内に何も存在しないため、キャッシュはほとんど価値がありません。しかし、ポイントは、システムがキャッシュの有無にかかわらず動作することです、キャッシュは単なる性能向上です。
セッションは、契約が異なります。多くのセッションでは、特定の最小寿命があります（通常は10分、20分、さらに30分です）。
つまり、ユーザーがサイトに1回だけヒットした場合は、返信がなくてもそのユーザーにリソースを割り当てる必要があります。そうしなければ、セッションは効果的に価値を提供しません。
トラフィックが多い場合は、管理する新しいセッションがたくさんあります。理論的には、悪い状況下では、セッションは制限なくスパイクする可能性があります。突然あなたのサイトで10,000ヒットを取得した場合、セッションの最小限の寿命のためにそれらのヒットの残りを管理することになります。リソース（メモリまたはディスク）を専用にする必要があります。そのリソースを追跡しなければならず、必然的にそれらをクリーンアップする必要があります。
キャッシュは固定リソースです。それはあなたがそれを構成するサイズに成長するだけです。キャッシュに何かを保持する義務はありません。前述のように、システムはキャッシュの有無にかかわらず機能します。キャッシュは自然にリサイクルします。あなたが10,000ヒットの急増を得るならば、彼らはあなたのキャッシュをロールする可能性がありますが、その後、彼らはあなたのシステムに印を残しません。彼らはヒットして1〜2分で消えて、再び見ることはできません。
最後に、セッションでは、ユーザーがマシン間を行き来する場合（何らかの理由で）、ユーザーと一緒に移動できるようにセッションを共有する必要があります。キャッシュはしません。理想的には、キャッシュを自分の仕事をすることができるように、ユーザーがリソースのセットにローカルにしたいが、システムは移動するかどうかにかかわらず動作します（キャッシュの再利用のために、セッションを複製しないと、セッションはまったく機能しません。
DBヒットは、値段は安いかもしれませんが、決して無料ではありません。しかし、セッションには独自のコストもあります。そのため、セッション内でどのように適用されるのかを考慮することが重要です。
私は歴史的にバックエンドのプログラマーではないので、私は質問の速度を考え出した。一回のログインは毎回1回の照会対ログインです。おそらくそれは無視できるでしょうか？ – user123321
非常に良いフォローアップの説明！ありがとうございました。 – user123321
現在、私はセッションを使用しています。 クライアントはログインAPIを呼び出し、 の他のAPIが必要です。しかし、私は 200000を持っているの影響について懸念しています すべての人々は、このサービスを呼び出す人々と これらのセッションをすべて持っています。
デフォルトのsession_save_handlerがfileに設定されているため、これらのセッションはディスクに接触します。システムがディスクに触れない方が良い（メモリははるかに高速です）。 session_set_save_handlerを無効にして、fileと異なるものを使用することができます。
これらのインメモリ・データベースはまた、より良いスケーリングをサポートしています。また、これらのデータベースを使用して残りのデータベースクエリ（MySQL？）をキャッシュする必要があります。ディスクに触れることはメモリを使用するのに比べて非常に遅いことを覚えておく必要があります。
最高のパフォーマンスを得るには、APCもインストールする必要があります。
これは通常どのように処理されますか？ （私はセッションを経由して認証を実装するのが容易であると思いますが）のようななど のFacebook、Flickrの、....
今ではOAuthを使用せずに任意のAPIを使用することはできません。これは、パスワードを共有することなく認証を行うための事実上の新しい標準です。 PHP（Rasmus）の作成者は、Writing an OAuth Provider Serviceを説明するチュートリアルを作成しました。 Googleでoauth phpを検索すると、十分な情報以上のものが得られるはずです。
また最近のFacebookのサイトのほとんどは、普通の古いPHPの代わりにHipHopを使ってウェブサイトを高速化しています。 PHPにはopen-sourcedがあります。多くのものがありますが、使用する必要があります：
うわー。どのような非常に良い説明。私はできるだけ多くを読むでしょう。残念ながら、私は十分な知識を持っていないので、今後どのような質問をしてもかまいません。ありがとうございました！ – user123321
問題はありません）。うまくいけば私は助けることができる.. – Alfred
PHPとそのセッションは、思うよりも強力です。まだサーバーに負荷がかかっている場合（あまり遅くないようにしてください）、PHPの 'session.save_handler'ディレクティブを変更して（ファイルシステムの代わりに）セッションを保存するデータベースを使用することを検討してください。それとは別に、独自の認証ライブラリを使用する代わりに、常に安全な認証ライブラリを使用してください。例：https：// github。com/delight-im/PHP-Authは、フレームワークにとらわれず、データベースに依存しません。 – caw