Archive for June, 2009

Velocity 2009 Day 3

June 27th, 2009 by naoya | No Comments | Filed in day

Velocity 最終日でした。

オープニングキーノートのあと、Google の Mayer 氏による「In Search of… A better, faster, stronger Web」というタイトルで Google で行ったさまざまな施策について紹介。資料は、こちら

  • デフォルトの検索結果の表示件数が 10 件になっていることをあげて、30 件すると 0.9 秒かかってしまうのに対して 10 件の場合 0.4 秒で済む
  • Google Reader の高速化について紹介、高速化したことでアクティブユーザが増えた
  • Google の検索結果に表示される Google Checkout のアイコン表示の高速化について紹介、アイコンは画像ではなく table  タグで実現している(日本からアイコンが表示されない)、その結果 2% 表示スピードが向上した
  • Google News の高速化について紹介
  • Google Maps の高速化について紹介、12% のユーザは遅い接続だったことに注目して画像を圧縮してさらに、プログレッシブロードディングすることで 2-3 倍高速になった
  • Google が公開している高速化のための設計を紹介、Google Code で公開されている
  • 雑誌のようにウェブも素早く閲覧したい

講演が終わったあと、Mayer 氏のまわりはものすごい人だかりでした。

Performance Tools

さまざまなウェブ用のパフォーマンスツールがたくさん紹介された。PagetestHTTPWatchYSlowVRTAFirebug、と豪華な共演だった。

Pagetest は、URL を入力して接続元のロケーションを選択して、そのときのパフォーマンスをみることができる。無料で使えるので、使ってみたほうが分かりやすいと思う。

HTTPWatch は、IE と Firefox 向けのプラグインで、HTTP のさまざまな情報の閲覧(POST データなど)や、ネットワークレベルでのタイムチャート(DNS 解決にどのくら時間がかかったなど)を表示することができる。機能は、このページにまとまっている。ベーシック版は無料で使えることができて、プロフェッショナル版は有料になっている。それぞれの比較は、このページにまとまっている。

YSlow は、2.0 の新機能について紹介。

VRTA は、Visual Round Trip Analyzer の略で、ウェブのパフォーマンスを計測できる Windows アプリケーション。

Firebug は、これから登場する 1.4 について紹介。

World’s Simplest Latency Simulator

Aptimize のサービスについて紹介。

High Performance at Massive Scale – Lessons Learned at Facebook

Facebook の Johnson 氏による Facebook での貴重な体験を紹介。とても貴重な情報のためか、このセッションは立ち見がでるほどの大盛況ぶりだった。

  • Facebook のアーキテクチャーは、ロードバランサー、ウェブサーバ、Memcached サーバ、データベースサーバ、という構成
  • Memcahed サーバの比率がとても高いという印象をうけた
  • 学んだことのまとめとして、キャッシュはとても高速、似たデータは計算してなるべく同じサーバへ格納する、1台から4台くらいの小さなクラスターを使う、ということでした

なり抽象度が高い講演であったと思います、動画が公開してほしいセッションの一つです。

Drizzle: Scaling for the Clouds

Drizzle の講演でした。Drizzle の紹介についてでした。紹介中、Drizzle は C++ で書かれていますが、boost を使っていないか?という質問がありました。回答は、OSX で動作させたい、パッケージングが大変などの理由から使っていないということでした。

MySQL Performance from Day #1

Zawodny 氏の講演でした。第一日目の BOF でのフィードバックの内容でした。第一日目に BOF があったとは気がつきませんでした。。。

  • インデックスについて、多すぎるインデックスは自分を締めることになる
  • MySQL のクエリーキャッシュは使用しない
  • マルチコアの世界ではレプリケーションの問題が発生する、なぜならレプリケーションはシングルスレッドでやっているため
  • メモリを多く載せる
  • XtraDB あるいは MySQL 5.4 を使用することで、パフォーマンス向上が期待できる
  • 成長し続けるデータに対する計画をたける
  • よく発行されるクエリーや遅いクエリーに重点をおいてチューニングする

ほとんど第一日目の BOF からの内容だったので、BOF に参加していなかったので話が理解できなかったです。

Frontend Performance Engineering in Facebook

Facebook エンジニアの Wei 氏とJiang 氏による Facebook のおもにフロントエンドのパフォーマンス向上施策について紹介でした。

  • ajaxification という施策で、ページのロードスピードが 40-50% 向上した
  • Facebook のユーザは、ブラウザの戻る/進むボタンを多用して、3から4ページごとにホームに戻るという行動をとるユーザが多いとのこと
  • この特性を利用して、ページキャッシュを多用するようにしたところ、3 〜 4 倍高速になったとのこと
  • CSS Sprite Image を使っているが、すべてのイメージをまとめるのでなくて、ページごとによく組み合わせのあるイメージのみをまとめて、転送効率をよくしている

展開が速すぎてまとめきれなかったので、資料の公開が待ち遠しいセッションの一つです。

Creating Instant Response Time Predictions with neXpert

neXpert というツールの紹介。

  • neXpert は、Fiddler のプラグイン
  • Fiddler は、Windows アプリケーションで、サーバ/クライアント間のHTTP(s) のトラフィックのログをとることができるツール
  • Fiddler は、フリーウェア

Native CPU Performance in the Browser with Google Native Client

Google の chen 氏による Google Native Client の紹介。Google I/O 2009 でも紹介されていた技術ですね。

  • Native Client は、ウェブアプリケーション上で x86 のネイティブコード(C/C++など)が動作させることができる技術
  • object タグで指定して、拡張子は nexe になっていた
  • プロジェクトのゴールは、JavaScript と同じくらい安全にネイティブコードを動作させるとのこと

State of Performance

最後の講演として、Velocity の chairman であり、YSlow の作者でもある Google の Souders 氏によるパフォーマンスの状態についての講演。おもに Firebug, YSlow, Page Speed, HttpWatch, PageTest, VRTA, and neXpert などのウェブのパフォーマンスを計測することができるツールがたくさん登場してきたというまとめのみ。

次のエントリで、「写真で振り返る Velocity」と題して個人的な所感をまとめておこうと思います。

Tags:

Velocity 2009 Day 2

June 26th, 2009 by naoya | No Comments | Filed in day

Surviving the 2008 Elections
オープニングのあとの最初の講演。2008 年を通じて生き残った技術を紹介。資料は、こちら

  • MySQL 3.23 系を使っているところが多い、停止してまで移行できるよい理由がない
  • Proxy サーバとして、Apache 1.3 が使われはじめた
  • Memcached は 2006 年から使われて Facebook をはじめ 2008 年でさらに使われるようになった
  • Porxy サーバとしての Lighttpd、mod_magnet というリクエストをハンドリングモジュールにより使われるようになった(mod_magnet にMemcached のサポートが追加された)
  • ハードウェアの進化、10 dual Xeon から 6 quad Xeons まで進化した(6コア使ってみたい…)
  • NFS root がけっこう使われるとのこと
  • 少ないコストで、パフォーマンスをよくしている
  • 広告と地図の表示は遅いとのこと

