自分のサーバの性能を知っておく - tokuhirom's blog
http://github.com/kazuho/manymanythreads ↑kazuhoさんがCで書いたエコーサーバーと、そのベンチマークツールによって、自分のサーバでどんぐらいのQPSがでるのかがわかる。 たとえば自分のマシン(SC440)だと ./testechoclient -c 1 -n 1000000 -f -p 5050で、 77906.624081 reqs./sec. (1000000 in 12.835879 seconds)ぐらいでる。 一番単純なエコーサーバーをうごかしたときの性能を把握しておくことによって、どのぐらいの速度がでてしかるべきなのかが把握できるようになるという。 【追記】 ここで知った echo server の限界性能をもとに、その後、自分がなにかサーバ等を書いた場合に最適化したらどのぐらいの速度がでるかを予測できる(経験が必要だとおもうけど)
障害対応とチューニングの危うい関係
開発現場は日々の仕事の場であるとともに、学びの場でもある。先輩エンジニアが過去に直面した困難の数々、そこから学んだスキルや考え方を紹介する。 パフォーマンス・チューニング・チームのリーダーに 前回「オフショアなんて、怖くない」では、オフショアでの開発を含む大規模基幹システム構築プロジェクトの経験を基に、私がオフショア開発に思うことをお話ししました。今回はその続きで、同じプロジェクトでのパフォーマンス・チューニングについてです。 オフショアでの開発・結合テストも終了し、システムテストが開始されました。移行のリハーサルも無事完了し、数百万件のトランザクションが投入されました……。と、ここまでは順調に見えましたが、移行データでのテストを開始してすぐに、性能に関する問題が表面化しました。 数百件、数千件のテストデータでは問題なく動いていたアプリケーションが、ボタンを押しても数分間応答しなくなったり
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
