問題タブ [persistent-connection]

Symfony フレームワークでロングポーリングの概念を使用する API を実装しようとしています。

成長することしかできないテーブル「フィード」があるとしましょう（ユーザーが他のインターフェースからフィードを挿入できると仮定します）。クライアント側のリアルタイム更新ページを作成したいと考えています。アイデアは次のとおりです。

1. クライアントは、最終変更のタイムスタンプを含む ajax リクエストを送信します (初回は 0 を送信します)。
2. サーバーは、クライアントのタイムスタンプをタイムスタンプと比較して、ユーザーが送信したものよりも大きなタイムスタンプを持つすべてのメッセージを取得します
3. 新しいメッセージがある場合は、最新のメッセージのタイムスタンプとともに、すぐにクライアントに返します。一方、新しいメッセージがない場合は、2 分間のビジー待機ループに入り、1 ～ 3 秒ごとに (ランダムに) チェックします。新しいメッセージがあるかどうか。
4. クライアントがサーバーの応答を受信すると、ブラウザはビューを更新し、すぐに新しい ajax リクエストを送信します。

つまり、x 秒ごとに AJAX 呼び出しを送信する代わりに、サーバーは新しい情報が得られるまでリクエストを保持します。

Symfony の経験が豊富なため、この API の簡単なデモを実装しようとしましたが、うまく機能します。セッションブロッキングの問題があったため (ajax 呼び出しが保留されているため、サーバーにアクセスできません)、単純にアクションに以下を追加しました。

（このリンクも参照してください）

次に、API への大規模なアクセスをテストします。100 人のユーザーは正常に動作し、1000 人のユーザーはすべてクラッシュします。次の 2 つの問題があることに気付きました。

1. アクセスごとに新しいDB接続が開かれます
2. アクセスごとに、サーバーは新しいプロセスを実行します

persistent: true最初の問題については、database.yml Doctrine コネクタに入れようとしました。サーバー接続を監視したところ、API へのアクセスごとに新しい接続が開かれることがわかりました。基本的に、私はまだ同じ2つの問題でブロックされています。

誰かがこの問題について何か考えや経験を持っていますか?? それとも、API を Symfony で実装するという考えをあきらめるべきでしょうか??

HTTP/1.1 (永続的な接続) で、クライアントに次の HTTP リクエストを送信するように促す「シグナル」は何ですか? Content-Length 以外に何かありますか?

ファイル間で TCP トラフィックをブリッジする単純なゲートウェイを構築しようとしています。私は2つのアプリを持っています:

• 「サーバー」はソケットを開き、接続を待ちます。接続が確立されると、取得したすべてを出力ファイルに転送すると同時に、入力ファイルからすべてをソケットに転送します。
• 「クライアント」は、上記の出力ファイルの内容を待ち、サーバーに接続してデータを送信し、受信したデータを上記の入力ファイルに書き戻します。

つまり、ソケットを介して取得したものはすべて、ファイルを介して別のソケットにリダイレクトされ、その逆も同様です。

私の知る限り、これは完全に透過的であるはずですが、永続的な接続は期待どおりに機能しません。

私は Firefox でテストしています - 何が起こるかというと、FF は 2 つの GET を送信し、2 つの応答を受け取ります。しかし、それはただそこに座って、まだすべてのデータを受信して​​いないかのように待機します... 5 秒後 (サーバーは "Keep-Alive: timeout=5" で応答するため、これに適合します)、一方の側が接続を閉じて、それを再確立し、再びスタックしたときにいくつかのファイルの送信を続けます。

WireShark で聞いてみましたが、異常は見つかりませんでした。何が起こっているのですか？

更新: 以下は WireShark ログのスクリーンショットです。TCP 接続が閉じられた後、HTTP 接続が送信されるのが遅すぎることを示しています (時間に注意してください)。私のログから判断すると、すぐに送信されました。この不一致の理由は何か分かりますか? どういうわけかソケットを「フラッシュ」する必要がありますか? 私はPythonを使用しています。

こんにちは、

7 つの IN パラメーターと 3 つの OUT パラメーターを持つストアド プロシージャがあります。PHP から 7 つのパラメーターを IN に渡し、プロシージャを使用してクエリを実行し、3 つの OUT パラメーターを取得する必要があります。

永続接続モードを有効にして mysqli を使用しています。(負荷に関する考慮事項) クエリを実行して結果を取得する最も効率的な方法は何ですか?

同時に実行されている他の PHP スクリプトに影響を与えず、結果自体をきれいにするものが必要です。それは簡単です。

これが私のアプリケーションです（簡略化）（実際の例ではなく、私が望んでいた方法です）

