PHP BLT#1でLTしてきました - blog.nomadscafe.jp
PHPの勉強会なので、いままでお会いしたことのない方とお話ができてよかったです。 発表内容は大きくなってしまったmaster.phpファイルをどうやって高速に読むかというお話です。PHPではリクエストの終了とともに全てのメモリを捨ててしまうので、変わらないデータもリクエストの度にキャッシュからロードしなくてはいけません。大きなphpファイルがあれば当然毎回の読み込みがオーバーヘッドとなってきます。そんな環境でどうやってアプリケーションのパフォーマンスをあげていったのかを紹介しています。 スライドの中でfile sizeを小さくする必要があると書きましたが、@hnwさんによると、VM命令が多過ぎるのが問題で、構造を簡単にしたことでVM命令が減ったのがよかったのではとのことでした。非常に参考になりました。ありがとうございました \n\n\nPHPの勉強会なので、いままでお会いしたことのない方と
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
Docker と SO_REUSEPORT を組み合わせてコンテナのHot Deployにチャレンジ - blog.nomadscafe.jp
「Docker と SO_REUSEPORT を組み合わせてみる。おそらくその1」のその2です。 結論から言うと、「単体ではリクエストの取りこぼしが若干あるけど、Reverse Proxyを工夫すればコンテナのHot Deployを実現できるかも」という感じです。 Rhebok の SO_REUSEPORT 対応 前回は簡単に検証するためにmemcachedを使いましたが、今回はアプリケーションサーバが対象ということで、 unicornの2倍ぐらい速いRackサーバであるRhebokに手をいれてSO_REUSEPORT対応しました。version 0.2.3〜です。 rhebok | RubyGems.org | your community gem host 起動時に ReusePort オプションを追加します。 $ bundle exec rackup -Ilib -s Rhebok
Docker と SO_REUSEPORT を組み合わせてみる。おそらくその1 - blog.nomadscafe.jp
SO_REUSEPORTはLinux Kernel 3.9からサポートされている機能で、複数のプロセス/Listenerから同じTCPポートをbind可能にして、Kernelが それぞれのプロセスに接続を分散してくれるという機能です。preforkなサーバはlistenしてからworkerをforkし、それぞれでacceptを行うという手順を踏みますが、SO_REUSEPORTを使えばその手順を踏まなくても複数プロセスから同じポートをListenして処理の並列性をあげたり、hot-depolyが実現できます。 Docker のHost networking機能とSO_REUSEPORTを使って、複数のコンテナから同じポートをbindできれば、コンテナのhot-deployができるんじゃないかと思ったので、試してみました。 SO_REUSEPORTについては以下のblogが参考になります。
「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でさらに上のパフォーマンスを出そうとしたのは、技術的なチャレンジの他に以下のようなアプリケーションで高速なアプリケーションサーバが必要とされると考えているからです。 ソーシャルゲーム、広告サーバ、
blog.nomadscafe.jp
PHPの勉強会なので、いままでお会いしたことのない方とお話ができてよかったです。 発表内容は大きくなってしまったmaster.phpファイルをどうやって高速に読むかというお話です。PHPではリクエストの終了とともに全てのメモリを捨ててしまうので、変わらないデータもリクエストの度にキャッシュからロードしなくてはいけません。大きなphpファイルがあれば当然毎回の読み込みがオーバーヘッドとなってきます。そんな環境でどうやってアプリケーションのパフォーマンスをあげていったのかを紹介しています。 スライドの中でfile sizeを小さくする必要があると書きましたが、@hnwさんによると、VM命令が多過ぎるのが問題で、構造を簡単にしたことでVM命令が減ったのがよかったのではとのことでした。非常に参考になりました。ありがとうございました そろそろ傷が癒えてきた。。 ISUCON5の本選にメルカリのインフ
「ISUCONで学ぶ Webアプリケーションのパフォーマンス向上のコツ 実践編 完全版」を公開しました - blog.nomadscafe.jp
昨日のエントリで紹介した「Webアプリケーションの パフォーマンス向上のコツ 実践編」ですが、いくつかスライドを追加して、「完全版」として公開しました。 ISUCONだけに限らず、一般的なWebアプリケーション、SQLのチューニングの参考となる資料となっていると思いますので、見て頂けたら嬉しいです。 ＜追記＞ ISUCON4 オンライン予選の参加登録が開始されています！！！Webアプリケーションを書いている方もインフラを扱っているエンジニアも運用エンジニアも、ぜひチャレンジしてください！！私もでます！！ 参加はこちらから↓↓↓↓ ISUCON4 オンライン予選の参加登録を開始しました \n\n\nISUCONだけに限らず、一般的なWebアプリケーション、SQLのチューニングの参考となる資料となっていると思いますので、見て頂けたら嬉しいです。\n\n## ＜追記＞\n\nISUCON4 オン
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
Q4Mを簡単に導入する方法 for MySQL 5.6 - blog.nomadscafe.jp
以前、「Q4Mを簡単に導入する方法 - MySQL Casual Advent Calendar 2011」で紹介したQ4M専用MySQLのセットアップスクリプトのMySQL5.6対応版を作りました。 kamipo先生によると、プラグインをあとからビルドしてMySQLに追加する事は推奨されていないとのことなので、Q4MのソースコードをMySQLのソースコードツリーにコピーしてから一緒にビルドします。これは同じくkamipo先生のmysql-buildを参考にさせて頂きました。 #!/bin/sh set -e MYVER=5.6.15 Q4MVER=0.9.11 CDIR=$(cd $(dirname $0) && pwd) cd /usr/local/src if [ -f $CDIR/mysql-$MYVER.tar.gz ]; then cp $CDIR/mysql-$MYVER.t
一時ファイルとdentry cacheとメモリ - blog.nomadscafe.jp
わりと長い間悩んでいたんだけど、最近解決したのでメモ。 サービスで利用しているsmalllightの画像変換サーバが、Apacheが使っているメモリ以上のメモリを使用し、Swapしたりメモリ枯渇でサーバがダウンするなどのことが何度かありました。 ↑メモリの動きはこんな感じ いろいろ調べた結果「dentry cache」なるものがメモリ多くを占めていることがわかりました。dentry cacheはディレクトリやファイル名とinodeとを結びつけに使われるキャッシュです。smalllightでは画像を変換する際に一時ファイルを作成するので、その情報が残るようです。 手元で再現させる 本番で使っているサーバはCentOS5系ですが、手元のVagrant上のCentOS6(ファイルシステムはext4)で、再現させてみました。 use Parallel::Prefork; use File::Tem
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
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
HTTP/1.1 の Transfer-Encoding: chunked をビジュアライズするツール書いてみた - blog.nomadscafe.jp
Chunked Transferとは 一般にHTTP KeepAliveを利用するには、レスポンスのボディがどこで終わり、次のレスポンスがどこから始まるかをクライアントが知る必要があります、そのためHTTP/1.0ではKeepAliveを行う為にボディの長さをContent-Lengthをヘッダに入れなければなりませんでしたが、サイズを測るためにデータをすべてメモリに読み込むなどの処理が必要になり、レスポンス開始までの時間もかかります。（一般的なアプリケーションにはあまり影響がありませんが） そこでHTTP/1.1ではChunked Transferという仕組みが入っていて、事前に全体のレスポンスの長さが分からなくても、chunk=固まり毎にサイズを記してレスポンスを返していき、最後に0byteと送信することで、コンテンツの切れ目がわかるようになっています。 HTTP/1.1 200 OK
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
ウェブオペレーションエンジニアはリリース前のソースコードのココを見ているッ！ - blog.nomadscafe.jp
「ウェブオペレーションエンジニアはリリース前のソースコードのココを見る！」みたいな記事があればいいね — masahiro nagano (@kazeburo) November 20, 2012 ちょいと前にツイートしたこの件のまとめ。新規サービスのリリースや既存サービスに新しい機能が追加される際に、しばしばそのソースコードを確認しているのですが、僕がどんなところを見ているのかまとめてみました。 そのサービスへの導線とランディングページの確認 まず、そのサービスへの導線やランディングページを確認します。そしてその一番アクセスがあろうページ、一つか二つに確認対象を絞ります — masahiro nagano (@kazeburo) November 20, 2012 どんな素敵なサービスも、機能も適切な誘導がなければ使われる事はありません。また誘導次第では大量のアクセスが一度にサーバに対し
GrowthForecast のデータストアに MySQL が使えるようになりました - blog.nomadscafe.jp
これまで GrowthForecast のグラフ一覧や直近の数値などのデータはSQLiteに保存していましたが、パフォーマンスの問題がありそうということで、MySQL も利用できるようにしました。 移行ツールなどはありませんが、既にGrowthForecastを使っていて、MySQLを使いたい場合は、依存モジュールが増えているので以下のコマンドを実行し、モジュールの追加を行ってください。 $ git pull $ perl Makefile.PL $ cpanm --installdeps . テーブルはgrowthforecast.plの起動に自動で作られるので、MySQLにデータベースの追加とユーザの設定を行って下さい。 mysql> CREATE DATABASE データベース名; mysql> GRANT CREATE, DELETE, INSERT, UPDATE, SELECT
Replication Booster for MySQL を試す - blog.nomadscafe.jp
松信さんが作った Replication Booster for MySQL をデータサイズが大きいデータベースに対して使ってみました。 Yoshinori Matsunobu’s blog: Making slave pre-fetching work better with SSD github - yoshinorim/replication-booster-for-mysql Replication Booster for MySQL をものすごく簡単に説明すると、以下のようになるでしょうか。 MySQL でレプリケーションを設定した場合、マスターのバイナリログをIOスレッドが読み取り、relay-logへ記録します。そしてSQLスレッドがrelay-logから読み取ってテーブルを更新して行きます。Replication Booster を実行するとrelay-logを読み取り、更
Plack::Middleware::ReverseProxy でリモートホストを確認する理由 - blog.nomadscafe.jp
Reverse Proxyの後ろでApplication Serverを動かす際に、REMOTE_HOSTを本当のアクセス元に書き換えてくれる仕組みはいくつかありますが^1、Plackでは壇上氏の Plack::Middleware::ReverseProxy がそれにあたります。 ^1 例えば mod_extract_forwarded http://www.openinfo.co.uk/apache/ PM::ReverseProxy のSYNOPSISでもそうなってますが、このような仕組みを使う場合、REMOTE_HOSTを指定するのが安全です。 builder { enable_if { $_[0]->{REMOTE\_ADDR} eq '127.0.0.1' } "Plack::Middleware::ReverseProxy"; $app; }; 拙作の Plack::Buil
ImageMagickとOpenMPの件 - blog.nomadscafe.jp
「PerlMagick が OpenMP 有効だと高負荷になる件 :: drk7jp」の件 どうやら、Perlに限らずマルチプロセスでOpenMPが有効なImageMagickを動かすとパフォーマンスが悪くなるようです。 Enabling OpenMP for most algorithms creates 8 threads (1 per core). If your process creates 8 threads that’s a total of 64 threads and that is a whole lot of contention and possible misuse of your processor cache. 「ImageMagick • View topic - Multi Process Contention?」より ということで、small_light
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