Keynote – After Click

Facebook の   Jonathan 氏によるかなり貴重なプレゼン。資料は公開されていないが、動画が公開されている。ものすごい数字に鳥肌がたった。

  • 2004 年から 2008 年までの Facebook のおもな機能(NewsFeed など)を紹介
  • Facebook には、現在 2 億人のユーザがいる
  • オバマ大統領の演説時の CNN と共同で行った LiveFeed を紹介(オバマ大統領も Facebook に登録している)
  • Facebook の開発チームについて紹介、Facebook では開発、QA、テスト、というチームにわかれていなくてエンジニアが全部を担当している(Google と似ていると思った)、ただし機能ごと(アプリチームなど)がいるため、ときにはまとまって作業しているとのこと
  • Like というシンプルな機能を紹介、Like はユーザの News Feed に気にいったということを示すという単純なもの、この機能は初日に 4.1 百万、最初の週で 16.3 百万 、最初の月で39.6 百万、のユーザに使用されたとのこと、バックエンドは Memcached になっている
  • 先日リリースされた Username allocation (ユーザごとに独自の URL を設定できる機能)について紹介。この機能は 3 分で 20 万人、15 分で 50 万人、1時間で 1 百万のユーザが使った。この機能は、ものすごくロードテストされていて RRDtools で負荷状態などが数多く紹介されていた。
  • The only place success comes before work is the dictionary. で締めくくった

動画が公開されているので、もう一度チェックしてみようと思います。

The User and Business Impact of Server Delays, Additional Bytes, and HTTP Chunking in Web Search

Google によるサーバの遅延によりユーザとビジネスがうける影響について紹介。資料は、こちら。Google の Brutlag 氏は、Microsoft にいた経歴をもっている。

  • 実際にあったサーバの遅延による影響を紹介した、例えば 500ms 遅延が発生すると 1 ユーザあたり 1.2% の収入、1.0 のクリックが減ってしまうとのこと
  • ユーザがページを表示するまでのロード時間の中で、header タグの前後、広告を表示した後、のそれぞれのタイミングでわざと遅延を発生させて、任意のユーザで実験してみたところ、一番影響があったので header タグを表示した後のときのとこと
  • プログレッシブレンダリング(HTTP 1.1 のチャンク・エンコードを使って送信する)で実験してみたところ 4-18% 高速になってクリック率が 0.7% 上がった

これほど大きな影響があることは、本当に驚きました。

‘Next Web’ Challenges: It’s Still All About The End User Experience
keynote の新製品についての紹介。

Fixing Twitter: Improving the Performance and Scalability of the World’s Most Popular Micro-blogging Site
もっとも楽しみだった Twitter の Adams 氏の講演。Twitter について。成長スピードがすごいすぎて鳥肌がたってしまった。資料は、こちら

  • 2008 年は、752% 成長した、2009 年も成長中で 2008 年のグラフが分からなくなっている
  • モニタリングは、Flickr と同じで ganglia で多少カスタムしている(スライドに twitter の ganglia スクリーンショットが掲載されているが普通)
  • 死活監視は、質問ででたが Nagios でやっている
  • ひとことのプライマリキーが unsigned int(32bit) を超えた
  • Puppet や Chef などは、使ってから一ヶ月くらいたったばかり
  • Reviewboard として SVN pre-commit フックでコミットログに “reviewed” が含まれていないとき通知している
  • コミット内容は、メールで通知
  • Campfire を使っている
  • Apache と Mongrel の間に Varish を挟んでいる
  • Mongrel と MySQL の間に Memcached を挟んでいる
  • CPU を AMD から Xeon に変更したころで 30% 削減できた
  • Rails から Memcached を使っているが、そのライブラリを Native C gem + libmemcached に切替えたころで 50% ロードアベレージが減った
  • メッセージキューには、RabbitMQ を使っていたが重かったので、Scala で書かれた Kestrel を使っている
  • MySQL まわりでは、時間のかかっているクエリーを kill している(!)
  • status.twitter.com は、Tumblr でホスティングされている(へぇー)

2 Years Later, Loving and Hating the Cloud

Picnik.com の Huff 氏による Picnik.com は AWS を2年間使ってきた経験でよかったこと悪かったことを紹介。資料は、こちら

  • 柔軟性であることは、よかったことの一つ
  • Picnik.com は、写真編集サイトなのでデータそのもの寿命が短いのでストレージが落ちても無視している

Page Speed

PageSpeed の紹介。動画のみ公開されている。PageSpeed の紹介とデモ。

10+ Deploys Per Day: Dev and Ops Cooperation at Flickr

Flickr の Allspaw 氏と Hammond 氏の二人による Flickr での開発チームとオペレーションチームとの連携についての話。資料は、こちら

  • PuppetSystem Imager などによるインフラの自動化を行っている
  • バージョン管理システムを使っていて、どちらのチームの人もすべて中身をみることができる
  • ブラウザ上で一発でビルドできるようになっている
  • さらにそのままデプロイができるようになっている
  • デプロイしたあとは、IRC に、誰が?いつ?何を?デプロイしたのか通知される
  • Hudson を使っているっぽい
  • 小さく何度もデプロイする
  • 機能ごとに機能フラグをつけている
  • ブランチなどは切っていない、トランクのみで開発している
  • モニタリングには ganglia を使っていて、ページの上部にデプロイ日時を表示している
  • IRC には、ビルドログ、デプロイログ、アラート、を通知していて、さらに検索可能なようにしている(これは既知の話)
  • 文化として、お互いに尊敬しあうこと、No だけとは言わない、ものごとを隠さない、信頼する、失敗に対する健全な性格をもつ、避難を避ける、これは簡単なことでない

Scaling for the Expected and Unexpected
dealnews.com の Moon 氏による、サイトのキャパシティプランニングについての話。

  • dealnews.com で、8月にいっきに PV が上がった事例を紹介
  • キャッシュの基本について紹介(ページそのものだったり、クエリー結果だったり)
  • Varnish や Squid によるプロキシサーバを導入する
  • 読み込みに対しては、データをコピーする
  • 書き込みに対しては、データストレージを分離させる
  • どのくらいサイトの規模が大きくなるか、見積って決めること(実際とは違うことが多いが)
  • KeynoteGomez といったサービスを使う
  • サードパーティ製のコンテンツには、IFrame を使う