誰かがこのコードが実際にどのように見えるかを示すことができれば、お願いします!

私は明らかに適切な接続でmysqliを使用していますが、インターネットで見つけた例は本当に混乱していて効率が悪いようです.「nextResult」などのように動作するため、他のクライアントと競合しないか心配です.いくつかの奇妙な機能。

どうもありがとう！

PHP 5.3、MySQL 5.5

Apple CFNetwork フレームワークを介して永続的な HTTP 接続を使用して、サーバーのオーバーヘッドを削減しようとしています。ただし、それに関するドキュメントはほとんどありません。私が見つけた唯一の情報は、適切なフラグが設定されている限り、フレームワークが開発者に代わってストリームをリサイクルすることを示唆しています。

上記のコードにより、「CFNetwork 内部エラー」が発生します。CFReadStreamSetProperty(ReadStream, kCFStreamPropertyHTTPAttemptPersistentConnection, kCFBooleanTrue) 呼び出しを削除すると、エラーが発生しなくなりました。また、データの読み取りが完了したら readstream を閉じますが、ストリーム プールを自分で管理する必要があるのではないでしょうか?

誰かが私に紹介できるドキュメント、例、またはチュートリアルを持っていますか? Obj-C の使用を最小限に抑える必要があると主張するクライアントがいるので、CFNetwork を使い続けたいと思っています。

pg_pconnect 接続を使用して php から postgres に接続する場合、pg_close を実行します:

1. 本当に接続を閉じる (永続的な効果を台無しにする) ?
2. 接続を pconnect プールに渡しますか?

ここに osCommerce 2.2-MS2 があります。以前はうまく機能していたいくつかの設定がありました。データベースへの接続の設定 (ユーザー名、パスワード、データベースなど) を変更しましたが、変更が保存されていないことに気付きませんでした。ここで、変更が成功したかどうかを確認したいと思います。use persistent connectiontrueに設定されている設定があることがわかりました。だから彼は古い設定をどこかに保存していると思います。接続を再起動して、新しい設定に問題がないかどうかをテストするにはどうすればよいですか?

私はアプリケーション (MySQL/PHP) を構築します。このアプリケーション (MySQL/PHP) は、(やがて) 離れた (そしておそらく遅い) MySQL サーバーへの接続を使用する可能性があります。アプリは、DB 接続を頻繁に開く AJAX ウィスパーを使用します。私はクライアント側の最適化をいくつか行いましたが、永続的な接続を使用する勇気がありませんでした。これは良い考えかもしれません。

サーバーの制限を超えてサーバーを再起動する必要があるアイドル状態の mysql 接続が心配です。だから私mysql.connection_timeoutは15秒まで使用する予定ですが、制限後にすべてのアイドル状態の永続的な接続を強制終了しますか? それとも、サーバー プロセスが終了するまでシステム リソースをブロックしますか?

私はささやきでトランザクションを使用しませんし、接続が閉じられた後にすべてのロックを解放する必要がありますよね?

他に注意すべき継続的な接続の問題はありますか? （私はすでにドキュメントを読みました。）

私は基本的な RESTful サービスを作成しており、このタスクには ASP.NET MVC 3 を使用することにしました。私のアプリケーションは、ユーザーごとにサーバーへの永続的な接続を維持する責任があります (今のところ)。静的/共有状態 (永続的な接続など) を登録する場所であると想定していましたがApplication_Start、Unity.MVC3 のドキュメントを読んだ後、各要求/応答サイクルが (Application_Start を呼び出して) サービスの作成をトリガーするようです。

私が参照するドキュメントには次のように書かれています：

リクエストごとに、1 つの UpperCaseService、1 つの LowerCaseService、および 1 つの ExampleContext が、Unity を介して DependencyResolver によってインスタンス化されます。リクエストの最後に、ExampleContext は自動的に破棄されます

他のドキュメントを読んだ後、および私がすでに想定していたことから、Application_Start は、生成された AppDomain ごとに呼び出されます (これは、サーバー上にあるコアの数に近いと想定されます)。

では、サーバーへの一連の永続的な接続を維持し、要求/応答フェーズを生き延び、可能であれば、IIS サーバーが作成したすべての AppDomain 間で共有する効果的な方法は何でしょうか?

この Web サービスは、別の Web サイトによってのみ使用されることに言及しておくと役立つかもしれません。これは本質的には認証プロキシ サーバーですが、将来的にはさらに多くのことを行う予定です。したがって、将来のリクエストが必要になり、再認証はオプションではないため、レスポンスをキャッシュすることはできません。