PHP BLT#1でLTしてきました - blog.nomadscafe.jp
PHPの勉強会なので、いままでお会いしたことのない方とお話ができてよかったです。 発表内容は大きくなってしまったmaster.phpファイルをどうやって高速に読むかというお話です。PHPではリクエストの終了とともに全てのメモリを捨ててしまうので、変わらないデータもリクエストの度にキャッシュからロードしなくてはいけません。大きなphpファイルがあれば当然毎回の読み込みがオーバーヘッドとなってきます。そんな環境でどうやってアプリケーションのパフォーマンスをあげていったのかを紹介しています。 スライドの中でfile sizeを小さくする必要があると書きましたが、@hnwさんによると、VM命令が多過ぎるのが問題で、構造を簡単にしたことでVM命令が減ったのがよかったのではとのことでした。非常に参考になりました。ありがとうございました \n\n\nPHPの勉強会なので、いままでお会いしたことのない方と
ISUCON5にチーム「GoBold」で参加して特別賞と3位でした - blog.nomadscafe.jp
そろそろ傷が癒えてきた。。 ISUCON5の本選にメルカリのインフラ改めSite Reliability Engineerで結成したチーム「GoBold」で参加して、最も速く決められた得点に到達したチームに与えられる特別賞と最終的に3位となりました。チームメンバーは @cubicdaiya、@shmorimo、@kazeburo の3人です 出題のtagomorisさん、kamipoさん、運営の941さん、LINEの皆様、テコラスの皆様ありがとうございました。 ソースコードとやったこと。 こちらにて公開しています https://github.com/kazeburo/isucon5-final-public 構成は、Nignx + Perl + PostgreSQL + memcachedです。 課題となったサイトは、データベースに格納してある情報からいくつかのAPIに問い合わせて、その
ISUCON5予選に参加して2位で予選通過しました - blog.nomadscafe.jp
ISUCON5 の予選にメルカリのインフラ系エンジニアで結成したチーム「GoBold」で参加して、無事2位で通過しました。チームのメンバーは、@cubicdaiya、@shmorimo、@kazeburoの3人で、普段から横にならんで座って、メルカリのパフォーマンス改善やサーバ環境の整備に携わっています。 今回の予選問題、ずいぶん盛ってきたなーというのが最初の印象。モリスさんも予選問題を本選のようにしたいと言っていたし、その通りになっていました。マシンの性能に対しての扱うデータ量もメモリに乗り切らないであろうスレスレのラインでkamipoさんの調整も神だなと思いました。おかげでやることが満載だし、素晴らしい問題でした。運営の941さんも含め本当にお疲れさまでした。本選もよろしくお願いします。 チームのメンバーのblog ISUCON5予選 2位で通過しました - 考える人、コードを書く人
Mackerel meetup #4, Shibuya.pm Tech Talk #17、Norikra meetup #2 で喋って来た & YAPC::Asia Tokyo 2015のトークに応募した話 - blog.nomadscafe.jp
久しぶりに喋ってきました。Mackerel meetup #4とShibuya.pm Tech Talk #17ではLTを、Norikra meetup #2では少し長めの話をさせて頂きました。 資料3つ貼っておきます。 メルカリでもサーバ・運用周りの仕事をしています。メルカリではzから始まるモニタリングツールをメインに使用していて、サーバ周りのさまざまなデータを突っ込んで監視に役立てていますが、カジュアルにグラフをつくって、アラートを仕掛けるという用途には向いていないなぁと思ってます。 そこで、Norikra と Mackerelを組み合わせて柔軟にログの可視化＋閾値の設定を行うってのを思いついて設定したところ、結構うまく行って、それについてtwitterでつぶやいていたところ、今回のような機会を頂いたというわけです。 harukasanのログ解析ツールのまとめは非常にわかりやすく、fu
株式会社メルカリに入社しました - blog.nomadscafe.jp
入社なう pic.twitter.com/OSi3NaCAnV — masahiro nagano (@kazeburo) February 2, 2015 1000万ダウンロードと会社の2周年という記念の日に入社しました。 2周年を迎えたメルカリ、ダウンロード数は1000万超に - TechCrunch iOS、Androidアプリのダウンロード数はもちろん、商品の出品数や流通額も大幅に伸びています。また、アメリカでの展開等も進んでいるので、サーバ・フロントのエンジニアを募集しています。ご興味のある方はぜひご連絡くださいませ。 3月には六本木ヒルズへのオフィス引越も予定されています。mixi入社前にlivedoorのセミナーでヒルズへ行ってから9年。ここに通うことになるとは思いもしませんでした。 今後の仕事 仕事は変わらずサーバ周りの運用・パフォーマンス改善、スケーラビリティの向上です。
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
一時ファイルとdentry cacheとメモリ - blog.nomadscafe.jp
わりと長い間悩んでいたんだけど、最近解決したのでメモ。 サービスで利用しているsmalllightの画像変換サーバが、Apacheが使っているメモリ以上のメモリを使用し、Swapしたりメモリ枯渇でサーバがダウンするなどのことが何度かありました。 ↑メモリの動きはこんな感じ いろいろ調べた結果「dentry cache」なるものがメモリ多くを占めていることがわかりました。dentry cacheはディレクトリやファイル名とinodeとを結びつけに使われるキャッシュです。smalllightでは画像を変換する際に一時ファイルを作成するので、その情報が残るようです。 手元で再現させる 本番で使っているサーバはCentOS5系ですが、手元のVagrant上のCentOS6(ファイルシステムはext4)で、再現させてみました。 use Parallel::Prefork; use File::Tem
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
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
blog.nomadscafe.jp
PHPの勉強会なので、いままでお会いしたことのない方とお話ができてよかったです。 発表内容は大きくなってしまったmaster.phpファイルをどうやって高速に読むかというお話です。PHPではリクエストの終了とともに全てのメモリを捨ててしまうので、変わらないデータもリクエストの度にキャッシュからロードしなくてはいけません。大きなphpファイルがあれば当然毎回の読み込みがオーバーヘッドとなってきます。そんな環境でどうやってアプリケーションのパフォーマンスをあげていったのかを紹介しています。 スライドの中でfile sizeを小さくする必要があると書きましたが、@hnwさんによると、VM命令が多過ぎるのが問題で、構造を簡単にしたことでVM命令が減ったのがよかったのではとのことでした。非常に参考になりました。ありがとうございました そろそろ傷が癒えてきた。。 ISUCON5の本選にメルカリのインフ
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
ウェブオペレーションエンジニアはリリース前のソースコードのココを見ているッ！ - blog.nomadscafe.jp
「ウェブオペレーションエンジニアはリリース前のソースコードのココを見る！」みたいな記事があればいいね — masahiro nagano (@kazeburo) November 20, 2012 ちょいと前にツイートしたこの件のまとめ。新規サービスのリリースや既存サービスに新しい機能が追加される際に、しばしばそのソースコードを確認しているのですが、僕がどんなところを見ているのかまとめてみました。 そのサービスへの導線とランディングページの確認 まず、そのサービスへの導線やランディングページを確認します。そしてその一番アクセスがあろうページ、一つか二つに確認対象を絞ります — masahiro nagano (@kazeburo) November 20, 2012 どんな素敵なサービスも、機能も適切な誘導がなければ使われる事はありません。また誘導次第では大量のアクセスが一度にサーバに対し
Apache httpd.conf の Allow from .. にコメントを書いてしまうとDNSの逆引きが行われてレスポンスが悪化するので注意の件 + コメントが書けるようになるパッチ - blog.nomadscafe.jp
Apacheのconfにコメントを書く際に、設定の後ろに書く事はできないのは知られているのかどうかよくわかりませんが、その通りです。例えば MaxRequestsPerChild 200 #少なめに これは syntax error になります % ./local/httpd/bin/apachectl -t Syntax error on line 12 of /Users/.../local/httpd/conf/httpd.conf: MaxRequestsPerChild takes one argument, Maximum number of requests a particular child serves before dying. よくやりがちなんですが、ドキュメントにも Directives in the configuration files are case-in
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
