Pythonスクリプトのパフォーマンス計測ガイド | Yakst
Pythonスクリプトの速度を計測し、そのボトルネックを探る。さらに、メモリ使用量、メモリリークの原因特定までの調査方法を解説する。 あなたが書いたすべてのPythonプログラムで厳密なパフォーマンス計測が必要になるというわけではないにせよ、その時が来たら、役に立ってくれる様々な種類のツールがPythonのエコシステムにはあるのだということを知っておけば安心できるだろう。 プログラムのパフォーマンスを計測することは、すなわち以下の4つの基本的な質問に答えることだと要約できる。 どのくらい高速に実行できるか？ スピードのボトルネックはどこか？ どのくらいのメモリを使うか？ メモリリークしているのはどこか？ これから、いくつかの素晴らしいツールを使ってこれらの質問に答えていくための詳細を見ていこう。 大ざっぱな実行時間 素早くざっくりとコードの実行時間を計るのに、古き良きUNIXのユーティリテ
ファイルシステムよりも35％高速に | POSTD
1. 概要 SQLiteを使うと小さなBLOB（例：サムネイル画像など）を読み書きする場合、fread()やfwrite()を使って個別のファイル上に記録されたBLOBを読み書きするよりも35％も速く (*1) 読み書きができます。 さらに、10キロバイトのBLOBを扱うようなSQLiteデータベースを考えた場合、個別のファイルにそれぞれのBLOBを格納する場合に比べてディスク領域を約20％も節約可能です。 このようなパフォーマンスの差が生じる理由は、（私たちの考えでは）SQLiteデータベースの場合、open()やclose()システムコールが呼び出されるのが1回だけなのに対して、個別のファイルに格納されているBLOBを使用する場合は、open()やclose()がBLOBの数だけ呼び出されるためだと思われます。どうやらopen()とclose()を呼び出すオーバーヘッドは、データベース
Redis latency spikes and the Linux kernel: a few more details - <antirez>
Today I was testing Redis latency using m3.medium EC2 instances. I was able to replicate the usual latency spikes during BGSAVE, when the process forks, and the child starts saving the dataset on disk. However something was not as expected. The spike did not happened because of disk I/O, nor during the fork() call itself. The test was performed with a 1GB of data in memory, with 150k writes per se
How we keep GitHub fast
EngineeringHow we keep GitHub fastThe most important factor in web application design is responsiveness. And the first step toward responsiveness is speed. But speed within a web application is complicated. Our strategy for keeping… The most important factor in web application design is responsiveness. And the first step toward responsiveness is speed. But speed within a web application is complic
ウェブサイトパフォーマンス入門 - ニコール・サリバン | warikiru
2009-11-29 ウェブサイトパフォーマンス入門 - ニコール・サリバン ラベル: performance, report Web Directions East 2009 ワークショップ 11月12日 ウェブサイトパフォーマンス入門 ニコール・サリバン 通訳はcouldの長谷川さんだよ。 Design Fast WebsitesView more documents from Nicole Sullivan.スライドはほぼこれと一緒で、収益に関するデータが新たに追加されてた感じ。 Nicole Sullivan （ニコール・サリバン）3000以上にも昇る大規模サイトの最適化に携わって来た Nicole Sullivan は、現在 Yahoo! のパフォーマンスエンジニアと最適化のエバンジェリストとして国内外のセミナーで講演。Webサイトに関する研究だけでなく、プロジェクト管理もこなす
漢(オトコ)のコンピュータ道: MySQLを高速化する10の方法
ちょっとキャッチ−なタイトルをつけてしまったが、今日は独断と偏見でMySQLを高速化する方法を10個紹介しよう。MySQLサーバをチューニングするときや初期導入する場合などに参考にしてもらいたい。 1. バッファを増やす、または減らす チューニングの基本中の基本であるが、適切なバッファサイズを設定することはパフォーマンスチューニングの要である。主なバッファは次の通り。 innodb_buffer_pool_size・・・InnoDBだけを利用する場合は空きメモリの7〜8割程度を割り当てる最も重要なバッファである。余談だが、実際にはここで割り当てた値の5〜10%ぐらいを多めにメモリを使うので注意が必要だ。 key_buffer_size・・・MyISAMだけを利用する場合は、空きメモリの3割程度を割り当てるといい。残りはファイルシステムのキャッシュ用に残しておこう。 sort_buffer_
メモリリークトラブルシューティング記 - その5: Memory Analyzer でヒープダンプを解析(最終回) - 侍ズム
- その1: 自宅サーバがハング - その2: フリーズの原因はガベージコレクション - その3: 侍でヒープ使用量を確認 - その4: リーク箇所を確認する色々な方法 - その5: Memory Analyzer でヒープダンプを解析(最終回) 今回のメモリリーク現象はリークの再現方法がわからないため、運用環境から詳細なデータが取得できるheapdumpを取得した、というのが前回までのあらすじです。 次は、ヒープダンプの解析。 ヒープダンプは JDK に付属の jmap コマンドで取得します。 jmap -heap:format=x [pid] または jmap -heap:format=b [pid] といった形で実行するとヒープダンプを xml 形式、またはバイナリ形式で記録できます。 通常生のヒープダンプを人間の目で読むことはないので xml 形式は使いません。バイナリ形式で取得し
Yahoo!パフォーマンスチーム、最新高速化ルール20を発表 | エンタープライズ | マイコミジャーナル
Webアプリケーション開発に欠かせないFirefoxエクステンションであるFirebugをベースにして開発されたWebページのパフォーマンス計測ツールにYSlowがある。2007年12月上旬にはパフォーマンス分析能力を向上させたYSlow 0.9がリリースされた。紹介にもあるように、手軽に導入できるうえにかなり効果的に分析ができるところに特徴がある。 YSlowの強みとなっているのはYahoo! Exceptional Performanceチームが分析した評価基準をベースにしている点にある。Yahoo!が実際に分析した結果をベースにしているだけあって効果が確実なものとして効いてくるわけだ。 そのYahoo! Exceptional Performanceチームから最新の調査結果およびパフォーマンスブレークスルーのための新しいルールが発表された。既存の14のルールに加えて、新しく20のルー
Chromeはなぜ速いのか － ＠IT
Chromeの動作が圧倒的に速いように感じている。Chromeがリリースされた当初、それがなぜなのかよく分からなかった。グーグルだけにできて、ほかのWebブラウザ開発者にできないことなどあるように思えないが、それにしてはあまりに速いように感じたからだ。 その疑問のほとんどは、Chromeのオープンソースプロジェクト版「Chromium」の公式ブログの解説で氷解した。ブログを読んで分かったのはグーグルのエンジニアたちが信じられないほどのスピード狂であることと、そのスピードへのこだわりには2種類の“スピード”があることだ。 1つは処理速度、もう1つは応答速度だ。特に後者、ユーザーをできるだけ待たせない、イラつかせないということに対する徹底したこだわりは、すさまじい。その背後には「スピードとは、つまりお金だ」という洞察があるようだ。 0.5秒の遅延でユーザー離れ グーグル創業約1年後の1999年
秋元@今日も頑張ってます! � YSlowのSteve Souders氏が新測定ツールHammerheadをリリース
米Yahoo!のクライアント側パフォーマンスチューニングで名を上げ、Googleに移籍した、「ハイパフォーマンスWebサイト」の著者スティーブ・サウダーズさんが、新しいプラグインHammerheadを出しました。 Hammerheadは、FirefoxのFireBug拡張の上で動く子拡張。Firebugを入れた上でインストールする必要があります。 Firefox3のアドオンマネージャのセキュリティチェックに引っかかるので、パラメータをいじらないとインストールできません。about:configから手順に沿ってパラメータを一つ追加する必要があります。 ブラウザ側のパフォーマンス測定をするときは、キャッシュの影響を排除しないと正確な測定ができません。このプラグインではまず、ディスクやメモリ上のキャッシュをステータスバーからクリアするための簡易な手順が提供されます。 これは、3つのURLについて
KOF 2008 の発表資料 - naoyaのはてなダイアリー
KOF 2008 での発表資料「はてな流大規模データ処理」を以下にアップロードしました。 http://bloghackers.net/~naoya/ppt/081108huge_data.ppt 一部参考文献からの引用 (Introduction to Information Retrieval から Vector space model の図、たつをの ChangeLog から転置インデックスの図) があります。この場を借りて感謝。 環境によってはおそらくフォントの表示がいまいちだと思いますが、ご了承ください。 追記 SlideShare にアップロードしました。 081108huge_data.pptView SlideShare presentation or Upload your own. (tags: linux mysql) 追記: メモリはディスクの 150 倍について
第4回 Railsアプリケーションをもっと速く | gihyo.jp
Rails Web アプリケーションをもっと速く こんなストーリーを考えてみます。 あなたは、Railsを学び、アプリケーションを作成し、サービスをインターネットに公開しました。しばらくすると、最初のユーザができます。あなたはとてもハッピーです。そうするうちにユーザが二人増え、十人になり、百人になりました。あなたはハッピーです、ユーザーもみんなハッピーです。 でも、ユーザが千人になり、一万人になり…。といった場合、何が起こるでしょうか？ そこで起こるのはアプリケーションへの同時接続数増加によるサービス提供速度の低下です。ユーザ数が一万人を越えてしまうWebサーバに特有の問題は、C10K問題として知られています。 それでなくとも、残念ながらRailsは同様他種フレームワークと比べて、単位時間あたりの処理量が低いことで知られています。その理由は、RailsではRubyが遅くて、NativeTh
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Railsアプリケーションのパフォーマンス改善手法 / #ginzarb
MySQL load data infile - acceleration?
Web ページを高速化する
チューニング - データベース ( MySQL ) - 自宅サーバーの構築 - 自宅サーバーでやってみよう！！
「実現したいことを計算機の問題に置き換えることが『技術力』」、伊藤CTOが“はてな流”大規模データ処理の極意を語る：CodeZine
ヤフーの画像はなぜyimg.jpドメインなのか？ サイト高速化の手法とヤフーの失敗例 | 初代編集長ブログ―安田英久
IndexBuilding - Welcome
Hardware - Welcome