このセッションは、特段新しい情報を得ることができませんでした。

A Preview of MySpace’s Open-sourced Performance Tracker

MySpace.com のオープンソースのパフォーマンストラッカーの msfast というツールの紹介。

msfast は、IE 6 – 8 のプラグインで、おもに次の機能があるという紹介とそのデモを行った。ソーソコードは、Google Code で公開されています。

  • ページを表示したときのブラウザがページを描画するために CPU と メモリの使用量を表示
  • ページの表示のされかたをビジュアルに表示
  • 接続スピードが異なった場合のページの表示のされかたを見れる

Getting to Second Base With Your CDN

第二の CDN を導入するときの話。CDN を導入するときには、イメージや CSS などのスタティックコンテンツなものとドメインをわける方法、ページの一部を CDN に持たせる方法を紹介していた。

Migrating www.aol.com from a Proprietary Web Platform to Open Source

aol.com が行った旧システムからオープンソースを使ったシステムへ移行したときの事例を紹介。資料は、こちら

  • 新システムでは、Java、MySQL、talend、Apache、Tomcat、を採用した(アーキテクチャーは、下の図、資料から転載)
  • NetScaler というのは、このスイッチらしい
  • Front は Apache、Backend は Tomcat という普通な構成

Building OpenDNS Stats

OpenDNS の負荷対策などについて紹介。

  • OpenDNS は、1日 14 億回の DNS クエリーをさばいている
  • DB は、auto_increment はテーブルロックがかかるので、domain を SHA1 した値をプライマリキーとしている
  • 28GB の Memcached があるが、32 ビットと 64 ビットの両方が存在している
  • mysqld_safe に ulimit -n 600000 を設定している
  • MyISAM を使っている
  • MySQL 5.0.77-Percona を使っている(使っているところを始めて知った!) 12 台のハードディスクで、16GB メモリ table_cache=300000 を指定している(たぶん、1 DNS ごとに 1 テーブルだからだと思う)
  • OpenDNS は、Palo Alto にある

Percona MySQL を使っている事例が聞けてよかったです。

Machines or MegaWatts

Yahoo.com による貴重な Yahoo! のデータセンターというかトラックを紹介していた。資料が公開されていないので、公開が楽しみ。

Best I/O is No I/O

NetEdge の Mashraqi 氏によるもっともよい I/O について。この講演がもっとも英語が聞き取れなかった。かなりつらかった。

Load Balancing Roundup

Six Apart の Kasindorf 氏によるロードバランサーについて。おもに Perlbal の紹介だった。

夜の BOF に参加したがったが、言語の壁を勝手に感じて断念してしまった。

二日目以降は、iPhone で撮影する余裕がなかった。

Tags:

Velocity 2009 Day 1

June 24th, 2009 by naoya | No Comments | Filed in day

Velocity 2009 レポート – 第一日目 –

第2回となるオライリー主催の Velocity 2009 に参加してきました。今日は、第一日目ワークショップの日でした。

velocityconf_registration

カンファレンスへの登録は、セルフチェックイン式で事前にメールで送られてくる確認コードが必要です。確認コードを入力すると、受付の人から名前を呼ばれて参加証を含む登録カードをもらいますが、このときに ID が必要でした。運よくパスポートをホテルの部屋に預けなくて持参してきたのでパスポートを提示して無事参加証を受け取りました。

velocityconf_selfcheckin

参加証と一緒に Velocity のアジェンダと Linux Journal をもらいました。どうして Linux Journal なのか分かりませんが、おそらくアメリカには Web DB +Press のような本はないからのではないかと思いました。正直なところ高価かカンファレンスなので、豪華なものをもらえるのかなと思っていましたが、そうでもなかったですw。バッグとかほしかった。。。

velocityconf_badgets

第一日目で参加したカンファレンスの日程表は、次のとおりです。

Velocity 2009 Day 1 P.M. - Mon 22 Jun

まず、Death of a Web Server: Crisis in Caching に参加しました。

velocityconf_workshop1

この講演では、実際に隣で 1U サーバ(スペック:Intel Core2 Duo, 4GB RAM)で、車の検索サイトを動作させながら、実際にキャッシュを利用してそのパフォーマンスを計測するデモを行っていました。動作環境は、次のとおりでした。

  • OS: Micrsoft Windows 2008 Server
  • DB: Microsoft SQL Server 2005
  • プログラミング言語: ASP.NET

デモサイトへの負荷テストツールには、Microsoft Visual Studio Team 2008 を使って行っていて、そのときの秒間リクエスト数などのモニタリングには専用のパフォーマンスモニタを使用していました。数秒おきくらいで、秒間リクエストやメモリの使用量などをまとめて表示していたので便利そうなツールでした。

デモサイトの変更も Visual Studio で変更してからメニューから一発でデプロイしていたのも印象的でした。

キャッシュするよくあるデータベースの内容を対象にしていました。キャッシュする方法は、ASP.NET に含まれているキャッシュのライブラリで行っていたので、詳しく分かりませんでしたが、キャッシュごとにそのヒット率を集計するプログラムを自作しながらキャッシュがちゃんと使われているかというとても基本的なことを再確認させられる講演でした。

かなり、.NET 技術にフォーカスしていたので、すぐには使うことはないと思いますが、他の技術でも基本的なことはやはり同じだと再確認させられました。

海外のカンファレンスは初参加の初セッションでしたが、10分間の質問時間にもかかわらず時間をオーバーしてまで質問が出続けていたのは印象的でした。

続いて、Introduction to Managed Infrastructure with Puppet に参加しました。普段、愛用している Puppet の入門的な講演だったので、既知の内容がほとんどでしたが以外に知らないこともありました。

Puppet では、基本的に manifest と呼ばれるシステムの状態定義ファイルを Puppet の独自言語で書いて実行する必要がありますが、-e オプションを使うことでコマンドライン一発でも実行できます。例えば、次のような感じです。

$ puppet -e ‘file { “/tmp/foo”: ensure => present }’

notice: //File[/tmp/foo]/ensure: created

通常ユーザ権限で実行するときには、$HOME/.puppet/var ディレクトリを作成する必要があります。

noop オプションをつけると、実際にはシステムに適応しないで動作確認することができます。

$ puppet -e ‘file { “/tmp/foo”: ensure => present }’ –noop

notice: //File[/tmp/foo]/ensure: is absent, should be present (noop)

Puppet の設定の一部をみるときには、configprint オプションをつけます。

$ puppet –configprint modulepath

/Users/naoya/.puppet/modules:/usr/share/puppet/modules

