私のプログラムには、ログ ファイルに (タイマーで) 定期的にフラッシュされる std::stringstream があります。フラッシングとタイマーは、デフォルトの実行ループにあります。
アプリの他の部分はその std::stringstream に追加するだけで、残りはタイマーが処理します。stringstream のサイズを (1 MB に) 制限しているので、ストリームが「満杯」の場合はメッセージをドロップします。
私はちょうど疑問に思っています、これはベストプラクティスです;
node.js はログをどのように処理しますか?
その質問は、一見して考えるよりも複雑だと思います。
良い反応の一部は、libuv とはほとんど関係がなく、具体的なニーズとトレードオフに大きく関係しています。たとえば、いくつかのバッファリング (つまり書き込みシステムコールの頻度が低い) は良いことですが、ロギングの領域で大きな問題が発生する可能性がある (または問題にならない) こともあります。理由: バッファリングされたものは、アプリケーションが停止すると、アプリケーションと共に停止します。ただし、これはロギングのロジックに反します。
libuv とパフォーマンスに関して、私の個人的な経験は、
a) 情報を書き出すこととバッファリングの間のバランスをうまく見つけたい。あなたの場合、私の直感は、バッファリングが多すぎて、おそらくもっと頻繁に書き出す必要があるということです。
b) パフォーマンスが本当に重要であるかどうか、および詳細の両方の観点から、パフォーマンスについてよく考えたいと考えています。後者は、サーバーの負荷が高い場合にますます重要になります。100 程度の接続を提供する場合はおそらく関係ありませんが、数万または数十万の接続を提供する場合、fprintf などの便利な関数を使用するにはコストがかかりすぎる可能性があります。
具体的な例: 高負荷の状況では、単調タイマー (非常に安価) の現在の値 (そのとき) とともに、起動時に 1 回壁時間を取得したい場合があります。任意の時間情報は、その開始値に関連している可能性があります (単純な減算)。書き出すと、次のように機能します: 事前にフォーマットされた開始ウォール時間と単調差分 (例: "03:52:41 +123456 ms")。
シナリオのもう1つのポイントは、最新のOSは事実上常に優れたバッファリングを提供するため、通常、自分でバッファリングしすぎることはあまり意味がありません.
全体として、約 16K または 32K のバッファーを使用し、より頻繁に書き出すことをお勧めします。シナリオが高パフォーマンス/高負荷である場合 (およびその場合のみ)、便利ではあるが高価な関数を避けたい場合があります。
libuvに関する限り、私は心配しません。お使いの OS と libuv のバージョンによっては、(ソケットのものとは対照的に) ファイルのものは実際には疑似非同期 (スレッド化による偽造) である可能性がありますが、私の経験では、libuv は問題ではありません。むしろ、たとえば、大きなバッファが複数のチャンクに書き込まれる可能性があるため、問題になる可能性があります。
タイマー ベースのアプローチに関しては、libuv のアイドル メカニズムを確認し、バッファがいっぱいになる問題にも対処する必要があります。ログ情報を単純に破棄することは、私には受け入れられないように思えます。結局のところ、楽しみのためにログを記録しているわけではありませんが、その情報はおそらく重要であるためです (そうでなければ、そもそも問題はありません。その場合の解決策は簡単です。ログを減らすことです)。
最後に、より一般的な発言をしたいと思います。ここでの秘密はバランスであり、個々の詳細の最適化されたパフォーマンスではありません。たとえば、問題を解決するのではなく、最終的に問題を別のレベルにプッシュするだけの大きなバッファーを使用して最適化するのではなく、システム全体のバランスを適切に保つ必要があります。
私はその問題分野を、たとえば会社の本社を移動するタスクのように考えるのが好きです。問題は最速のトラックではなく、すべてのトラックが非常に高速であること、つまりバランスの取れたアプローチです。