Taobaoが公開しているnginxベースのWebサーバ Tengine の health check 機能 を試す - blog.nomadscafe.jp
Tengineはアジア最大級のECサイト「淘宝網」が公開しているWebサーバです。 The Tengine Web Server alibaba/tengine Nginxをベースにいくつかの機能拡張を行い、また開発も続いていて最新のstableバージョンに追従しているようです。 主な機能拡張は上記のサイトにも上がっていますが、興味があるところを上げると、 nginx-1.6.2をベース。nginxと100%互換性がある ダイナミックなモジュールの読み込みをサポート。モジュールの追加にTengineの再ビルドが必要ない SO_REUSEPORT をサポート。接続がnginxの3倍高速化 SPDY v3をサポート upstreamの負荷分散方式の追加。consistent hashやsticky session、upstreamのヘルスチェック、リクエスト処理中のホスト名の名前解決 acce
「Webエンジニアが知っておきたいインフラの基本」はぜひこの冬休みにWebエンジニア・ディレクタに読んでみて欲しい一冊 - blog.nomadscafe.jp
サーバの監視やモニタリングなどのサービス・ソリューションを提供するMSP(マネージメントサービスプロバイダ)のハートビーツの馬場さんが「Webエンジニアが知っておきたいインフラの基本」という本を出版されました。 献本頂きありがとうございます！！ 冬休みは実家に帰ったり、旅行に行ったりと何かとイベント事が多くなかなか本を読む時間が取れなかったり、年が明ければ弟妹・甥っ子姪っ子にお年玉を上げないとならず、自由に使えるお金も減ってしまうかもしれません。なので、読んでみて欲しい本が何冊もあっても困ってしまいますね。そこで自分がお勧めしたいのが、この一冊「Webエンジニアが知っておきたいインフラの基本」です。 本屋に行く時間がない方も安心。電子版があります Webエンジニアが知っておきたいインフラの基本 インフラの設計から構成、監視、チューニングまで【委託】 - 達人出版会 http://tatsu
Unicornの2倍のパフォーマンスを実現したRackサーバ「Rhebok」をリリースしました - blog.nomadscafe.jp
“Hello World”なベンチマークでUnicornに比べ2倍高速に動作するRackサーバをリリースしました。 rubygems: http://rubygems.org/gems/rhebok github: https://github.com/kazeburo/rhebok PerlのGazelleをベースに作っています。Rackアプリケーションの運用経験がほぼないので、機能不足があると思います。issue等で教えて頂ければ幸いです。 なぜ高速に動作するアプリケーションサーバが必要なのか Unicornは高速に動作します。多くのアプリケーションにとっては十分でしょう。それでもRhebokでさらに上のパフォーマンスを出そうとしたのは、技術的なチャレンジの他に以下のようなアプリケーションで高速なアプリケーションサーバが必要とされると考えているからです。 ソーシャルゲーム、広告サーバ、
Gazelle: new Simple and Fast Plack Handler for Performance Freaks - blog.nomadscafe.jp
Gazelle という新しいPlack::Handler(Server)をリリースしました https://metacpan.org/release/Gazelle 前のISUCONの結果報告で「Chobi」として紹介していたものを名前を変更しました。 GazelleはnginxやApacheでreverse proxyを行うことを前提に書かれたPlack::Handlerです。nginxの後ろにunix domain socketを利用して配置した場合、”Hello World”のベンチマークで、Starmanの3倍、Starletの1.7倍程度高速に動作します。 一番左はnginxで静的ファイルを配信した場合のQPSです ベンチマークの詳細はこちら↓です https://github.com/kazeburo/Gazelle/wiki/Benchmark 特徴など Gazelleは以下
YAPC::Asia Tokyo 2014 で LT と、Docker についての発表をしてきました - blog.nomadscafe.jp
うしろのばやしさんにラーメンと一緒に飲み込まれてしまった感がありますが、PSGI/Plackのパフォ厨としては、どうしても現状を報告しておきたい内容でありました。unicornに勝ちたい！！ 2日目の朝イチというコマでありましたが、大勢の方に見に来て頂いて驚きました。前半の内容を盛り込みすぎて時間が足りなくなってしまい、すみませんでした。アンケートで既にDockerを使っている方が凄く多かったので、インストールの部分とかは飛ばしてもよかったんじゃないかと思いましたが、Dockerを使う上で少しでも役に立てば幸いです。 ベストトーク賞 うずらさんのPHP発表は内容面白かったし、喋りはうまいし、スライドも作り込んであってさすがという感じでした。ベンチマークで自分がLTで紹介したオプションを使って頂いて嬉しかった。時代はPHP その他のトークではgugodの「One layer down bel
Heroku上でProcletを使っていろいろ動かすと便利 - blog.nomadscafe.jp
最近、Module::CoreListのWebUIと、perl-buildで使っているperlのリリースとアーカイブのリストの生成をHerokuに移動しました。両方とも、情報を更新するworkerとappサーバが必要になるので、Heroku上でProcletを使ってappサーバとworkerなどを動かしてみました。 HerokuでのProcletの使い方 まず、cpanfileとProcfileを用意します。 $ cat cpanfile requires 'HTTP::Tiny','0.043'; requires 'Getopt::Long'; requires 'Proclet'; requires 'Plack'; requires 'Starlet'; $ cat Procfile web: ./server.pl --port $PORT Procfileに書くのは1つだけです
GitHubとDocker HubのAutomated Buildを組み合わせてGrowthForecastのDocker imageの作成を自動化したハナシ - blog.nomadscafe.jp
タイトルがそのままですが、GrowthForecastのDocker imageを作りました。 https://registry.hub.docker.com/u/kazeburo/growthforecast/ 使い方は単純に起動するだけなら次のようになります。 $ docker run -p 5125:5125 kazeburo/growthforecast これだと、データが永続化されないので、適当なボリュームをマウントします。 $ docker run -p 5125:5125 -v /host/data:/var/lib/growthforecast kazeburo/growthforecast 起動オプションを変更したい場合は、コマンドを渡すか、Dockerfileを書いてビルドすると良いでしょう。 $ docker run -p 5125:5125 -v /host/dat
VagrantのVMを使い捨てる。vagrant-destroy-provisionerをリリースしました - blog.nomadscafe.jp
最近、Vagrantのprovisionerを使ってパッケージの作成などをいくつか行っているのですが、その際にVMを落とし忘れ、ホストしてるマシンの余計なリソースを使ってしまっていることがあります。 なので、provisionerでサーバをdestroy/haltするやつを書いてみました。 rubygems: https://rubygems.org/gems/vagrant-destroy-provisioner github: https://github.com/kazeburo/vagrant-destroy-provisioner 勝手にshutdownしてイメージを破棄するデモ動画です。 インストールはvagrant pluginコマンドから行います。 $ vagrant plugin install vagrant-destroy-provisioner 使い方はこんな感じ
plenvやxbuildで使っているperl-buildを信頼性の向上目指してアップデートしました - blog.nomadscafe.jp
plenvやxbuildで使っているperl-buildなのですが、ひろむ氏からコミット権限頂いてアップデートをしました。 変更点としてはいつでも使えるように search.cpan.org への依存度を減らしたことと、だれでも同じように作業ができるよう依存モジュールを1つのスクリプトにまとめるfatpackにDockerを導入して自動化した点です。 search.cpan.org への依存度の削減 perl-buildはperlのバージョンを引数に渡してインストールを行います。 $ perl-build 5.20.0 /opt/perl-5.20 この際に、渡されたperlのバージョンからアーカイブのパスを調べる必要があります。アーカイブのパスとは以下のようなものです R/RJ/RJBS/perl-5.21.0.tar.gz R/RJ/RJBS/perl-5.20.0.tar.gz R/
dstat + fluentd + Graphite + Grafana でサーバモニタリングする - blog.nomadscafe.jp
ES + kibanaでサーバモニタリングをやってみたのですが、ESのCPU負荷がかなり高くて、リアルタイムにモニタリングできない状況だったので、graphite + grafanaにしてみた。ちなみに、ESのサーバのCPU負荷はこんな感じ。 GrafanaはGraphite用のDash boardを作るツール。最近、influxDBにも対応していてなかなか野心的。 Grafana - Graphite Dashboard kibanaをforkしただけあって、画面はそっくり。まだ修正もれがあるのか、メッセージにkibanaって文字がでてくることもある セットアップ もろもろのセットアップのメモ 監視サーバ まず、監視サーバにGraphiteとGrafanaをいれる。環境はCentOS6 CentOS6.x - CentOSにRPMでGraphite+Diamondをインストールする -
dstat + fluentd + Elasticsearch + kibana でサーバモニタリングする - blog.nomadscafe.jp
普段はサーバのメトリクス可視化のためにcloudforecastを使っていますが、某案件用に数秒単位で数十台のサーバのメトリクスを表示したいので、記事タイトルのような構成を作ってみた。 dstatでとった各種値の他に、nginxとmemcachedの情報も合わせて表示させています。 セットアップ もろもろのセットアップのメモ 監視サーバ まず、監視サーバにElasticsearchとkibanaをいれる。環境はCentOS6 $ sudo yum install java-1.7.0-openjdk $ sudo rpm -Uvh https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-1.x.x.noarch.rpm Elasticsearchは特に設定なく起動 $ sudo service
CentOS 6.5にDockerいれてGrowthForecastを動かしてみた - blog.nomadscafe.jp
ちょっとずつ試してる。環境は以下。 MacOS X 10.8 VirtualBox 4.3.2 Vagrant 1.3.5 Packer v0.4.0 packer でCentOS6.5のイメージを作る まず、packerを使ってCentOS 6.5のイメージを作るところから。テンプレートはgithubにあげてます。 $ git clone https://github.com/kazeburo/my_packer.git $ cd my_packer $ packer build centos6.5.json テンプレートは https://github.com/hnakamur/my-packer-template-files を参考にさせて頂きました。 このあとの作業が楽になるようにCentOS 6.5をインストールしたあとに、yum groupinstall "Developmen
Released GrowthForecast-0.80. ドキュメントページの英語化 - blog.nomadscafe.jp
GrowthForecastのバージョン0.80をリリースしました。 インストールはCPANもしくはgithubから https://metacpan.org/release/GrowthForecast https://github.com/kazeburo/GrowthForecast 主な変更点 変更点は以下の通りです。 bootstrap 3 にアップグレーとして見た目が変わった (kazeburo) グラフリストの折り畳み (kazeburo, dalyfolowerさん) mysqlを使った場合のdefault valueの扱い (oranieさん,sonotsさん) exportへのstepとcf (統合巻数) オプションの追加 (anoworlさん) 参考 -> http://qiita.com/anoworl/items/63a2d8d33cab077e729b unix
HRForecast - もうひとつのデータビジュアライズツール - blog.nomadscafe.jp
ずいぶん前から作って動かしてはいるのですが、GrowthForecastの他にもうひとつのグラフ作成ツールを公開しています。 https://github.com/kazeburo/HRForecast デイリーで更新される数値のビジュアライズに使う事が出来ます。GrowthForecastにはない過去データの登録もできます。 モリスさんのスライドでも少し登場しています。弊社では主にHiveでの集計の書き出し先として使っています http://www.slideshare.net/tagomoris/log-analysis-with-hadoop-in-livedoor-2013 画面はこんな感じ 他のページにembedするHTMLの発行やCSVでダウンロードをサポートしています データの登録APIについて データの登録は、GrowthForecastと同じようにURIに対してPOSTリ
YAPC::Asia 2013 Tokyo で PSGI/Plack サーバの高速化について発表してきました - blog.nomadscafe.jp
livedoorBlogのPlack/Starlet化を背景として、この半年間ぐらいの間、PlackやStarletの高速化に取り組んできました。この発表はその中で学んだPSGI/Plackの基本仕様、PSGIサーバの構築の方法と最適化、PSGIサーバの選び方、またMonocerosについて紹介しました。 多くのWebアプリケーションではこの最適化の恩恵を受ける事はないかもしれません。しかし、アプリケーションが動作する基盤がどのように実装され、最適化のテクニックが施されているかを知る事により、アプリケーション層の最適化がより捗るのではないかと思います。 質問等があれば気軽に、コメントやtwitterでメッセージを下さいませ。 1日目のトークでは、tokuhiromのFuture Perlの話。新しい構文や正規表現やpfjのexobrainなど、が気になりました。 あと、前夜祭のLT-Tho
G-WANはなぜ速いのか？をnginxと比べながら検証してみた - blog.nomadscafe.jp
ツチノコブログのWEBサーバベンチマークツール比較の記事で紹介されていた。WebサーバのG-WAN。この記事によると凄く速いようです。 Intel Xeon E5-2640 (6コア/12スレッド 2.50GHz) を2つというサーバで gwan 334944 req/s nginx 111842 req/s と、速いと言われているnginxの3倍の速度を出しています。 このベンチマーク結果がとても気になったので、なぜG-WANが速いのか、自分でも検証してみました。 結論から言うと以下の2つ。 1) G-WANはデフォルトで物理CPUに合わせた数のスレッドを起動する 2) HTMLファイルも一度読み込んでキャッシュする という事です。 今回はAWSのcc2.8xlarge(E5-2670 8コア/16スレッド 2.60GHz *2)を使ってベンチマークを行いました。OSはAmazon L
Starlet が HTTP/1.1 に対応しました / wrkによるベンチマークとYAPC::Asiaのトーク宣伝 - blog.nomadscafe.jp
Starlet が HTTP/1.1 に対応しました。これによりでnginxのupstream keepaliveなどが捗ると思われます https://metacpan.org/release/Starlet https://github.com/kazuho/Starlet ながらくStarletはHTTP/1.0 + keepaliveなサーバでしたが、version 0.20にてHTTP/1.1に対応しました。具体的に対応したスペックは以下。 HTTP/1.1 keepalive Transfer-Encoding: chunked (Request & Response) Expect HTTP Pipelining StarmanやMonocerosとだいたい同じ動きをするようになっていると思われます。 なお、導入にあたっては、リバースプロキシ等と組み合わせた場合の動作パターン
YAPC::Asia Tokyo 2013 にて「PSGI/Plack・Monocerosで学ぶハイパフォーマンスWebアプリケーションサーバの作り方」というはなしをします #yapcasia - blog.nomadscafe.jp
YAPC::Asia Tokyo 2013 にて「PSGI/Plack・Monocerosで学ぶハイパフォーマンスWebアプリケーションサーバの作り方」というはなしをします。 トークの内容は 先日、MonocerosというPlack::Handler(サーバ)をリリースしました。MonocerosはStarmanやStarletと同じくPrefork型ですが、AnyEventを使い、C10Kのような多数のコネクションを捌くことができる特徴を持ち、非常に高いパフォーマンスを備えています。 このセッションではStarmanやStarlet、Twiggyといった各Plack::Handlerの内部構成の簡単な紹介、Monocerosを実装する上で学んだPlack::Handlerの構成や作成方法から、forkやUNIXプロセス、Linux TCPの話を交えて、高性能なWebアプリケーションサーバ
PSGI/Plackアプリケーションの起動方法いろいろと本番環境アレコレ - blog.nomadscafe.jp
PSGI/Plack/PSGIアプリケーションを動かす時に一番使われているのは plackup でしょう。 $ cat app.psgi use Plack::Builder; use MyApp; my $app = MyApp->psgi_app; builder { enable 'ServerStatus::Lite', => ..; $app; }; $ plackup -E production -s Starlet --max-workers 30 --port 5000 -a app.psgi plackup コマンドの -s にハンドラ名を指定して起動します。本番環境では -E や $ENV{PLACK_ENV} を指定してStackTraceやLintといった開発に便利なPlack::Middlewareが追加されないようにする必要がありますね。 Starmanの場合は
Monoceros が HTTP/1.1に対応しました & nginx と組み合わせたベンチマーク - blog.nomadscafe.jp
C10K対応Prefork型高速PSGI/Plackサーバの Monoceros をHTTP/1.1に対応させました。 https://metacpan.org/release/Monoceros https://github.com/kazeburo/Monoceros MonocerosではHTTPのKeepAliveに対応して、大量の接続を捌く事ができますが、リリース時点ではHTTP/1.0 KeepAliveにしか対応していませんでした。しかし、nginxのupsream などでは、keepaliveを有効にしてHTTPセッションを使い回したい場合にHTTP/1.1が求められます。 以前このあたりの事をしらべてblog書いています nginx-1.1.x で httpなupstreamにもkeepaliveができるようになったので検証してみた https://blog.nomads
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