test オプションをつけると、Puppet デーモンが起動している状態でもコマンドライン一発で puppet を起動することができます。

$ puppet –test

puppetmastered の certname は、実際にはサーバでためすときテストサーバを実際のサーバのホスト名を指定にすることで可能なようです。

あと、File リソースで filebucket を指定しておくと置き換える前のファイルを bucket へ保存することができるのですが、Puppet の作者でもログをみてバックアップファイルのファイル名のハッシュ値を手動で指定していたのには驚きました。やっぱり手動で設定するか方法はない様子です。

今回の資料はここに公開されていて、サンプルの manifest などは git でアクセスできます。

$ git clone git://github.com/reductivelabs/velocity_puppet_workshop_2009.git

このセミナーで偶然隣に座ってきた人が、Reductive Labs の Andrew Clay Shafer さんで、Luke Kanies 氏を紹介してくれました!

今回の講演は、Puppet 入門にかなりいいので日本語版を作って公開してよいか Andrew Clay Shafer 氏に確認したら問題なさそうなので作りたいと思います。

Hadoop Operations: Managing Big Data Clusters

Cloudera Inc. の Jeff Hammerbacher 氏による、Hadoop の概要から実際の運用まで幅広い内容をカバーした講演でした。同氏は、Cloudera Inc. を立ち上げる前には Facebook の 30 名近いデータチームにいたそうです。

おもに次の内容についての講演でした。

  • Hadoop の概要とサンプルケースについて
  • Cloudera と Hadoop について
  • クラスターに使用するハードウェアとソフトウェアについて
  • インストールと設定
  • HDFS(講演中は、HDFS についてかなり重点的に説明していました)
  • MapRedeuce
  • クラスターのライフサイクルとメンテナンスについて

同日のスライドは、ここに公開されています。スライドにかなり詳しい内容が書かれているのでかなり役に立ちそうです。

Scalable Internet Architectures

OmniTI の Theo Schlossnagle 氏によるウェブのアーキテクチャーに関する講演でした。同氏は、同名の本が発売されています。

正直なところスライドをめくるのが早くて、まとめることができなかったので、スライドが公開されたあとに振り返ってみようと思います。

Ignite Velocity

velocityconf_ignite

時間をあけて Ignite Velocity という BOF がありました。これは、20 スライドを自動的に 15 秒ずつ表示しての LT のようなものでした。
印象的に残ったのは、Yahoo! の人による Velocity の公式ホームページに使われている画像を GIF から PNG(ピンジーと発音していた) に変換してページの全体サイズを約 30% ほど削減することができたという話。
varinish についての話が印象的に残りました。このスライドは、ここに公開されています。

あと、ネット環境は San Jose ダウンタウンということで、ダウンタウンに Wifi、ホテルにも Wifi、会場にもホテルと Wifi 盛り沢山です。Wifi はほとんど解放されています。電源は、さすがに全員分といかないですが会場の端に用意されています。なので、セッションが始まるときには、電源まわりに集まってきますw。

P.S.
# 写真はすべて iPhone で撮影したものですが、デジイチで撮影した写真はデジイチと接続する USB ケーブルを忘れてしまったので、あとでアップ予定です。

Tags:

Velocity 2009

June 20th, 2009 by naoya | No Comments | Filed in day, emacs

Velocity 2009 に無事申し込んで、航空券とホテルの確保、はじめての一人渡米なので SFO から San Jose までの行き方を調べました。SFO から San Jose までは、Google Maps の道案内を信じて行ってみたいと思います。Velocity は高価だけあって、全日程のランチが含まれています。

さて、Velocity 2009 に参加するセッションを決めたので、紹介しておきます。

一日目 – 6/22(月)
一日目は、ワークショップの枠組で開催されます。
9:00am: Death of a Web Server: Crisis in Cashing

我々のウェブサーバ郡は、うまくいかなかったとき何が悪いのか教えてはくれない。このワークショップでは高負荷時にウェブサーバが落ちてしまったときの様子を見ることができるだろう。その負荷テストをライブでみることでサーバがあるステージで落ちてしまうのを見ることができるだおう。そして、どういうときに失敗するのかを明かにすることで解決の糸口が分かるだろう。例えば、コードを変更したとき、設定を変更したとき、ハードウェアを変更したときなど。このワークショップを通じて、もし「なぜウェブサイトはこんなにも重いのか」という質問に答えられるようになるだろう。

11:00am: Introduction to Managed Infrastructure with Puppet

Puppet は、Ruby で書かれている人気のあるオープンソースのサーバ管理ソリューションです。このワークショップでは、Puppet のインストール、いくかのサービスを管理する方法や Puppet を使ってシンプルに問題を解決できるデモを行います。

Puppet は普段から愛用していますので、このワークショップで Puppet を開発している Luke Kanies さんに会えるのがとても楽しみです。

1:45pm: Hadoop Operations: Managing Big Data Clusters

Hadoop と MapReduce は、蓄積されていて増え続けているログやセンサーデータ生成されたコンテンツやフィードなどの巨大なデータを処理することを可能にしてくれる。

Cluudera, Inc で、我々は世界中各地にある団体などで同じプロセス「プロダクション並列環境で小さな Hadoop クラスター上で研究プロジェクトを開始して、その上オペレーションチームにとって新しい負担になっていること」を目撃した。信頼できる管理するためのツールの数とスケーラブルな Hadoop のインストール方法は Hadoop の活気のあるユーザコミュニティによって提供されている。これらのコミュニティにはメジャーな貢献者である Yahoo! や Facebook や IBM 研究所が含まれている。
セッションを通じて、私たちが管理しているクラスターからの苦労話を共有できるだろう。それらは 10 から 1000 ノードにスケールした Hadoop での特別なコツやトリックである。詳細には次の内容をカバーしている。

  • クラスターのセットアップ:どうやって始めればよいか?安定版のバイナリはどこから見つければよいか?どうやって自分のシステムのイメージするか?どうやってマスターやスレーブや他の逸脱したトラックを保てばよいか?
  • モニタリングと通知:どうやったクラスターが問題なく動いていることを知ることができるか?Hadoop をモニターするツールには何を使うのが一番良いか?自分のクラスターでモニタリングシステムをスケールすることができる助けとなるコツは何か?
  • アップグレード:Hadoop はとても速いリリースサイクルをとっている。いつアップグレードするべきか?スムーズにアップグレードするには?ユーザにどのくらいのインパクトがあるか?
  • 最適化:100 台のサーバが 60 か 160 のどちらのパフォーマンスになっているか?それを知る方法は?50 のチューニングパラメータは何を意味するのか?

3:45pm: Scalable Internet Architectures

