Perl スクリプトで遅い場所を特定する方法 - Devel::Profiler / Devel::NYTProf
今仕事で書いてる Sledge アプリがあるのですが、先日負荷テストを行った結果びっくりすることに現行アプリの１０倍遅いことが判明してしまいました・・・orz Sledge フレームワーク自身が重くないことは今までの経験でわかってるのですが、どうにもソースを見直しているだけでは原因が特定できない・・・そんな活躍するのがプロファイラです。プロファイラの御陰で遅いヶ所を特定することができ、無事に想定するパフォーマンスを得ることができました。この内容に関してはまた別エントリにて。 さて、プロファイラを使うとプログラム実行時の各種情報を収集し、性能解析を行うことが可能です。プロファイラについてもう少し詳しくしるには 性能解析 - Wikipedia あたりを読むと良いでしょう。 プロファイラ（英: Profiler）は性能解析ツールであり、プログラム実行時の各種情報を収集する。特に、関数呼び出しの
イケてないプログラム（使えない成果物）に見られる３つの共通点
クイックソートの話で書いたとおり、相変わらず Excel - VBA と格闘する日々が続いております・・・orz 「大企業にありがちな問題。委託開発の甘い罠・・・」でも書いたとおり、今まで外注して作ったソフトウェアってほぼ 100% の確率でイケていないものが完成してます。年末に納品されたソフトウェアのできも酷いの何のって・・・ さて、いままで見てきたイケてないプログラムのダメソースに共通して言えることが３点ありまして、 DRY ( Don’t Repeat Yourself ) でない。同じもしくは似たソースのコピペが至る所に散在する。 ロジックに無駄が多すぎ。行き当たりばったりで作った感、満点。 アルゴリズム知らなさすぎ。馬鹿ループ処理で時間かかりすぎ。 のいずれか、もしくは全部が当てはまります。大抵は全部ですね。こういったソースが納品されると、センス無いなぁ〜と思っちゃうわけ。こうい
lighttpd + FastCGI は mod_perl + Apache1.3 より１割ほど高速 :: Drk7jp
巷で超高速 Web サーバとして話題になっている lighttpd を試してみました。lighttpd に関する日本語ドキュメントは非常に少なく、ちょっと込み入った設定ファイルの記述方法とかの解析に手間取りました。 lighttpd のコンセプトは、「セキュアで省メモリで高速に動作し、柔軟性もある」なのですが、「lighttpd 公式サイトのベンチマーク結果」や「UnknownPlace. - Catalyst ベンチ」で簡単な Catalyst - Hello.cgi のベンチマークが公開されているとおり、Apache 1系、Apache 2系よりも高速に動作するようです。特に static なページの処理は Apache の 2〜3 倍程度は高速に処理できるみたいです。 また注目すべき点として、Apache + mod_perl よりも lighttpd + FastCGI の方が１割
使える言語は Perl と言うと何故にバカにされるのか？
？さん 「言語何使ってる？」 僕 「Perl がメインかなぁ〜」 ？さん 「( ´_ゝ｀)ﾌｰﾝ Java じゃないんだぁ・・・今時 CGI で書いてるの？」 ここで言う Java ってのは Tomcat や Resin に代表される Servlet / JSP コンテナを利用したプロセス常駐型 java の事を指してます。決して Java-cgi のことを意味していません。多分彼らも、そういったことは意識していないと思います。 本業で随分昔（servlet 技術が出る前）に作成した Java-cgi で作られたアプリケーションが現役で活躍していますが、とてつもなく遅いです。いわゆる Perl-cgi が遅いと言われる理由と一緒です。一番の勘違いのポイントは、 CGI = Perl って図式が無意識のうちにあると言うことですね。でも実際は、CGI の定義は、アクセスがあるたびにサーバが新し
Fedora Core 4 リリース
先日、Linux 界の最新・最良版を宣言していた Fedora Core 4 がリリースされましたね。今回の主だった機能は、 Power PC アーキテクチャ（32bit / 64bit）に正式対応 最新の kernel 2.6.11 を採用 コンパイラが gcc 4.0 に変更 Gnome 2.10、KDE 3.4、OpenOffice 2.0 Beta、Eclipse 3.1 M6 等の最新のオープンソースを搭載 VMware みたいなマシン仮想技術 Xen 2 を標準搭載 RedHat Global File System (GFS)への対応 と言ったところ。gcc 3 系から gcc 4 へのメジャーバージョンアップはかなり気になる点で、コンパイルできないものが一杯でてきそうで怖い。gcc 2 系から 3 系にメジャーバージョンアップしたときの苦い記憶が頭をよぎります。 逆に歓迎す
やはり Perl はメモリ喰いな言語。データ型の内部構造
use Devel::Size::Report qw/report_size/; # 1bit, 1byte, 2byte, 3byte, 4byte(=32bit), 5byte my $b = [ 0, 0xFF, 0xFFFF, 0xFFFFFF, 0xFFFFFFFF, 0xFFFFFFFFFF ]; print report_size($b, { indent => " " }); # null, length=1, 2, 3, 4, 5 my $c = [ '', '1', '10', '100', '1000', '10000' ]; print report_size($c, { indent => " " }); Size report v0.10 for 'ARRAY(0x8c8bc28)': Array ref 192 bytes (overhead: 92 byte
Perl 5.6系 と 5.8系では巨大配列の処理効率が違う :: Drk7jp
Perl 5.6系 と 5.8系では巨大配列の処理効率が違う 仕事で、OLAP チックな処理を MySQL でやらせて、その結果を Perl で整形して出力なんてことを書いているのですが、久々に原因不明の処理速度低下でハマりました。 ５万レコード×２００セルほどのデータを DBI 経由の fetchrow_arrayref で取得して、その配列リファレンスを元にゴニョゴニョ置換処理やら文字列マッピング処理などをやっていたのですが、Perl 5.6.1 では処理時間が３分ほども要してしまい、要求仕様を全然満たせなかったのですが、どうにも腑に落ちなく Perl 5.8.6 な環境で同じプログラムを動作させたら、僅か２０秒で処理が完了しました。 top コマンドでメモリ使用量を見ていたら、perl 5.6.1 では 230 MB 程度しか確保してくれないらしく、Perl 5.8.6 では 6
CGI で特定フレームを指定して実行する方法
Perl CGI でフレーム分割したアプリケーションにおいて、リクエスト毎の認証チェックでエラーになったときに、フレームの親、つまり全画面（"_top"）で認証画面にリダイレクトする要求仕様を満たすために、いろいろ調べました。次のようなヘッダーを出力すれば良いみたいです。 print "Location: http://www.xxxx.co.jp/auth.cgi\n"; print "Window-Target: _top\n\n"; 特定のフレームを指定して書き換えたいのであれば、「Window-target: フレーム名」 とすれば良いようです。本当は、CGI.pm の redirect メソッドとで header メソッドを組み合わせて、
[_11_Install] intel compiler で Apache が 400% 高速化
「無料で30%のパフォーマンスUP!! - intel compiler」でも書いた intel compiler ですが、apache1.3.33 + mod_perl 1.29 を再構築してみました。apache bench で速度を測ってみたら、ナント 400% も高速化していました。?(￣□￣;)ﾅﾝﾄ!! 本当かぁ？？と思って数回試してみましたが、結果は同じでした。スゴイ！ 以下、インストールメモとapache bench のログです。 mv /usr/bin/gcc /usr/bin/gcc.bk ln -s /opt/intel_cc_80/bin/icc /usr/bin/gcc mkdir /usr/local/src/icc cd /usr/local/src/icc wget http://www.meisei-u.ac.jp/mirror/apache/dist/h
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
