How to build a High Performance PSGI/Plack Server PSGI/Plack・Monocerosで学ぶ ハイパフォーマンス Webアプリケーションサーバの作り方Read less
![How to build a High Performance PSGI/Plack Server](https://cdn-ak-scissors.b.st-hatena.com/image/square/265ebc0378c4e93e3b85f6c7bee1fca0cd9b962c/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fyapc2013psgi-plack-130919214359-phpapp01-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
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
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 の限界性能をもとに、その後、自分がなにかサーバ等を書いた場合に最適化したらどのぐらいの速度がでるかを予測できる(経験が必要だとおもうけど)
と言う事で、連結する変数が多くなると途中から 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;
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 :
大量にアクセスがあってMaxClientを大きく設定したい場合、Apacheの1プロセスあたりのメモリを少なくするのが重要。当然アプリ側で大きなライブラリを読み込まずに画像の変換はGearmandにタスクとして投げたりとかの工夫するのも有効だが、fork元になるApacheの親プロセスと子プロセス間でできる限りCopy on Writeな共有メモリを増やすのも有効。 その辺の詳しい仕組み等の話はnaoyaさんがd:id:naoya:20080212:1202830671でしてるのでそこを参考に。linuxカーネルまわりの仕組みって楽しいよね。会社の案件ではFreeBSDサーバーも結構あるんだけどFreeBSDではどうなるのかは知らない。 で、社内にXenなテストサーバーがあるのでまっさらな環境で色々実験してみた。・・・過程を全部書こうとしたら長くなったので省略。地味にpsしたり/proc/
最適化の心得 or HTTP::MobileAttribute最適化祭りに参加してみた HTTP::MobileAttributeの最適化祭りに突発的に参加してみた。 正直言うと未だにHTTP::MobileAttributeの中身であるClass::Componentを分かってない。なのでできることも限られてるわけだが。 今回のミニ祭りを見ていてよくわかるのは結局のところスピードに最も影響があるのは端的なコードの書き方ではなく構造(ストラクチャ)を見直す事であるというだ。id:tokuhiromのところでパフォーマンスチューニングの結果を追ってる人はわかると思うけど、結局俺が参加したのはもう本当にコードの書き方をチューニングするというレベルのところで、例えばループをアンロールしてif/elseで実装してみるとかね。でもそこはどんなにがんばっても数%のパフォーマンスゲインにしかならない。
サキとは彼女の自宅近く、湘南台駅前のスーパーマーケットで待ち合わせをした。彼女は自転車で後から追いつくと言い、僕は大きなコインパーキングへ車を停めた。煙草を一本吸ってからスーパーマーケットへ向かうと、ひっきりなしに主婦的な女性かおばあちゃんが入り口を出たり入ったりしていた。時刻は午後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
« キャッシュシステムの Thundering Herd 問題 | メイン | DBI::Printf - A Yet Another Prepared Statement » 2007年09月27日 ウェブサービスのためのMutex - KeyedMutex 昨日、以下のように書いたのですが、両者のうち2番目のアプローチを実現する Perl モジュール KeyedMutex を作成しました。 サーバにおける Thundering Herd 問題は良く知られていると思いますが、類似の現象はキャッシュシステムでも発生することがあります。 (中略) 対策としては、以下の2種類の手段があります。 バックエンドへの同一リクエストを束ねるような仕組みを実装する エクスパイヤ以前の残存時間が一定以下となった段階で、キャッシュエントリのアップデートを開始する これらの手法には、それぞれメリットとデメリッ
« MySQL の高速化プチBK | メイン | ウェブサービスのためのMutex - KeyedMutex » 2007年09月26日 キャッシュシステムの Thundering Herd 問題 サーバにおける Thundering Herd 問題注1は良く知られていると思いますが、類似の現象はキャッシュシステムでも発生することがあります注2。 通常、キャッシュに格納されるデータは、それぞれ単一の生存時間をもっています。問題は、頻繁にアクセスされるキャッシュデータがエクスパイアした際に発生します。データがエクスパイヤした瞬間から、並行に走る複数のアプリケーションロジックがミスヒットを検知し、いずれかのプロセスがキャッシュデータを格納するまでの間、同一のリクエストが多数、バックエンドに飛んでしまうのです。 対策としては、以下の2種類の手段があります。 バックエンドへの同一リクエストを束ねる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く