Scalble Internet Architectures という書籍を書いた Theo Schlossnagle 氏によるワークショップです。

伝統的なウェブアーキテクチャーの内部にどっぷり浸かりながら議論します。実際の生活アーキテクチャーを見てみると、弱点を見ることができ Digg や NYTimes や MSN のような大規模サイト(あるいはトラフィックが 30 秒間で 15 Mbps から 1 Gbps に跳ね上がったとき)で長期に渡って発覚した強烈な重荷として起こるであろうことを議論できるだろう。

フレンドリーな雰囲気で、ここ1年で実際に使ったできるさまざまな逸話や苦労話や良い悪いデザインやコツなどを楽しむことができるだろう。

8:00pm: Ignite Velocity

BOF みたいなもので LT のようです。すでに締め切っていますが、内容が公開されていません。

二日目 – 6/23(火)

午前中は、キーノートです。

8:30am: オープニングキーノートFacebook Keynote2 Years Later, Loving and Hating the CloudSurviving the 2008 Elections

Google の Steve Souders 氏と O’Reilly Rader & Opscode の Jesse Robbins 氏のとオープニングキーノート「ようこそ Velocity 2009 へ」。

続けて、Facebook のテクニカルオペレーションの副リーダーの Jonathan Heilgher 氏のキーノート。

そして、picnik.com でのクラウドを使った良い点と悪い点について。

最後に、dailykos.com の Jeremy Bingham 氏による MySQL の最適化、lighttpd を動かしてパフォーマンスを向上させるカスタムモジュールを lighttpd へ組み込む方法、など。

10:40am: Fixing Twitter など

twitter のパフォーマンス向上とそのスケーラビリティについての講演です。これはかなり興味深いです。

Twitter (twitter.com) は、「今何している?」という質問に答えているユーザたちのマイクロブログサービスです。それは単純な 140 文字の文字列(a tweet)で表現されていてユーザのフロー(あるいは友達)たちに伝えています。

数年を経て Twitter は数百万のユーザたちが使うサイトにスケールする挑戦を体験してきました。ROR をホスティングすることからたくさんのスケールする挑戦に出会い、コミュニティーと我々の体験を共有したいと思います。

次のトピックが含まれています。

  • ROR を本番環境で使うときのベストプラクティス
  • パフォーマンスにインパクトをあたえる制限の割合について
  • API が通常のウェブで使われると同じことができるときどうすればよいか
  • 非同期と同期処理について
  • なぜディスクは新しいテープなのか
  • キャッシュ手法と Twitter でのオープンソース効果
  • なぜデータベースはすべての問題に対するもっともよい解決方法ではないのか
  • メッセージキュー
  • Thrift を使った巨大なログのハンドリング
  • 弱点を見つけてはその問題を直してさらに次の弱点を見つけるその繰り返しでスケーリングを強化する

1:00pm: 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr

「先週、18 人によって 496 の変更が行われて 67 回のデプロイがされまいた」- Flickr 開発ブログ 2008/12/17。

新しいコードをデプロイするためにプロジェクトを計画したり、管理上のリスクを考えたり、開発とオペレーションとの間でのコミュニケーションと協調はもっとも重要なことです。ウェブインフラは成長してくると、システムとソフトウェアとの間はほとんどはっきりしなくなります。

よりよい Flickr の混在したルールはなぜどのようにできたのかについて話します。

大きな赤いデプロイボタン(Big Red Deploy Button)を健全に保つために有効なツールやテクニックや文化や伝統的なプロセスを議論しましょう。

個人的にもっとも楽しみなセッションの一つです。

1:45pm: Scaling for the Expected and Unexpected

たくさんの人たちとスケーリングとパフォーマンスについて話します。しかし、起こるすべてのことに対して準備できないでしょうか?それらはさまざまな問題を抱えていてそれを解決するソリューションは一つではありません。

すべてのことはよくなったり BAM(?) だったりします。あなたのサイトが Yahoo! のトップページからリンクされたとき何ができるでしょうか?どうやって突発的な大きなトラフィックを捌くことができますか?秒間リクエスト数が通常の5倍になります。サーバ群の CPU は急増します。デーモンは最大限まで稼働しています。回線帯域を越えてしまいます。どうやったこれからのことに対処することができますか?これからの突発的なことに対したどんなツールやテクニックがありますか?

あるいはあなたのサイトがみんなに発見されることは年々トラフィックが 70% から 80% に成長しておきます。これは1ヶ月で 100 万ページビューだったのが 2 年間で 300 万近くになるということです。どうやったこれらの計画を立てればよいでしょうか?2年間ごとにアーキテクチャーを再設計することおは望まないはずです。

それらのシナリオには銀の弾はありません、さまざまな状況を通じて手に入れた助けがたくさんのサイトで使われている技術があります。このセッションではこれらのいくつかの技術をカバーして準備などについて話します。

2:30pm: Infrastructure in the Cloud Era

Chef の作成者による講演です。

ウェブオペレーションは、その都度のメジャーなトレンドの最先端は常に動きつづけています。最近、急増しているのはインフラの全自動化です。素早く軽量な設備や統合された管理路線、ささいなアプリケーション開発です。

複数のオープンソースツール(ChefNanite や CouchDB や RabbitMQ など)を最大限に組わせるとテクニック同士の戦いがテストされます。アダムとイザベラはどのようにして管理を簡単にしたり、アプリケーションと融合したり、自身でドキュメントを作成したりするのを見ることができるでしょう。この道に沿っていけばビジネスに使えるこれからの技術から最大限の手助けを手に入れる必要性のヒントを与えられるでしょう。

講演者はこの世界でよく知られた二つの会社が来ます。Engine Yard は非常にすばらしい名声をもった独自の内部的なホスティングからクラウドへ移しました。Opscode はインフラの自動化をもたらしています。彼らは「Chef」を作成しました。「Chef」はスタートアップ向けにインフラの完全な自動化を構築する体験ができるツールです。

3:40pm: Migrating www.aol.com rom a Proprietary Web Platfrom to Open Source

aol.com でレガシーシステムをオープンソースを含んだ新しいアプリケーションスタックに置き換えたときに話です。アプリケーションアプリケーションの設計、スケーリングとキャパシティの計画、ツール、ネットワーク設計など。

4:25pm: 3本立てで Building OpenDNS Stats, Machines or MegaWatts, Best I/O is No I/O

45分なので、15分ずつのセッションのはずです。OpenDNS の状態について OpenDNS はバックエンドで MySQL と memcached を使っている、Yahoo! の人によるマシンの消費電力について、MySQL のデータをメモリにあわせてディスク I/O を減らす方法

5:30pm: Load Balancing Roudup

