マイクロサービスは phprpc を使用しますが、最近、phprpc が依存する fsockopen に、同時実行性が高い場合に深刻なブロッキング問題があることが判明しました。それを解決する良い方法はありますか?

私は phprpc を使用していますが、最近、phprpc が依存している fsockopen が高い同時実行性の下で深刻なブロッキングの問題を抱えていることに気付きました。それを解決する良い方法はありますか?

• 多数の読み取り操作が各ユーザーに関連しており、リアルタイムのパフォーマンスを確保する必要があります。この問題を解決するにはどうすればよいですか?

。

返信内容:

私は phprpc を使用していますが、最近、phprpc が依存している fsockopen が高い同時実行性の下で深刻なブロッキングの問題を抱えていることに気付きました。それを解決する良い方法はありますか?

• 多数の読み取り操作が各ユーザーに関連しており、リアルタイムのパフォーマンスを確保する必要があります。この問題を解決するにはどうすればよいですか?

。

YARで試してみよう

メッセージキューは同時実行性の問題に対する根本的な解決策です

メッセージキューについて言及した人がいますが、リアルタイム要件が高く、非同期にできないシナリオには適していないようです。

phprpc を使用したことがないので、パフォーマンスに問題があるかどうかはわかりません。

しかし、他の製品の経験から判断すると、リクエストが行われるたびに接続ハンドルが開かれる場合、輻輳の問題が発生するはずです。 mysql へのイントラネット接続が特定のデータ レベルに達すると、接続遅延が比較的長くなりますが、クエリ プロセス自体は遅くありません。

これが理由である場合、yaf にもそのような問題が発生する可能性があります。調査の方向性は、長い接続と接続プールです。

リーリー

この分野には研究がありません。投稿者は http://wiki.swoole.com/wiki/page/196.html を試すことができます

何かご意見がございましたら、忘れずに共有してください

あなたの RPC はリアルタイムで問題を解決できません。 。 。長い接続を使用しているはずです。 。あなたのニーズと解決策が一致しない可能性があると思いますので、具体的なニーズについて話し合う必要があります。

高度なリアルタイム要件がない場合は、メッセージ キューを検討できます。

パフォーマンスが向上するかどうかを確認するために、php の swoole 拡張機能を検討することもできます。

お誘いありがとうございます。推奨メッセージキュー