How to build a High Performance PSGI/Plack ServerHow to build a High Performance PSGI/Plack Server PSGI/Plack・Monocerosで学ぶ ハイパフォーマンス Webアプリケーションサーバの作り方Read less
ソーシャルアプリ向けシステム監視運用の勘所
Tatsuro Hisamori from DeNA Co., Ltd. discusses mbga OpenPlatform and summarizes techniques for optimizing database and application performance including using tcpdump, Wireshark, and mk-query-digest to analyze SQL queries and network traffic. He also provides examples of optimizing resources and response times by distributing applications across virtual machines and monitoring CPU usage, database
自分のサーバの性能を知っておく - 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 の限界性能をもとに、その後、自分がなにかサーバ等を書いた場合に最適化したらどのぐらいの速度がでるかを予測できる(経験が必要だとおもうけど)
Perl 最速伝説k - Yokohama.pm Teck Talk #1
と言う事で、連結する変数が多くなると途中から join が最速になる。"$a$b$c" のような形式は最適化されて $a . $b . $c となるようだがやはり数に関わらず最も遅いので使わない。 続・スカラーの文字連結 http://www.ibm.com/developerworks/jp/linux/library/l-optperl/ より 他にも色々拡張してみた。 #!/usr/bin/perl use strict; use warnings; use Benchmark qw(:all); my $limit = 100; my $sets = { concat1 => sub { my $string = 'abcdefghijklmnopqrstuvwxyz'; my $concat = ''; for (1..$limit) { $concat .= $string;
モジュールをuseした際のメモリ使用量(増加量)を調べてみる (iandeth.)
iandeth. Perl, Flash ActionScript, MySQL, Movable Type, システム開発 - そんなテーマのサイトdeth. gtop.plx #!/usr/bin/perl use strict; use warnings; use GTop; my $gtop = GTop->new; my $before = $gtop->proc_mem($$)->size; eval $ARGV[0]; die $@ if $@; my $after = $gtop->proc_mem($$)->size; my $diff = GTop::size_string($after - $before); print "$diff : $ARGV[0]\n"; 例） CGIモジュールのメモリ増加量は... $ ./gtop.plx 'use CGI' 704k :
mod_perlで親プロセスとのCopy on Writeな共有メモリを増やす方法。 - hideden.hatenablog.com
大量にアクセスがあってMaxClientを大きく設定したい場合、Apacheの1プロセスあたりのメモリを少なくするのが重要。当然アプリ側で大きなライブラリを読み込まずに画像の変換はGearmandにタスクとして投げたりとかの工夫するのも有効だが、fork元になるApacheの親プロセスと子プロセス間でできる限りCopy on Writeな共有メモリを増やすのも有効。 その辺の詳しい仕組み等の話はnaoyaさんがd:id:naoya:20080212:1202830671でしてるのでそこを参考に。linuxカーネルまわりの仕組みって楽しいよね。会社の案件ではFreeBSDサーバーも結構あるんだけどFreeBSDではどうなるのかは知らない。 で、社内にXenなテストサーバーがあるのでまっさらな環境で色々実験してみた。・・・過程を全部書こうとしたら長くなったので省略。地味にpsしたり/proc/
最適化の心得 or HTTP::MobileAttribute最適化祭りに参加してみた - D-6 [相変わらず根無し]
最適化の心得 or HTTP::MobileAttribute最適化祭りに参加してみた HTTP::MobileAttributeの最適化祭りに突発的に参加してみた。 正直言うと未だにHTTP::MobileAttributeの中身であるClass::Componentを分かってない。なのでできることも限られてるわけだが。 今回のミニ祭りを見ていてよくわかるのは結局のところスピードに最も影響があるのは端的なコードの書き方ではなく構造（ストラクチャ）を見直す事であるというだ。id:tokuhiromのところでパフォーマンスチューニングの結果を追ってる人はわかると思うけど、結局俺が参加したのはもう本当にコードの書き方をチューニングするというレベルのところで、例えばループをアンロールしてif/elseで実装してみるとかね。でもそこはどんなにがんばっても数%のパフォーマンスゲインにしかならない。
ゆーすけべー日記: YourAVHost その後
サキとは彼女の自宅近く、湘南台駅前のスーパーマーケットで待ち合わせをした。彼女は自転車で後から追いつくと言い、僕は大きなコインパーキングへ車を停めた。煙草を一本吸ってからスーパーマーケットへ向かうと、ひっきりなしに主婦的な女性かおばあちゃんが入り口を出たり入ったりしていた。時刻は午後5時になる。時計から目を上げると、待たせちゃったわねと大して悪びれてない様子でサキが手ぶらでやってきた。 お礼に料理を作るとはいえ、サキの家には食材が十分足りていないらしく、こうしてスーパーマーケットに寄ることになった。サキは野菜コーナーから精肉コーナーまで、まるで優秀なカーナビに導かれるように無駄なく点検していった。欲しい食材があると、2秒間程度それらを凝視し、一度手に取ったじゃがいもやら豚肉やらを迷うことなく僕が持っているカゴに放り込んだ。最後にアルコール飲料が冷やされている棚の前へ行くと、私が飲むからとチ
ブラウザキャッシュの挙動を見てみる - 日向夏特殊応援部隊
改めて勉強したかったので、こんなテストしてみました。 Apacheの設定とテスト内容 <VirtualHost *:80> ServerAdmin zigorou@localhost DocumentRoot /home/zigorou/www/cache ServerName cachetest.art-code.org ExpiresDefault "access plus 5 minutes" Alias /test1 /home/zigorou/www/cache/test Alias /test2 /home/zigorou/www/cache/test Alias /test3 /home/zigorou/www/cache/test <Location /test1> FileETag None ExpiresActive Off </Location> <Location
Kazuho@Cybozu Labs: ウェブサービスのためのMutex - KeyedMutex
« キャッシュシステムの Thundering Herd 問題 | メイン | DBI::Printf - A Yet Another Prepared Statement » 2007年09月27日 ウェブサービスのためのMutex - KeyedMutex 昨日、以下のように書いたのですが、両者のうち２番目のアプローチを実現する Perl モジュール KeyedMutex を作成しました。 サーバにおける Thundering Herd 問題は良く知られていると思いますが、類似の現象はキャッシュシステムでも発生することがあります。 (中略) 対策としては、以下の２種類の手段があります。 バックエンドへの同一リクエストを束ねるような仕組みを実装する エクスパイヤ以前の残存時間が一定以下となった段階で、キャッシュエントリのアップデートを開始する これらの手法には、それぞれメリットとデメリッ
Kazuho@Cybozu Labs: キャッシュシステムの Thundering Herd 問題
« MySQL の高速化プチBK | メイン | ウェブサービスのためのMutex - KeyedMutex » 2007年09月26日 キャッシュシステムの Thundering Herd 問題 サーバにおける Thundering Herd 問題注1は良く知られていると思いますが、類似の現象はキャッシュシステムでも発生することがあります注2。 通常、キャッシュに格納されるデータは、それぞれ単一の生存時間をもっています。問題は、頻繁にアクセスされるキャッシュデータがエクスパイアした際に発生します。データがエクスパイヤした瞬間から、並行に走る複数のアプリケーションロジックがミスヒットを検知し、いずれかのプロセスがキャッシュデータを格納するまでの間、同一のリクエストが多数、バックエンドに飛んでしまうのです。 対策としては、以下の２種類の手段があります。 バックエンドへの同一リクエストを束ねる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Apache2-Filter-Minifier-JavaScript-1.07 - JavaScript minifying output filter for mod_perl - metacpan.org
Apache2-Filter-Minifier-CSS-1.07 - CSS minifying output filter - metacpan.org