Six Apart の人によるいくつかあるロードバランサーのアルゴリズムについて。ラウンドロビンな L4 ロードバランサーから最小コネクションあるいは重み付けがあるちょっと賢い L4 ロードバランサーから L7 ロードバランサー、Perlbal まで。人気のあるオープンソースのロードバランサーの実装ついての話。

6:15pm: レセプション

最終日 – 6/24(水)

午前中はキーノートです。

8:30am: ようこそキーノート by Marissa Mayer (Google)パーフォマンスツール by Eric Goldsmith (AOL), Simon Perkins (Simtec Limited), Stoyan Stefanov (Yahoo! Inc), Jim Pierson (Microsoft), Jan Odvarko (Freelance)

オープニングキーノートは毎日あるんですね。それにしても朝早い。さすがはアメリカ。

Google の Marissa 氏のキーノートがあって驚きました。

パフォーマンスツールでは、AOL PageTest, HttpWatch, YSlow 2.0, and Visual Round Trip Analyzer などのツールについて紹介があるみたいです。

10:40am: World’s Simplest Latency Simulator

Aptimize ソフトウェアが世界中でもっともシンプルな潜在するシミュレーターを紹介します。オープンソースなブラウザに追加することによってネットワークの潜在効果をシミュレートすることができます。使うのは単純でとても簡単です。プロではない人向けにデザインされていて開発者やオペレーターや営業の人たちがインターネットごしあるいは WAN を通じてどのくらいウェブサイトが速いのか遅いのかすぐに見ることができます。

11:45am: The Rackspace Cloud

内容未定ですが、タイトルから推測するとクラウド環境下でのラックスペースについての講演でしょうか。

1:00pm: High Performance at Massive Scale – Lessons Learned at Facebook

この講演もとても楽しみです。Facebook による貴重な体験が聞ける講演です。

Facebook にあるデータは驚くべき割合で成長しています。毎日 50 万人以上の人々が新規登録していて、1億5000万の既存ユーザは驚く割合で新しいデータを追加し続けています。データに逆らって読み込み割合もまた増えています。5000万人以上のユーザによって1秒間に低遅延のランダムアクセスされています。これらの要求を満たすシステムを構築することはまったくもって挑戦であり、私はそこから学んだ教訓を共有したいと思います。

システムのコンポーネントで重大な問題があるものが一つ(SPOFのことだと思う)あってそれは memcached クラスターである。私はパフォーマンスを維持しながら信頼性のある成長したクラスターをもつ方法について議論したい、そして膨大なネットワークトラックを必要とするのと引換えに使われているテクニックがある。いくつかのテクニックはデータをクラスタリングしたようにアプリケーション層にあってアクセスのパターンを解析していたり、他のものはネットワーク帯域に動的に制限するようなシステムレベルで行われていたり、カーネルのネットワークスタックを変更しているものもある。

我々が巨大なコード基盤のある初期化のコストを減らす挑戦を PHP インタプリタで行った最適化、そして 100 TB のデータをもつ MySQL にスケールしたときに学んだ教訓も議論したい。

これからのトピックをすべて共通することは、さまざまな最適化に対する重大な議論することは、スケーリングとパフォーマンスの両面をもつだろう。

1:45pm: Improving Performance in Mature Web Apps, Beyond Gzipping

前半は WordPress による講演です。

WordPress オープンソースプロジェクトの歩みはたくさんの組み合わせでフロントエンドのパフォーマンスを増やしています。そのために何をして何をしなかったのか紹介します。

後半は Google による講演です

あなたのウェブブラウザ上で gzip 圧縮が有効になっているならば、ウェブサイトを加速させるとても一つもっとも簡単にそして高い効果がある方法があります。しかしながら、それをやっても訪問者の 15% は未だに圧縮されたレスポンスを受け取っていません。
このセッションは、なぜこのような問題が行ってこの問題についてできることについて取り上げます。

2:30pm: Fistful of Sand: Monitoring Code Performance at MySpace.com

myspace.com によるコードのパフォーマンスを監視する講演です。

3:40pm: Frontend Performance Engineering in Facebook

Facebook で我々はそれぞれのページの奥に機能やアプリケーションを組み込んでいます。そのような深い融合は、フロントエンドパフォーマンス技術にとって機会と挑戦の両方が存在しています。

4:24pm: Creating Instant Response Time Predictions with neXpert, Native CPU Performance in the Browser with Google Native Client, State of Performance

Microsoft と Google による講演です。

一つ目は、neXpert というツールの紹介です。neXpert とは、クラシックのウェブブラウザのチェックを自動的に行ってくれるウェブデバッカのプラグインで、キャプチャ結果をHTMLレポートとして生成します。

二つ目は、Google が開発した Native Client という技術の紹介です。

三つ目は、Velocity の中心人物である Steve Souders 氏の講演です。ウェブがなぜ遅いのかという根本的な問題に対する講演です。

5:30pm: High Performance Ads – Is It Possible?

そして最後の講演は、この講演です。ウェブ広告のパフォーマンス向上についての講演です。

広告はウェブのもっとも人気のあるたくさんのウェブサイトへもっとも優先順位の高い収入源として提供されています。そして、広告はウェブページを遅くしてしまうという評判をもっています。このプロフェッショナルによるパネルディスカッションではサイトに負荷がかかっているときの広告の影響を緩和するテクニックと体験について議論します。そして計測する標準的な方法の効果と広告のパフォーマンスを向上させる効果についても議論します。

ということで、インフラのカンファレンスとして盛りだくさんすぎる内容ですが、これらのセッションに参加する予定です。

それではいってきますー。(サイドバーにもブログパーツをはってみた)


Velocity, the Web Performance and Operations Conference 2009


Velocity, the Web Performance and Operations Conference 2009

Tags:

Xen on CentOS

June 19th, 2009 by naoya | 3 Comments | Filed in day

CentOS 5.3 x86_64 に Xen を導入するためのメモです。

1. 次のコマンドで Xen をインストールする
$ sudo yum install xen

2. Dom0 のメモリ容量を最低限に利用する(通常は 512MB あれば十分)
$ sudo vi /boot/gnub/grub.conf

18c18
<       kernel /xen.gz-2.6.18-128.1.6.el5 console=com1,vga com1=57600,8n1

>       kernel /xen.gz-2.6.18-128.1.6.el5 console=com1,vga com1=57600,8n1 dom0_mem=512M

3. 再起動して、Xen Kenel で起動する

4. free コマンドでメモリ容量が 512MB になっていることを確認する

$ free -m
total       used       free     shared    buffers     cached
Mem:         512        507          4          0         46        249
-/+ buffers/cache:      211        300
Swap:       8095          0       8095

