依存するモジュールはEPELを使うと簡単にインストールできる
$ sudo yum install perl-HTTP-Server-Simple perl-Regexp-Common
スクリプトの実行は以下
$ sudo perl ./build-virt.pl --private 仮想マシンのプライベートIP
スクリプトを実行すると、kickstartを配布するためのwebserverをforkして、virt-installを実行します。OSイメージはftp.iij.ad.jpから取得するように固定で書いてしまっています。
scriptはgistにおいてます => http://gist.github.com/334894
かなり決めうちで書いてますので実際使うにはカスタマイズが必要だと思います。
]]>WEB+DB PRESSで連載させて頂いている「大規模Webサービスの裏側」はVol.55にて第六回となり、最終回です。最終回は「監視」です。
「監視」の切り口を死活監視とリソース監視にわけて紹介し、後半はNagiosの設定や、Nagosの分散構成の解説です。Nagiosの分散構成はあまり資料がないので、（必要かどうかはおいておいて）面白いんじゃないかと思います。 同じVol. 55には宮川さんによるPSGI/Plackの記事もあるので、楽しみです。
昨日のデブサミ2010でRedHatの平さんとVmwareの各務さんの仮想化インフラのセッションでもでてきましたが、ハードウェアを知ることがその上で動くさまざまなソフトウェアを構築・運用していく上でも大事です。そのハードウェアを知るためにも監視を行い、リソースの利用のされかたを知るというのが重要だと思います。監視を楽に行えるよう様々なソフトウェアがあるので、どんどん活用して行きたいものです。
最終回となりますので、1年間のご愛読(まだ出てない)ありがとうございました！ 1年間連載できたことがいい経験になり、記事を書くことでより深く技術を理解できたことも非常によい体験になりました。それから、執筆に協力いただいた、吉野君、加藤幹生さん、木村さん、藤沢さん、あと校正手伝ってくれたたんぽぽおよび、運用グループの方、奥さんありがとうございました。
また、何か記事の内容について詳しく聞きたいとか、「ここはどうやっているの？」とか質問がありましたら、メールなどで頂けたらと思います。ブログ等どこかで紹介していこうと思います。
]]>んで、できたので、specファイルをさらしてみる
Summary: bundle package of Plack+AnyEvent
Name: perl-bundle-plack
Version: 0.3
Release: 1%{?dist}
License: Artistic
Group: Development/Libraries
Source: http://search.cpan.org/CPAN/authors/id/A/AP/APEIRON/local-lib-1.004009.tar.gz
Patch10: local-lib-1.004009_destdir.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: perl(YAML)
BuildRequires: perl(Config)
BuildRequires: perl(File::Path)
BuildRequires: perl(FindBin)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(ExtUtils::Install)
BuildRequires: perl(ExtUtils::CBuilder)
BuildRequires: perl(ExtUtils::ParseXS)
BuildRequires: perl(Module::Build) >= 0.28
BuildRequires: perl(CPAN)
AutoProv: no
%define buildhome %{_tmppath}/%{name}-%{version}-%{release}-home-%(%{__id_u} -n)
%define bundle_prefix /usr/local/bundle-plack
%define __perl_requires /usr/lib/rpm/perl.req --ignore_deps 'perl(Plack)'
%description
bundle package of Plack+AnyEvent
%prep
%setup -n local-lib-1.004009
%patch10 -p1
%build
[ "%buildroot" != "/" ] && rm -rf %buildroot
[ "%{buildhome}" != "/" ] && rm -rf %{buildhome}
export HOME=%{buildhome}
%{__mkdir_p} %{buildroot}%{bundle_prefix}
%{__mkdir_p} %{buildhome}/.cpan/CPAN
cat <<EOF > %{buildhome}/.cpan/CPAN/MyConfig.pm
\$CPAN::Config = {
'urllist' => [q[ftp://ftp.jaist.ac.jp/pub/CPAN/], q[ftp://ftp.riken.jp/lang/CPAN/]],
};
1;
__END__
EOF
perl -Ilib Makefile.PL --bootstrap=%{buildroot}%{bundle_prefix}
make
make install
rm -rf %{buildroot}%{bundle_prefix}/.modulebuildrc
%install
export HOME=%{buildhome}
export ORIGINAL_PREFIX=%{bundle_prefix}
export DESTDIR=%{buildroot}
sed -i "s/'urllist' => \[\],/'urllist' => [q[ftp:\/\/ftp.jaist.ac.jp\/pub\/CPAN\/], q[ftp:\/\/ftp.nara.wide.ad.jp\/pub\/CPAN\/], q[ftp:\/\/ftp.riken.jp\/lang\/CPAN\/]],/" %{buildhome}/.cpan/CPAN/MyConfig.pm
perl -I%{buildroot}%{bundle_prefix}/lib/perl5 -Mlocal::lib=--self-contained,%{buildroot}%{bundle_prefix} -MCPAN -e '
$ENV{PERL_MM_OPT} .= " INSTALLMAN1DIR=none INSTALLMAN3DIR=none";
$ENV{PERL_MM_USE_DEFAULT} = 1;
for my $m (qw/EV IO::AIO AnyEvent AnyEvent::AIO Coro
HTTP::Parser::XS Plack Plack::Request Plack::Server::AnyEvent/){
CPAN::Shell->rematein("notest", "install", $m);
}
'
#↑にいれるモジュールを書く
find %{buildroot}%{bundle_prefix} -name *.so -type f | xargs -I{} sed -i "s@%{buildroot}@@g" {}
sed -i "s@%{buildroot}@@g" %{buildroot}%{bundle_prefix}/.modulebuildrc
find %{buildroot} -name perllocal.pod -or -name .packlist | xargs rm -f
find %{buildroot}%{bundle_prefix} -type f -print |
sed "s@^$RPM_BUILD_ROOT@@g" |
grep -v ^%{_mandir} |
grep -v perllocal.pod |
grep -v "\.packlist" > %{name}.files
if [ "$(cat %{name}.files)X" = "X" ] ; then
echo "ERROR: EMPTY FILE LIST"
exit -1
fi
%clean
rm -rf %{buildroot}
rm -rf %{buildhome}
%post
%preun
%postun
%files -f %{name}.files
%defattr(-, root, root, -)
%dir %{bundle_prefix}
%changelog
どこかからのコピペが混ざっていたりと、あまりきれいではないけど。このspecファイルによって、/usr/local/bundle-plack以下にlocal::libと依存モジュールがすべてインストールできる。
使用するときは、普通のlocal::libと同じようにshellだったら
eval $(perl -I/usr/local/bundle-plack/lib/perl5 -Mlocal::lib=/usr/local/bundle-plack)
とやればOK。
この方式を利用することで、サービスで用いている他のモジュールに影響することなく、新しいモジュールをインストールでき、一部の必要としているところだけに適用できるってのがいいですね。
以下はlocal::libにあてているpatch
diff -ur local-lib-1.004009.orig/lib/local/lib.pm local-lib-1.004009/lib/local/lib.pm
--- local-lib-1.004009.orig/lib/local/lib.pm 2009-11-08 10:27:23.000000000 +0900
+++ local-lib-1.004009/lib/local/lib.pm 2009-11-26 11:59:21.000000000 +0900
@@ -235,6 +235,20 @@
File::Spec->catdir($class->install_base_perl_path($path), $Config{archname});
}
+sub install_base_path {
+ my ($class, $path) = @_;
+ $ENV{ORIGINAL_PREFIX} ? $ENV{ORIGINAL_PREFIX} : $path;
+}
+
+sub destdir {
+ my ( $class ) = @_;
+ if ( $ENV{DESTDIR} && $ENV{DESTDIR} !~ m!/$! ) {
+ $ENV{DESTDIR} .= '/';
+ }
+ $ENV{DESTDIR};
+}
+
+
sub ensure_dir_structure_for {
my ($class, $path) = @_;
unless (-d $path) {
@@ -253,8 +267,11 @@
warn "Attempting to create file ${modulebuildrc_path}\n";
open MODULEBUILDRC, '>', $modulebuildrc_path
|| Carp::croak("Couldn't open ${modulebuildrc_path} for writing: $!");
- print MODULEBUILDRC qq{install --install_base ${path}\n}
+ print MODULEBUILDRC qq{install --install_base } . $class->install_base_path(${path}) . qq{\n}
|| Carp::croak("Couldn't write line to ${modulebuildrc_path}: $!");
+ if ( my $destdir = $class->destdir ) {
+ print MODULEBUILDRC qq! --destdir $destdir\n!;
+ }
close MODULEBUILDRC
|| Carp::croak("Couldn't close file ${modulebuildrc_path}: $@");
}
@@ -344,9 +361,10 @@
sub build_environment_vars_for {
my ($class, $path, $interpolate) = @_;
+ my $destdir = ( $class->destdir ) ? " DESTDIR=" . $class->destdir : "";
return (
MODULEBUILDRC => $class->modulebuildrc_path($path),
- PERL_MM_OPT => "INSTALL_BASE=${path}",
+ PERL_MM_OPT => "INSTALL_BASE=" . $class->install_base_path(${path}) . $destdir,
PERL5LIB => join($Config{path_sep},
$class->install_base_perl_path($path),
$class->install_base_arch_path($path),
もっとスマートな方法があればだれか教えてくださいませ(_ _)
]]>1.4.0では、こちらに書いた通り、いつの間にかdeleteのtimeoutがサポートされなくなった。なので、
delete key timeout noreply
というコマンドが無効になって困ることになった。それでも
delete key timeout
というコマンドは、timeoutにどんなも文字列が入っていてもエラーになることはなかった。timeoutは効かないけど。
ここから1.4.4ではさらに悪化。timeoutが0でないとエラーになるようになった。つまり
delete key 0 noreply
delete key 0
は有効なんだけど、
delete key 10
がエラーになるようになった。 この変更のコミットはこれ。
実際試す。
% telnet localhost 11234
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
version
VERSION 1.4.4
delete key 10
CLIENT_ERROR bad command line format. Usage: delete <key> [noreply]
quit
プロトコルの変更は下位互換が基本中の基本だと思うんだ。また１つmemcachedが嫌いになった。
]]>nginxがnon-blockingで動いているので、組み込みのPerlでもblockingする処理をいれることはおすすめされていないのですが、sleepだけは機能が用意されていました。使い道がよくわからないけど、とりあえずレスポンスを遅延させるのだけやってみた。
まず、handlerとなるperlモジュール
package delay;
use nginx;
sub handler {
my $r = shift;
my $args = $r->args;
$args =~ m/sleep=([^&]+)/;
my $sleep = $1 || 1;
$r->variable("sleep", $sleep);
if ( $sleep ne "no" ) {
$r->sleep($sleep * 1000, \&next);
return;
}
$r->send_http_header("text/html");
$r->print("<html><head><title>title</title></head><body>sleep:$sleep</body></html>\n");
return OK;
}
sub next {
my $r = shift;
my $sleep = $r->variable("sleep");
$r->send_http_header("text/html");
$r->print("<html><head><title>title</title></head><body>sleep:$sleep</body></html>\n");
return OK;
}
1;
このコードの中の$r->sleepが遅延実行ようにするところ
$r->sleep( msec, func )
となるようです。
これを利用するnginx.conf
worker_processes 16;
events {
worker_connections 32768;
}
http {
include /usr/local/nginx-server/conf/mime.types;
default_type application/octet-stream;
sendfile on;
tcp_nopush on;
keepalive_timeout 60;
perl_modules /path/to/lib;
perl_require delay.pm;
server {
listen 80;
server_name localhost;
access_log off;
location / {
perl delay::handler;
}
}
}
ApacheBenchでベンチマークをとったところ、
ab -c 1000 -n 100000 'http://localhost/?sleep=0.1'
Concurrency Level: 1000
Time taken for tests: 10.449 seconds
Complete requests: 100000
Failed requests: 0
Write errors: 0
Total transferred: 19100000 bytes
HTML transferred: 6900000 bytes
Requests per second: 9570.41 [#/sec] (mean)
Time per request: 104.489 [ms] (mean)
Time per request: 0.104 [ms] (mean, across all concurrent requests)
Transfer rate: 1785.11 [Kbytes/sec] received
想定通り、1コネクションあたり10req/secできるみたい。
これだけだと使い道があまりわからないだけど、nginxのevent loopが組み込みperlから利用できるようになる最初の一歩だと期待すればwktkです。
あと、調べた感じ、組み込みperlを入れるオーバーヘッドは5%ぐらいだった。7万req/secが6万6千req/secぐらい
]]>アプリケーションがマルチスレッドになってもネットワーク処理が分散されなければマルチコアを活かせない典型的な例です。id:viverの古橋さんがs100kpsとしてあげていた件にも近いかも。
memcachedで現象を確認します。最近のmemcachedはマルチスレッドで動くようになっているので、まずはそれを確認します。
$ memcached-tool localhost stats|grep threads
threads 4
スレッドが4つで起動しています。
負荷がそれなりにある状態(8000req/sec程度)で、コマンドラインでtopを開き、「1」キーを押して、CPUごとの使用率を表示します。(例はFedora8 kernel-2.6.23)
Tasks: 77 total, 1 running, 76 sleeping, 0 stopped, 0 zombie
Cpu0 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu1 : 3.0%us, 5.7%sy, 0.0%ni, 75.3%id, 0.0%wa, 7.7%hi, 8.3%si, 0.0%st
Cpu2 : 0.0%us, 0.3%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3692 nobody 20 0 10.9g 10g 716 S 10 44.0 10253:09 memcached
＊メモリの行は削除しています。
CPUは4つ認識されていますが、CPU1しか使用されていないのがわかると思います。おそらく、CPU1のアイドルがなくなった時点で他のCPUに空きがあってもそれ以上の処理ができなくなります。なぜCPU1しか使われないかは「/proc/interrupts」をみるとなんとなくわかります。NICはBroadcom BCM5722です。
$ cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
0: 10569 0 10460 0 IO-APIC-edge timer
16: 301 301 302 303161 IO-APIC-fasteoi aerdrv, aerdrv, aerdrv, ioc0, eth0
17: 8 3570118309 7 7 IO-APIC-fasteoi eth1
memcachedの通信は主にeth1で行われるのですが、このeth1に関する割り込み処理がCPU1でしか行われていません。ソフトウェア割り込みはハードウェア割り込みが行われたCPUでしか行われないのもこの傾向を強めます。
マルチコアCPUの性能を活かすために考えられることは、ネットワークの割り込み処理を複数のCPUに分散することだと思うのですが、最新のNICにはRX/TX Multiple Queue(正式名称がわからない。Receive Side ScalingとかScalable I/O？)機能が備わっています。もともとRX/TX Multiple Queueは10GbpsのNICなどに備わっていた機能で、複数の割り込みチャンネルを持つことでネットワーク処理の分散を実現しています。最近のIntelやBroadcomの1GbpsのNICにも同じ機能があります。
以下はBroadcomのBCM5709を搭載しているマシンのinterrupts。(CentOS 5.3)
CPU0 CPU1 CPU2 .. CPUy CPUz
0: 342688765 0 0 0 0 IO-APIC-edge timer
114: 55 34 19613 39212 11 PCI-MSI-X eth0
122: 23 0 145 193 0 PCI-MSI-X eth0
130: 243 0 75 138 0 PCI-MSI-X eth0
138: 24 12 10423 35836 6 PCI-MSI-X eth0
146: 2141 0 110 556 0 PCI-MSI-X eth0
154: 21 4 12802 17806 7 PCI-MSI-X eth0
162: 561 0 216 72 0 PCI-MSI-X eth0
186: 72 76 97076 137548 197952 PCI-MSI-X eth1
194: 24 45478 100337 140189 554148 PCI-MSI-X eth1
202: 24 527452 94677 87876 305476 PCI-MSI-X eth1
210: 23 220400 175792 56390 205521 PCI-MSI-X eth1
218: 24 37023 30778 6169 11788 PCI-MSI-X eth1
226: 21 349792 48599 91969 0 PCI-MSI-X eth1
234: 23 206063 5911 43536 4 PCI-MSI-X eth1
＊加工済み
こんな感じで、割り込み処理用のチャンネルが複数個存在して、CPU間で分散ができています。
まとめると、マルチコアCPU、SSDの普及によってハードウェアの性能があがり、epoll/kqueue/event portsによって大量のコネクションをさばけるようになると、こういった複数のCPUに分散できない処理がボトルネックになってくるので、最新のハードウェアとか対応しているカーネルを利用しようということです。
]]>まず、共通していること、前提など
サーバは主に4タイプあります。
小規模DB、Q4MやGearmanなどのJobQueue/Workerサーバ、memcachedやSquid/Varnishなどのキャッシュサーバに利用するサーバ。目的に応じてHDDをSSDに換装して利用できることが必要となります。
アプリケーションサーバやリバースプロキシーに使う。おそらく最もCPU(ユーザ)の負荷が高い。性能の高く、コア数が多いCPUでぶん回して全体のサーバ台数は減らしたい。
中負荷〜高負荷DBとして利用。SSDについて入れ替えではなく追加としてしているのはデータベースのデータ部分をSSD、バイナリログをHDDとそれぞれの特性に応じて使い分けるためになります。メモリについては後述します。
メモリにすべてのデータが乗り切らないデータ蓄積型、大規模なDB用。
48〜64GBとしたメモリに関して、64GBを積むためには1本8GBのものを買わないとならなく、4GBと比べると3倍程度するのが悩みどころ。メモリの値段は上がってきている中で8GBの値下がりするのか注目。また、今年の後半(前半？)には、Westmere-EPが出て、6コア/12スレッドになるので、また少し状況が変る可能性がありますね。こちらも注目
]]>奥一穂さんのエントリーでは、「5,000万PV/Month」という見積もりでアプリケーションサーバの台数を1台と計算していますが、これからは「1,000万PV/Day」を超えるサイトが多く生まれてくると予想しています。どんなサイトかというと、mixiアプリやモバゲーなどにソーシャルゲームを提供するサイトです。
ソーシャルゲームサイトのキャパシティプランニングについては中澤さんのエントリーが参考になります。
最も人気がでた場合には数千万から数億PV/Dayという数字がならんでいます。怖い怖い
1,000万PV/Dayとなると、ピークのリクエスト数が平均の2倍として秒間に230リクエストとなります。
( 10,000,000 pv / 86400 sec/day ) * 2 = 231.481481
奥一穂さんの試算であれば、クアッドコアのサーバで秒間40回の処理が可能なので、6台程度のアプリケーションサーバがあれば、1日1,000万PV、月に3億PVがさばけることになります。冗長性や安全をとるためにサーバを増やしたり、またクアッドコアを2つ搭載するマシンを採用することも考えられますが、この数字は自分の経験と比べても大きなずれはない数字です。
さて、ここからが本題で、1,000万PV/Day（秒間230 req/sec)には何台のデータベースが必要となるのでしょうか。Shardingを行ってデータベースの分散を行い多くのデータベースサーバを運用する必要があるのでしょうか。
1リクエストにつき、SQLを8回発行した場合、秒間のクエリー数の最大は1840query/sec
230 req/sec * 8 = 1840 query/sec
このうち、5%程度が更新系のクエリーだったとしたら、更新系クエリは92 query/secとなり、
1840 query/sec * 0.05 = 92 query/sec
残りが参照クエリとなり、1748 query/secとなります。1リクエストあたりのSQL数や更新回数はアプリケーションにより大きく変動しますが、この程度のクエリー数の場合、MySQLであれば1台で処理することは可能です。冗長性やバックアップのためのSLAVEサーバも追加して1組2台あれば安定稼働できます。
多くのSQLをさばくためには、クアッドコア以上のCPUや十分なメモリー、最適なデータベースサーバの設定や、効率のよいスキーマとSQLの設計が必要です。Blogサービス等でなければデータをあまり蓄積しないのも重要です。MySQLであれば次の書籍が非常に参考になります。
もし、アプリケーションがもっと多くのクエリーを発行していたり、負荷が大きな場合には、安くなったSSDを使ったり、SLAVEサーバを追加して参照クエリーを分散を行ったり、memcachedを利用して参照クエリを減らしたり、また、更新が多いテーブルだけを別のMySQLサーバに移動したり、データが単純なkey-valueであればTokyo TyrantやRedisなどを利用すれば、データベースサーバを最小限にとどめることができます。
2010年代は手軽に購入できるようになった高性能なハードウェアでスケールアップし、OSやミドルウェアのチューニングを行うことで、アプリケーションサーバ、データベースサーバを最小限に食い止め、サービスの収益率を改善してお給料を増やしてもらうのがよいのだろうと思う。
]]>
プライベートでは、昨年は子供が生まれ生活ががらりと変わった一年でした。仕事の方に目を向けると、前回に続いてのYAPC::Asiaでの発表、mixiアプリの開始による変化への対応、また、技術評論社様のWEB+DB PRESSで連載をさせて頂くなど新しいチャレンジもできました。
今年は息子が保育園に入る予定があるなどなどまだまだ激動は続きそう。そして6月には0x20歳。仕事も去年の激動の余波が残っていますが、2011年、2012年と何を目指すのかも自分なりに考えていたいなぁと思っています。
ってことで今年もよろしくお願いします。
]]>WEB+DB PRESSで連載させて頂いている「大規模Webサービスの裏側」もVol.54にて第五回となりました。
第五回目の今回は、「ログ＆データ解析 .. 現状の改善と新サービス開発のために」ということで、アクセスログの解析やデータマイニングの話題を、システム運用グループの加藤幹生さん、研究開発の木村さんと藤澤さんに書いて頂きました。
一般にシステム運用の仕事のイメージとは少し異なりますが、大量のデータをさばく重要な技術のひとつです。
]]>はなぼくろ師との共作です。
目的は、AnyEventでもマルチコアを使いたいよねという理由ですが、それほど一般的な利用はないと思います。plackupの方でprefork処理を行うとかいう話もあったりなかったりなので、しばらくCPANにはアップロード予定ありません。不足している部分もありますので、fork & patchウェルカムです
Hello Worldだけのテストで生AnyEventとの比較 ベンチマークをしたサーバはVMware ESXi上の仮想マシン。一応CPU 2つ割当てある
起動はこんな感じ
plackup -a hello.psgi --server AnyEvent::Prefork --max_workers 2 --max_reqs_per_child 10000 --port 8080 --env production
AnyEvent
Concurrency Level: 100
Time taken for tests: 3.941 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 680000 bytes
HTML transferred: 40000 bytes
Requests per second: 2537.41 [#/sec] (mean)
Time per request: 39.410 [ms] (mean)
Time per request: 0.394 [ms] (mean, across all concurrent requests)
Transfer rate: 168.50 [Kbytes/sec] received
AnyEvent::Prefork
Concurrency Level: 100
Time taken for tests: 2.673 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 680000 bytes
HTML transferred: 40000 bytes
Requests per second: 3740.71 [#/sec] (mean)
Time per request: 26.733 [ms] (mean)
Time per request: 0.267 [ms] (mean, across all concurrent requests)
Transfer rate: 248.41 [Kbytes/sec] received
preforkにするだけで、req/secが50%アップしてます。 これで多少CPUを使ったり、block処理が入ってもAnyEventで動かすことができるんじゃないかなと思います。
現在残っている課題としては、子プロセスがmax request per childに達した際にまず、新規のacceptを行わないようにしていますが、その際に既存のコネクションをいつまで保持するかの処理が入っていない点です。streamingをやっていた場合は新規のacceptを受けない状態でいつになってもプロセスが死なない→新規のプロセスが立ち上がらない→リクエストを全く受けれない。なんていうことが起こることです。 現状としては、アプリケーションに応じてそのあたりの処理を入れていくしかないと思われます。
会社の最新サーバでも試してみたいな。
]]>毎日どんなtipsが上がってくるのか楽しみです。
いきなり初日ですが、Casual trackで記事を1つ書かせて頂きました。
最速IPアドレスマッチ研修会 - JPerl Advent Calendar 2009
http://perl-users.jp/articles/advent-calendar/2009/casual/01.html
内容はIPアドレスが指定したCIDR内にあるかの確認を行なえる各モジュールのベンチマークです。Net::IP::Match::XSは高速ですが、まだまだ最適化の余地がありそうな気がしています。
]]>アクセスが出来なくなっていた原因は、自宅サーバが落ちていたということですが、なぜ落ちていたかというと、UPSが壊れたっぽいからです。
現在はUPSなしで動いてますので、停電があるとまた止まってしまう可能性があります。こちらの対策も早めに行うつもりです。
(そういや、ここ何年か停電を経験してないかも)
これまで使っていたUPSは、三菱電機のFREQUPSの350VA製品。 実は6年ぐらい使っていました（ここが駄目 バッテリがもうだめだったのでしょう。交換考えないとなぁと思っていた矢先でした。
UPSが壊れて気になるのは、その廃棄方法です。調べると、鉛が入っているので通常のゴミとして捨ててはならないようです。
そこで調べたところ、オムロンのUPSを新規にUPSを購入した場合に、オムロンが他社のUPSでも無料で引き取っていることを発見。
APCでも同じようなサービスやってる
ということで、オムロンもしくはAPCのUPSを買い直して、こちらのサービスを利用して今のUPSを引き取ってもらおうか検討中。
350VAクラスのUPSなら、Amazonで結構安いNe。
WEB+DB PRESSで連載させて頂いている「大規模Webサービスの裏側」の4回目がVol. 53に掲載されます。
第三回目のデータベース設計編に続いて実運用編となっています。
内容は、OSの設定、ファイルシステムのチューニングから、MySQLの設定と監視の話です。1000台を超えるサーバを管理・運用していく上でのポリシーなども混ぜて書いています。
紹介している設定などは大規模なサービスにだけ利用できるものではなく、小規模な運用でもパフォーマンス向上のために参考にできることが多いと思います。
松信さんの本や、アメブロさんの本と内容が被っていますが、8ページと手軽に読めると思いますので、ぜひお手をとって頂ければと思います。
その他Vol. 53には、mixiと同じくというか、規模がそれより大きいかもしれないYahoo!オークションの運用についての特集があります。
10年以上サービスを続けているということで、さまざまなノウハウや経験がつまった記事になっています。やはり、他社の事例を読んだり、想像したりするのは面白いですね〜。参考になりました
あわせて読みたい
(即納できるみたいです)
【オマケ】
Software Designの11月号にはバタラさんのインタビューが載ってますね。
これを使うと、streamingをサポートしたサーバから非同期/nonblockingにhttpやGearmanを利用して外部へ問い合わせを行い、その結果をレスポンスしたりできます。
また、これがPlackで既に実装済みなので、非常に短いコードでサーバの実装ができちゃいます。
すばらしいですね。
すでにmiyagawaさんが、この機能を利用した非同期Web Framework「Tatsumaki」を書かれています。
イベントを扱う部分が隠蔽されているので、これを使うとさらに簡単に実装できます。
すばらしすぐる。
ここでは、簡単に外部へAnyEvent::HTTPを用いて、HTTPリクエストを行うサンプルを書いてみます。
use AnyEvent;
use AnyEvent::HTTP qw//;
$AnyEvent::HTTP::MAX_PER_HOST = 20;
my $url = 'http://localhost/tmp/sleep3.cgi';
my $hanlder = sub {
my $env = shift;
my $cv = AE::cv;
AnyEvent::HTTP::http_get $url, sub {
my $content = shift;
$cv->send(
[ 200, [ "Content-Type" => 'text/plain', ], [$content] ] );
};
return sub {
my $start_response = shift;
$cv->cb(
sub {
$start_response->( shift->recv );
}
);
}
}
PSGIのHandlerでcallbackを返し、その中でhttpアクセスからの通知を待ちます(recv)。 Any::Event::http_get でレスポンスが得られたら、配列形式のレスポンスを構築しcallbackへ通知します。
起動はplackupを利用します。
% plackup --app test.psgi --server AnyEvent port 8080
アクセス先のsleep3.cgiは3秒間のsleepしてからレスポンスを返す通常のCGIです。 なので、このサーバへアクセスすると必ず、レスポンスに3秒かかります。
% time curl http://localhost:8080/
sleep 3
curl http://localhost:8080/ 0.00s user 0.01s system 0% cpu 3.052 total
では、abを利用して、平行してリクエストするとどうなるでしょう。
% time ab -c 10 -n 10 http://localhost:8080/
Concurrency Level: 10
Time taken for tests: 3.328 seconds
Complete requests: 10
Failed requests: 0
Write errors: 0
Total transferred: 720 bytes
HTML transferred: 80 bytes
Requests per second: 3.01 [#/sec] (mean)
Time per request: 3327.714 [ms] (mean)
Time per request: 332.771 [ms] (mean, across all concurrent requests)
Transfer rate: 0.21 [Kbytes/sec] received
ここで重要なのは、3行目のこのテストにあわせてどれくらいの時間がかかっているかです。
3秒×10回の30秒ではなく、ほぼ、3秒しかかかっていません。これは10個のリクエストを非同期に処理、sleep3.cgiへのアクセスし、レスポンスを返していることで実現できています。
これだけコード量も少なくこのような機能をつくれるのはうれしいですねー。
]]>