タグ

performanceに関するbull2のブックマーク (10)

  • 満足せる豚。眠たげなポチ。:大規模サービスの運用事例まとめ

    ここ数年の大規模サービスのシステム運用について調べてみたので参照したページやファイル、へのリンクをまとめておく。PDF へのリンクも多数含まれているのでご注意を。 時代が時代なら企業のノウハウとして隠されていたような情報がこれだけ公開してもらえているというのが非常にありがたい。公開してくれている各企業や公開してくれている人に感謝。 あとで気付いたが、Google や Facebook の事例も探しておけばよかった。Thrift とかあったのに。「こんな情報もあったよ」などあればぜひ教えてください。追記していきます。 youtube http://d.hatena.ne.jp/stanaka/20070427/1177651323 digg http://d.hatena.ne.jp/stanaka/20070427/1177651323 livedoor http://labs.cybo

  • OProfileの使い方備忘録 - hogelogの日記

    プログラムのボトルネックがどこにあるのか、なんて調べるときには計測する必要がありますね。プログラム中の特定処理の前後でrdtsc命令使って時間を計測して処理時間を求める、とかそういうこともできるんですけど、まあめんどうじゃないですか。プロファイラを使いましょう。 プロファイラとはなんぞや、Wikipediaの性能解析のページに色々書いてますね。 そういうわけでOProfileというLinuxで動くプロファイラを使っているので、未来の自分とか「OProfile動かしてみてーけどさっぱりわからん!」みたいな人のためにまとめておきます。 OProfileの特徴 OProfileは 計測したいプログラムに対して特別な処理をしなくてもいい 低レイヤーの情報も計測できる gprof形式のコールグラフも表示できる オーバーヘッドがとても小さい これらの特徴があるらしいです。使ってみて特に嬉しいと感じたの

    OProfileの使い方備忘録 - hogelogの日記
  • はてなブックマークが重い件について、Page Detailerというツールを使って調べてみる - VTuberになったプログラマーの魂の残滓

    JavaScriptの部分は というわけでid:amachangに任せましょう。 というわけでそれ以外の部分でいったいどこが重いのか 何が重いの?ということで重たい箇所を分析していきましょう。 IBM PageDetailer 解析ツールとしてIBM PageDtailerを利用します。 alphaWorks Community 解説するよりも見てもらうほうが早いと思うのでさっそく使ってみるよ。 ちなみに上記ソフトのダウンロードにはIBMアカウント(無料)が必要なので、使いたい人は登録しよう! http://b.hatena.ne.jp/HolyGrail/ の結果 こんな感じのグラフが出てきます。 では、詳細を見てみましょう。 このグラフですが、長い部分が http://b.hatena.ne.jp/HolyGrail/ のHTMLそのもののロード時間になっています。 内訳としては 濃い

    はてなブックマークが重い件について、Page Detailerというツールを使って調べてみる - VTuberになったプログラマーの魂の残滓
    bull2
    bull2 2008/11/27
    Webのパフォーマンス改善に参考になる
  • mixi Engineers’ Blog » Tokyo Tyrantによる耐高負荷DBの構築

    連休中はWiiのマリオカートをやりまくってやっとVR7000越えたmikioです。愛車はマッハ・バイクとインターセプターです。さて今回は、分散ハッシュデータベースサーバTokyo Tyrantでmixiの最終ログイン時刻を管理するようにした時の苦労話を書きます。 ログイン処理は負荷地獄 mixiでは、全てのユーザについて、各々の最終ログイン時刻を管理しています。「マイミクシィ一覧」や「お気に入り」などの画面で、友人が近い時間にログインしていてコミュニケーションがとりやすい状態にあるかどうか確認できるようにするためです。 mixiのほぼ全てのページはログインしないと見られないページなので、ほぼ全てのページにアクセスされるたびにログイン確認が行われます。したがって、最終ログイン時刻はほぼ全てのページにアクセスされる度に更新されることになります。mixiの中で最も重いデータベースのひとつとして「

    mixi Engineers’ Blog » Tokyo Tyrantによる耐高負荷DBの構築
  • パフォーマンスチューニングについて悩むこと - higepon blog

    ここ数日時間をかけているわりにはインタプリタのパフォーマンスチューニングが進まない。 しかもうまく進む気がしないもやもやする。これは良くない兆候だ。 Mさんに言わせればこれは知識や経験やどこまでやりこんだことがあるかといったものが足りないことに起因するようだ。 すぐそこに速くなるはずのものがあるのにもどかしい。 なので自分が知っていることやったこと悩んでいることを書いてみようと思う。 パフォーマンスチューニングとは? パフォーマンスチューニングは以下の要素と手順からなると思う。 目標 チューニングのための動機。 要求される速度が出ていないとか。 1秒以内にレスポンスを返すようにとか。 調査 ボトルネックとなる場所を特定する。 チューニング 問題となるコードに手を加えて速くする。 再計測 目標を達成しているか? 上記をくり返す。 これをベースに考えよう。 目標 大きな目標は Gauche 以

    パフォーマンスチューニングについて悩むこと - higepon blog
  • Linuxのネットワークスループット改善法教えます - builder by ZDNet Japan

    Linuxのカーネルやそれを含むディストリビューションでは、ネットワークのパラメータに影響を与えるような設定の一部は、デフォルトでは非常に控えめに設定されていることが一般的である。このような設定をチューニングするには、/procファイルシステムを使用する方法やsysctlプログラムを用いる方法があるが、どちらかというと後者の方がよい場合が多い。なぜかというと、後者の場合は/etc/sysctl.confファイルの内容を読み取るため、リブートを行っても設定が保持されるからだ。 /etc/sysctl.confで行える設定のうち、ネットワークのパフォーマンスを向上させる可能性がある設定を以下に示そう。 net.ipv4.tcp_window_scaling = 1 net.ipv4.tcp_syncookies = 1 net.core.rmem_max = 16777216 net.core

  • mixi Engineers’ Blog » libmemcachedで快速キャッシュ生活

    みんな大好きなmemcached。今日はBrian AkerのC言語用クライエントライブラリについて書きたいと思います。日語の情報がとても少なく、ドキュメンテーションも英語だけという事で興味はあるけど手をつけていないという方のお役に立てれたらなと思います。 題の前に why libmemcached? 既にlibmemcacheが存在するのに何故、libmemcached?かと言うと理由の一つは最近libmemcacheの開発が止まったからです。家ではそれが理由でlibmemcacheではなくlibmemcachedを推奨してますね。又、効率的なメモリ使用、Consistent Hashing、様々なハッシュアルゴリズム、新しいオペレータに対応している等という宣伝文句があります。apr_memcacheというライブラリも存在しますが自分は使った事がないためノーコメント。 ただ、推奨さ

    mixi Engineers’ Blog » libmemcachedで快速キャッシュ生活
  • ウノウラボ Unoh Labs: 画像の遅延読み込み

    yamaokaです。 webページの表示を高速化する手法にはいろいろありますが、 その一つとして遅延読み込みという手法があります。 初期状態で表示する必要のない要素については読み込まず、 必要になったタイミングで読み込み、表示するようにする手法です。 ページの読み込みにかかる時間の大半を 画像の読み込みが占めている場合が多いので、 画像の読み込みを遅延させるという手法が多く取られます。 検討するべきケース では、画像の遅延読み込みはどのような場合に検討されるべきでしょうか。 最初から表示されている必要がない画像が存在し、その画像のサイズが大きかったり、 そうした画像の数が多い場合は検討してみる価値があると思います。 例えば、次のようなケースです。 初期状態では表示されないブロックに属する画像が存在し、 JavaScriptで表示するかしないかを切り替えているような場合 ページのずーっと下の

  • オープンソース情報データベースシステム(OSS iPedia) のコンテンツについて

    オープンソース情報データベースシステム(OSS iPedia) は、2013年5月17日(金) をもちまして運用を終了いたしました。 長い間ご利用をいただきましてありがとうございました。 OSS iPediaで提供しておりました、IPAフォント、文字情報基盤、その他報告書等については、下記リンクをご参照ください。 皆様には大変ご不便をおかけいたしますが、何卒ご理解の程をよろしくお願い申し上げます。

  • /dev/shm に参照系DBを持っていくと I/O 負荷が激減した件(当たり前だけど)

    前エントリーから一部の内容を分離して追加記事にしてみました。以下実施したメモリ増設の効果について。 ここ数ヶ月、自宅サーバの負荷がだんだんと上昇してきていて、そろそろ1台で高速にさばききる限界に近づいてきた感があったり。ここ数週間のロードアベレージはこんな感じ。グラフは× 100 の値になってます。CPU のコアが2個なんで、200 までは OK ということでまだ処理しきれているわけではあります。ちなみに mrtg グラフは瞬間値を示しているわけではなく平均値なので瞬間的にはもっと負荷が高いときとかあります。 でも月次処理が走るともっさり感満点。 ※緑:1分平均 / 青:15分平均 実は CPU の処理速度が追いついていないと言うより I/O 周りがボトルネックになっています。 ※緑:読取ブロック数 / 青:書込ブロック数 ということで、メモリを2GBプラスして、合計 4GB にして参照系

  • 1