5. 念のため、次のコマンドで Dom0 が起動していることを確認する

$ sudo /usr/sbin/xm list
Name                                      ID Mem(MiB) VCPUs State   Time(s)
Domain-0                                   0      512     4 r—–   2439.7

6. Dom0 で bonding しているときは、/etc/xen/xend-config.sxp を次のようになおしてから Dom0 を再起動する

(network-script ‘network-bridge-bonding bridge=xenbr0 netdev=bond0′)

ちなみに netdev を指定しないとブリッジ用のデバイス xenbr0 ができないので注意する。
この設定をすると Dom0 が起動したときに /etc/xen/scripts/network-bridge-bonding が実行される仕組みになっている。

/etc/xen/xend-config.sxp の network-bridge-bonding で指定できる変数の意味は、次のとおりです。
– brdige: 作られるブリッジのデバイス名(デフォルト xenbrX)
– netdev: ブリッジにつなぐ実デバイス(デフォルト eth0)

ここで Xen Dom0 のメモリ容量を変更すると、実際に搭載されている物理メモリの容量を見ることができないのか知りたい。知ることができれば、Xen DomU のメモリ容量などをあわせて使われていない物理メモリ容量を計算することができそう。

Xen の基本コマンド /usr/sbin/xm の使い方

ドメイン一覧を見る: xm list
ドメインOに戻る方法: Ctrl+]
ドメインUへ接続: xm console <仮想マシン名>

Xen DomU を削除する方法

コマンドはないなので、設定ファイルをイメージファイルを削除する(しかないと思う)。

sudo rm -f /etc/xen/仮想マシン名
sudo rm -f /var/lib/xen/images/仮想マシン名.img

DomU で内部専用の eth1 を作る

/etc/xen/仮想マシン名 の vif 行を、次のように変更する。

vif = [ “mac=00:16:3e:33:63:10,bridge=xenbr0″,”mac=00:16:3e:75:4a:51,bridge=virbr1″ ]

mac アドレスは、http://www.asahi-net.or.jp/~aa4t-nngk/codes/xenmacgen.py.txt にあるスクリプトを使用して生成すると便利、重複しないように注意する。

/etc/xen/xend-config.sxp の network-script を次のように変更する

(network-script ‘network-bridge-bonding-custom bridge=xenbr0 netdev=bond0′)

/etc/xen/scripts/network-bridge-bonding-custom を、次の内容でパーミッション 755 で作成する。

#!/bin/sh
dir=$(dirname $0)
libvirtbr=virbr1

# Some clean-up of iptables rules inserted by libvirtd.
iptables -D INPUT -i $libvirtbr -p udp -m udp –dport 53 -j ACCEPT &>/dev/null
iptables -D INPUT -i $libvirtbr -p tcp -m tcp –dport 53 -j ACCEPT &>/dev/null
iptables -D INPUT -i $libvirtbr -p udp -m udp –dport 67 -j ACCEPT &>/dev/null
iptables -D INPUT -i $libvirtbr -p tcp -m tcp –dport 67 -j ACCEPT &>/dev/null

${dir}/network-bridge-bonding “$@”

echo 0 >/proc/sys/net/ipv4/ip_forward

/etc/virnet/virnet1.xml を、次の内容で作成する。

virnet1

virtnet1 の設定を有効にする。

# virsh net-define /etc/virnet/virnet1.xml
# virsh net-autostart virnet1

“default” ブリッジ(virbr0)の自動起動を無効にする。

# virsh net-destroy default
# virsh net-autostart default –disable

マシン(Dom0)を再起動して、ifconfig して xenbr0 と virbr1 があることを確認する。

参考資料

Tags:

mod_log_rotate Tips

June 18th, 2009 by naoya | No Comments | Filed in day

先日、紹介した mod_log_rotate ですが、とあるサーバで次のような設定をしたところちゃんとアクセスログがまったく ローテートしなくなってしまいました。

CustomLog “logs/access_log.%Y%m%d%H%M” combined

LoadModule log_rotate_module modules/mod_log_rotate.so
RotateLogs On
RotateLogsLocalTime On
RotateInterval 60

この設定だと、/var/logs/ に1分間ごとにアクセスログが「access_log.年月日時日分」というファイル名で順番に出力されるはずなのですが、なぜか httpd を起動した時間のアクセスログに追記され続けていてアクセスログがローテートされません。

原因を調べてみると、/var/log/httpd のパーミッションに原因がありました。/var/log/httpd のパーミッションを見てみました。

$  sudo ls -l /var/log/

drwx—— 2 root   root     4096 Jun 18 16:47 httpd

他のディレクトリは省略していますが、httpd は root のみ書き込み権限があります。mod_log_rotate が出力するときの実行ユーザは Apache の子プロセスになるので apache ユーザになるので apache ユーザで書き込み権限があるディレクトリを指定する必要があります。

解決方法としては、次の二つ考えられます。

  1. Apache ユーザで書き込める別のディレクトリを設定する
  2. /var/log/httpd ディレクトリに Apache ユーザで書き込み権限を与える

試しに /tmp で指定すると、次のようなファイルでアクセスログが生成されました。

$ ls -l /tmp

-rw-r–r– 1 root   root   3.3K Jun 18 16:47 access_log.200906181647
-rw-r–r– 1 apache apache 3.4K Jun 18 16:48 access_log.200906181648
-rw-r–r– 1 apache apache 3.4K Jun 18 16:49 access_log.200906181649
-rw-r–r– 1 apache apache 3.4K Jun 18 16:50 access_log.200906181650

起動した直後のアクセスログは root ユーザによって作成されて、mod_log_rotate によってローテートされるアクセスログは apache ユーザによって作成されているのが分かりますね。

これで、Apache module は、apache ユーザになることが理解できてよかったです。

ちなみに mod_log_rotate は、最短で1分おきにアクセスログをローテートすることができます。ローテートする間隔は、RotateInterval で秒単位で指定します。

Tags:

Velocity 1

June 13th, 2009 by naoya | No Comments | Filed in day

Velocity に参加申し込みをしたわけだが、さっそく申し込み完了メールが来たので、内容を紹介しておく。

Dear Naoya Nakazawa,

You are now registered for Velocity 2009

Your confirmation code is XXXXXX — please bring this code
with you when checking in at the event.

===================
BECOME A FAN  OF VELOCITY CONFERENCE IN FACEBOOK
===================

Become a fan of the Velocity Facebook group to connect with
other attendees before, during and after the conference:
http://www.facebook.com/pages/OReilly-Velocity-Performance-Operations-Conference/10407279362

===================
FOLLOW VELOCITY ON TWITTER
===================

