Tornado アプリのログファイル書き込みのチューニング : DSAS開発者の部屋
最近は協力プレイやPvPなどの「リアルタイムサーバー」を書くときは Go が主流になっているのですが、 Tornado を使ったシステムも健在です。 (以前の記事) 数人〜十数人程度の「部屋」を、1つの Tornado プロセスに複数もたせ、さらに一台のサーバーにその Tornado プロセスを複数置くことでCPUのマルチコアを活用する構成になっているのですが、最近各プロセスがログファイルを書く部分でブロックして応答性能が悪化するケースがあったので対策しました。 この記事ではその対策で行ったチューニングや、行わなかったチューニングについても紹介します。 ※なお、この記事は Tornado を題材にしていますが、似たような仕組みになっている node.js などの他の言語のフレームワークでも同じ事が言えるはずです。 前提知識 Tornado は epoll や select などのIO多重化
【実録ドキュメント】そのログ本当に必要ですか？
今回の概要 数人で利用しているときは、レスポンスが軽快だったシステムで、ユーザー数が増えてくると急激にレスポンスタイムが悪化する現象が発生した。現場から学ぶWebアプリ開発のトラブルハック 第2回で扱ったFull GCなどいくつか原因が考えられるが、本稿ではログ出力にまつわるトラブルをドキュメンタリー形式で紹介し、まとめとしてログ出力のパフォーマンスに関するTipsを紹介する。 今日もまた、突然電話が鳴り響く ある穏やかな朝、突然電話が鳴る。相手は結合テストの工程からパフォーマンステストで支援に入る予定のプロジェクトの担当者である。用件は「結合テストを20人のテスターで実施しようとしているが、レスポンスタイムが1分を超えていて、テストがままならない。早急になんとかしてほしい」 これだけの情報では、トラブルをハックすることはできないので、Webアプリの問題点を「見える化」する7つ道具をノート
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
