Pythonスクリプトのパフォーマンス計測ガイド | Yakst
Pythonスクリプトの速度を計測し、そのボトルネックを探る。さらに、メモリ使用量、メモリリークの原因特定までの調査方法を解説する。 あなたが書いたすべてのPythonプログラムで厳密なパフォーマンス計測が必要になるというわけではないにせよ、その時が来たら、役に立ってくれる様々な種類のツールがPythonのエコシステムにはあるのだということを知っておけば安心できるだろう。 プログラムのパフォーマンスを計測することは、すなわち以下の4つの基本的な質問に答えることだと要約できる。 どのくらい高速に実行できるか？ スピードのボトルネックはどこか？ どのくらいのメモリを使うか？ メモリリークしているのはどこか？ これから、いくつかの素晴らしいツールを使ってこれらの質問に答えていくための詳細を見ていこう。 大ざっぱな実行時間 素早くざっくりとコードの実行時間を計るのに、古き良きUNIXのユーティリテ
パフォーマンスチューニングでprofiler使わないのは損してると思う - Qiita
print文を仕込んで実行時間を出力していくパフォーマンスチューニング作業は辛いのでもう止めにしようってお話です。 プログラムで実行速度が遅いロジックを特定できれば改善は容易です。profilerを利用すると簡単に原因が特定できるので使い方を紹介します。前半はline_profilerを利用した実行速度が遅いロジックの特定方法、後半はPythonでの高速化テクニックです。 どの行が重いかprofilerで特定する ローカル環境でprofilerを使いどの行が重いのかを特定していきます。Pythonには様々なprofilerが存在しますが、個人的にはline_profilerが必要十分な機能を持っていてよく利用しています。ここで特定するのは『どの行がN回実行されていて、全体でM%の実行時間が掛かっている』という点です。 line_profilerの使用例 実行に10秒くらい掛かるサンプルコー
ファイルシステムよりも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()を呼び出すオーバーヘッドは、データベース
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サイトに関する研究だけでなく、プロジェクト管理もこなす
秋元@今日も頑張ってます! � YSlowのSteve Souders氏が新測定ツールHammerheadをリリース
米Yahoo!のクライアント側パフォーマンスチューニングで名を上げ、Googleに移籍した、「ハイパフォーマンスWebサイト」の著者スティーブ・サウダーズさんが、新しいプラグインHammerheadを出しました。 Hammerheadは、FirefoxのFireBug拡張の上で動く子拡張。Firebugを入れた上でインストールする必要があります。 Firefox3のアドオンマネージャのセキュリティチェックに引っかかるので、パラメータをいじらないとインストールできません。about:configから手順に沿ってパラメータを一つ追加する必要があります。 ブラウザ側のパフォーマンス測定をするときは、キャッシュの影響を排除しないと正確な測定ができません。このプラグインではまず、ディスクやメモリ上のキャッシュをステータスバーからクリアするための簡易な手順が提供されます。 これは、3つのURLについて
第4回 Railsアプリケーションをもっと速く | gihyo.jp
Rails Web アプリケーションをもっと速く こんなストーリーを考えてみます。 あなたは、Railsを学び、アプリケーションを作成し、サービスをインターネットに公開しました。しばらくすると、最初のユーザができます。あなたはとてもハッピーです。そうするうちにユーザが二人増え、十人になり、百人になりました。あなたはハッピーです、ユーザーもみんなハッピーです。 でも、ユーザが千人になり、一万人になり…。といった場合、何が起こるでしょうか？ そこで起こるのはアプリケーションへの同時接続数増加によるサービス提供速度の低下です。ユーザ数が一万人を越えてしまうWebサーバに特有の問題は、C10K問題として知られています。 それでなくとも、残念ながらRailsは同様他種フレームワークと比べて、単位時間あたりの処理量が低いことで知られています。その理由は、RailsではRubyが遅くて、NativeTh
blog.katsuma.tv
もう、いろんなニュースサイトで言われていますが、 Yahooからページパフォーマンス計測ツールの「YSlow for Firebug」が リリースされました。Firebugをインストールしている上で、YSlowをインストールすると、Webサイトの高速化を行うためのポイントと、 現状についてのポイント表示を行ってくれます。 これ、実際に試してみるとよく分かるのですが、いかに工夫をしていないサイトは、改善の余地があり余っているか。。 ほんと身を引き締められます。ちなみにYSlowでは次の項目をポイントに挙げています。 Make Fewer HTTP Requests Use a Content Delivery Network Add an Expires Header Gzip Components Put CSS at the Top Move Scripts to the Bottom
川o・-・）＜2nd life - Railsの最適化に関する10の事柄
http://weblog.textdrive.com/article/175/rails-optimizing-resource-usage TextDriveで、Optimizing Rails Resource Usageという記事が公開されました。Railsの最適化について10の事柄を挙げています。興味がある人は原文を読んでもらうとして、ここでは軽くサマリー(意訳)を。間違っていたらコメント歓迎！ 1. 最小限のFastCGI 開発には1つのDispatcherで十分。A list Apartでも4つのFastCGI Dispatcherで動かしてて速くてloadも0.01だよ。あとFCGIが増えるとDBコネクションも増えるからね。 2. キャッシュを使う Dispatcherを通さずキャッシュを使う。Railsではとっても簡単にキャッシュ使えるし、期限設定も楽だし。lighttp
Rubyist Magazine - RubyOnRails を使ってみる 【第 10 回】 パフォーマンスチューニング
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日本 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直
もう少しだけmod_cacheを深追いしてみる - Ogawa::Memoranda
Posted by: Hirotaka Ogawa @ February 16, 2007 05:42 PM | 前のエントリーで書いた方法だとブラウザによってはページをリロードするたびに待たされることになります。 mt-search.cgiをmod_cacheで超高速化する!! - Ogawa::Memoranda なんでかな？と思ったので、動的コンテンツ(この場合はURLにクエリ文字列を含む動的コンテンツ)へのリクエストに対する、(mod_cacheで実現された)サーバーサイドキャッシュの振る舞いをもう少し深追いしてみました。 サーバーサイドキャッシュがない場合 サーバーサイドキャッシュがない場合には、すべての動的コンテンツへのリクエストごとにレンダリングを行い、そのデータがレスポンスとして返されます。 動的コンテンツで、Last-Modified, ETagヘッダを含むレスポンスを行
404 Blog Not Found:あなたのページを最速にする14の掟
2007年05月11日18:45 カテゴリiTech あなたのページを最速にする14の掟 人気Webサイトの管理人、必読。 紹介ページ: 14 rules for fast web pages (Skrentablog) PPTのスライド: http://www.web2expo.com/presentations/webex2007/souders_steve.ppt 実は、これらはYahoo!の"Chief Performance Yahoo!"(本当にそういう役職名)であるSteve Soudersによる以下のblog entriesをまとめたもの。 Performance Research, Part 1: What the 80/20 Rule Tells Us about Reducing HTTP Requests Performance Research, Part 2:
Ruby on Railsのパフォーマンス向上に関する10のtips:
という記事があった、色々と面白かったので訳してみる。良いとこも悪いとこもあると思うけど参考までにメモとして 元記事：Top 10 Ruby on Rails performance tips Rubyの基本的なコードを見直してみる自分で作ったクラスよりもできるだけ組み込みのクラスライブラリを使うできるだけ正規表現を使用する、文字列処理にコストの高いループは避けるREXMLは遅いのでLibxmlライブラリを使用する （Cで書かれたXMLパーサらしい、環境に依存するのは嫌かもしれない）if文の多用は避ける、例えば||=を使う ( z||="none" で unless(z){ z = "none" })Hashはコストが高いので他のデータ構造を検討してみる （でも使いたいときあるよね？）キャッシュを有効活用する acts_as_cached でModelをキャッシュ化してみる(PDF資料
Top 10 Ruby on Rails performance tips
The performance of Ruby on Rails is influenced by many factors, particularly the configuration of your deployment server(s). However the application code can make a big difference and determine whether your site is slow or highly responsive. This short article is about some of the tips and best coding practices to improve performances in Rails only, and won’t attempt to cover the server configurat
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Railsアプリケーションのパフォーマンス改善手法 / #ginzarb
「実現したいことを計算機の問題に置き換えることが『技術力』」、伊藤CTOが“はてな流”大規模データ処理の極意を語る：CodeZine
ヤフーの画像はなぜyimg.jpドメインなのか？ サイト高速化の手法とヤフーの失敗例 | 初代編集長ブログ―安田英久
IT戦記 - Shibuya.js Technical Talk #1 を終えて。