Follow Velocity on Twitter before, during and after the conference.
http://twitter.com/velocityconf

===================
JOIN THE VELOCITY LINKEDIN GROUP
===================
Join the Velocity LinkedIn group.
http://www.linkedin.com/groups?home=&gid=1303037

Facebook の Velocity グループあり、twitter あり、Linked あり、と Web 2.0 ならではのイベント案内メールでした。興味のある人は、それぞれ Join したり Follow したりすればいいと思います。Velocity に関する情報は Twitter の #velocityconf でもチェックすることができます。

Velocity on Twitter で知ったのですが、オライリーから「Complete Web Monitoring」という本が7月に出るそうなので予約しました!公式サイトは、ここみたいです。

この本は、ウェブサイトを運用するにあたって訪問者やパフォーマンスやコミュニティや競合サービスなどをチェックすることの重要さについて書かれている本です!

さて、次回は Velocity で参加するセッションを紹介します!!!

wget で保存先ディレクトリを指定する方法

June 7th, 2009 by naoya | No Comments | Filed in day

-P オプションを付けると、保存先ディレクトリを指定することができる。

$ wget http://example.com/hoge.tar.gz -P /tmp

Tags:

サーバを増やすということ

June 5th, 2009 by naoya | No Comments | Filed in day

サービスが成長していったり、内部的なバッチ処理などのために、サーバを増やすことはよくあります。もちろん、サーバ1台でできることには限界があって、サーバを増やすと限界を上がるのはあたりまえのことです。

先日、とある内部的なバッチ処理がかなり計算に時間がかかっており、サーバを増やすことが決定しました。担当者からは CPU は速いものがよいが、メモリやハードディスクは普通くらいで2台くらいあればいいでしょう。という話だったのだが、なぜか社長からでは多めに3台という話になって驚いた。個人的には、2台でいいと言っていているのになぜ3台になるのかがとてもとても不思議。本当に3台必要なんでしょうか?と。(嫌味を込めていうと、お金があっていいですねー、そんなお金があったら給料上げてくださいと言いたいわー。)

これはちょうど、どこかのカンファレンスかインフラが大好きな仲間に聞いた話とそっくりだったことを思い出した。The Art of Capacity Planning にも書いてあったけれど、ちゃんとサーバの増設スケジュールや見積りをするのは大事だと思う。2台必要?じゃあ、3台じゃなくて。どんな問題をどのように解決するので、2台必要という話が普通だと思う。さらに言えば、技術を駆使することで2台が1台で充分になる可能性だったあると思う。それが僕の仕事だと思っているし、サーバを増やせばなんとかなると思われてしまうと、サーバインフラエンジニアの僕の価値なんてないんだなぁとちょっと凹んでしまう。

もし、僕の駆使した技術でサーバの本来のパフォーマンスをちゃんと引き出して、サーバ3台必要だった処理がまったく同じ処理時間で1台で賄えるようになったら、特別ボーナスで購入する予定だったサーバ2台分のお金を僕に払ってほしいと思う(まぁ冗談だけれど。。。)。それが僕の価値ないのではないかなと思う。

サーバという機械さえ買えば、いくらでもサービスがスケールするとか問題がすぐに解決すると思っているのはちょっとおかしいと思う。それが自分の専門外の分野であったなら、なおさら慎重に検討して専門のエンジニアにちゃんと聞くべきだと思う。

もし、どんなレベルのサーバインフラエンジニアでぶっちゃけ誰でもいいと思っているのなら、そこに僕がいる価値はまったくないし、むしろいたくもない。正直なところ僕が担当しているインフラのサービスはあんまり成長していないけれど、ここまでできる人はそんなにいないと勝手に自負しているけれど、もしかして誰にでもできることしかできていないっていうことかもしれないけれど。

自分をちゃんと評価してくれて、自分もテンション AGE AGE でやれる環境を探す旅に出るときが来たと思った、今朝の出来事でした。

やばい、かなり愚痴まじりのネガティブなエントリになってしまった。

次回からは、そんな環境は気にせずにサーバ/インフラレベルを高めていくエントリをしていく所存です。

Tags:

PassengerHighPerformance

June 1st, 2009 by naoya | No Comments | Filed in day

passenger を使っていて今まで知らなかったのですが、PassengerHighPerformance の設定があります。以下、意訳です。

デフォルトでは Phusion Passenger は mod_rewrite とほとんどの Apache モジュールとの互換性をもっっています。しかしながら、この互換性によって影響も少なくありません。もし PassengerHighPerformace を on にすると Phusion Passenger はすこし早く高速になるかわりに他の Apache モジュールとの互換性がなくなってしまうかもしません。

PassengerHighPerformance をオンにした箇所では、mod_rewrite ルールは正しく動作しないかもしないかもしれません。mod_autoindex も動作しないでしょう。他の Apache モジュールも動作しないかもしれません。テストをしながらこの設定をすることをおすすめします。

PassengerHighPerformance を設定できる箇所はグローバルなサーバ設定、Virtual Host 設定、Directory や Loaction ディレクティブ内、.htaccess です。

デフォルトでは off です。

けっこう影響がありそうなパラメータなので、必要な VirtualHost の中に設定を書くのがよさそうです。

どのくらい効果があるかテスト環境で動作確認して問題なかったので、パフォーマンスを計測した。ベンチマーク方法は、REE benchmark と同じ方法で行った。

まず、PassengerHighPerformane off のとき(念のため、明示的に VirtualHost ディレクティブで off を設定した)

Concurrency Level:      12
Time taken for tests:   14.426 seconds
Complete requests:      20000
Failed requests:        10801
(Connect: 0, Receive: 0, Length: 10801, Exceptions: 0)
Write errors:           0
Total transferred:      10646548 bytes
HTML transferred:       3946548 bytes
Requests per second:    1386.40 [#/sec] (mean)
Time per request:       8.656 [ms] (mean)
Time per request:       0.721 [ms] (mean, across all concurrent requests)
Transfer rate:          720.72 [Kbytes/sec] received

次に PassengerHighPerformance on のとき

Concurrency Level:      12
Time taken for tests:   13.690 seconds
Complete requests:      20000
Failed requests:        19398
(Connect: 0, Receive: 0, Length: 19398, Exceptions: 0)
Write errors:           0
Total transferred:      10646756 bytes
HTML transferred:       3946756 bytes
Requests per second:    1460.90 [#/sec] (mean)
Time per request:       8.214 [ms] (mean)
Time per request:       0.685 [ms] (mean, across all concurrent requests)
Transfer rate:          759.46 [Kbytes/sec] received

それほど多くは変わらないという印象だけれど、気持ち高速になったので設定して本番環境へ入れることにした。

Tags: