最近、私は管理者のサーバーで同じ問題が発生しました。
私はこのことを考え出す前に、長い時間、少なくとも2週間、blitz.ioで無駄な一日を費やしました。
場合によっては、サイト上の任意のWebページがランダムに破損することがあります。最初のクリックは効果がなく、ページの一部のみを読み込むか、最も一般的には背景のみが表示されます。それは時間の約5％が発生するように見えました。
この問題は、直帰率が高くなり、広告費用が浪費されたため、特に問題でした。
問題が発生した正確な時刻について、nginxのログでは、「readv（）が失敗しました（104：ピアによって接続がリセットされました）」というメッセージが表示されました。 Googleの検索では、私の場合に適用されたこの問題に対する有用な解決策はないことが明らかになりました。それでも、PHPを非難することは、PHPがすでにブラウザに出力を送信した後に発生したように見えるので、私にとってはあまり意味がありませんでした。
Google Chromeでは、このメッセージには常に「エラー337（net :: ERR_SPDY_PROTOCOL_ERROR）」が付いていたため、GoogleのSPDYサポートが壊れていたかどうか疑問に思っていました）、またはnginxの私のバージョンがSPDYサポートを壊していた場合。 nginxをSPDYのバグ修正を行ったバージョンにアップグレードしても問題は解決しませんでしたが、Chromeの問題について読んだことはすべて、Googleサーバーの問題で、2011年のこの問題が発生したことを示唆しています。
私のサーバー上でnginx、PHP、およびTCPのタイムアウトを使って、私はあきらめる準備ができました。
過去にPHP 5.5のZend OpcacheとPayPalのMerchant SDKに問題があったので、Zend Opcacheもこれに関連しているのか疑問に思っていました。最後にZend Opcacheを完全に無効にしようとしましたが、驚いたことに、問題を再現できなくなったことがわかりました。
私はOpcacheのドキュメントを読んで、私がオンにした別の設定指示のいくつかの言及を期待していましたが、これはこの問題に寄与しているかもしれません。私は本当にXCacheに戻ってほしくない。結局のところ、Zendは時々ほぼ40％速くなっています。最後に、私は、php.iniでこれにそれを絞り込む：
opcache.fast_shutdown = 1
は、私は、とZend Opcacheをオフに設定することは、もはや、オンにしない任意のERR_SPDY_PROTOCOL_ERRORsまたはランダム接続が低下していたことになりました。ありがたいことに、fast_shutdownを無効にしてもパフォーマンスに大きな影響はなかったようです（おそらく1msが追加されました）。
FPMプール設定で 'catch_workers_output'を使用していますか？参照：http://stackoverflow.com/questions/8677493/php-fpm-doesnt-write-to-error-log – parhamr