サーバの監視やモニタリングなどのサービス・ソリューションを提供するMSP(マネージメントサービスプロバイダ)のハートビーツの馬場さんが「Webエンジニアが知っておきたいインフラの基本」という本を出版されました。 献本頂きありがとうございます！！ 冬休みは実家に帰ったり、旅行に行ったりと何かとイベント事が多くなかなか本を読む時間が取れなかったり、年が明ければ弟妹・甥っ子姪っ子にお年玉を上げないとならず、自由に使えるお金も減ってしまうかもしれません。なので、読んでみて欲しい本が何冊もあっても困ってしまいますね。そこで自分がお勧めしたいのが、この一冊「Webエンジニアが知っておきたいインフラの基本」です。 本屋に行く時間がない方も安心。電子版があります Webエンジニアが知っておきたいインフラの基本 インフラの設計から構成、監視、チューニングまで【委託】 - 達人出版会 http://tatsu

ツチノコブログの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

Nagiosを使っていると、その瞬間の絶対値だけじゃなく、差分や変化量を取得してその数値を監視したくなりますよね。ならないとしたら、今すぐこの記事を読むのをやめて病院に行って下さい。 Nagiosで変化量を測定するには、プラグインの中で前の数値をどこかファイルにでも保存し、比較するという手があります。このcheck_bandwidthはその方法を取っているようです。 ただ、これだと汎用性があまりないので、監視対象サーバ側に定期的に指定したコマンドを実行して、その数値を外部から取得できるサーバを書いてみました。 CPAN: https://metacpan.org/release/App-derived *出てくるまで時間がかかるようです github: https://github.com/kazeburo/App-derived 使い方 インストールはcpanmで $ cpanm -n

「ウェブオペレーションエンジニアはリリース前のソースコードのココを見る！」みたいな記事があればいいね — masahiro nagano (@kazeburo) November 20, 2012 ちょいと前にツイートしたこの件のまとめ。新規サービスのリリースや既存サービスに新しい機能が追加される際に、しばしばそのソースコードを確認しているのですが、僕がどんなところを見ているのかまとめてみました。 そのサービスへの導線とランディングページの確認 まず、そのサービスへの導線やランディングページを確認します。そしてその一番アクセスがあろうページ、一つか二つに確認対象を絞ります — masahiro nagano (@kazeburo) November 20, 2012 どんな素敵なサービスも、機能も適切な誘導がなければ使われる事はありません。また誘導次第では大量のアクセスが一度にサーバに対し

YAPC::Asiaのスライドで予告していた通り、実際に弊社のいくつかのサービスで使っている my.cnf を公開しました。 github: https://github.com/kazeburo/mysetup/tree/master/mysql 今回、公開した理由はMySQl Beginners Talksの発表の中でも触れている通りです。MySQLのソースコード中に含まれるサンプルのmy.cnfが最近のサーバハードウェアや運用に合わなくなって来ているという状況で、自分の設定にイマイチ自信が持てていない人は少なくないはず。そこで各社秘伝のタレ的な my.cnf をOpen & Shareすることで、モダンなmy.cnfを作り上げる事ができるんじゃないかという考えの下、今回 github にて公開しました。 ファイルは4つあり、それぞれ MySQL 4.0、5.1、5.5、そしてテスト中

なんかtwitterで書いたらウケたっぽいので cronをつかって外部のAPIに問い合わせる場合は、毎時0分をさけるのオススメ！！！！お兄さんとの約束だ！！！ — masahiro nagano (@kazeburo) August 9, 2012 某サービスのAPIへの問い合わせ件数を調べると、毎時 0分台(0秒から59秒)のアクセスは1分から59分までの1分間の平均アクセス数の5倍から8倍にもなります。 これはおそらく、crontabの設定が 0 * * * * /path/to/call_foreign_api になっていることが多いからじゃないかなぁと思うのです。 その結果、サーバのロードアベレージは このように毎時0分だけ跳ね上がってしまいます。サービスを快適に提供できなくなる可能性があるので、APIの利用を制限したり、サーバを追加しなければなりません。これはサービス利用者、サー

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

GrowthForecastについては、また別のエントリーとして詳しく紹介したいと思います。 kentaro氏のAPNs周りの実装のトーク、papix氏のYAPC::Asiaに行ってきたアツい話、またgardejo氏の汎用機で如何にPerlを使うかのLTなど面白く聞かせて頂きました。実はKansai.pmに参加するのは今回で2回目で、1回目は京都に住んでいる際に行ったlapis25氏のプレゼン中にもあった第六回だったりするのですが、その時と今回と共通して感じた事としてWebサービス以外の場所でもPerlが多く使われているんだなぁということがあります。普段Yokohama.pmに参加したり、社内で会話をしていると、ほぼ全てWebサービスに関連した話となってしまいますが、実際にはもっと広く、メインフレーム・汎用機上のプログラムを処理する為にPerlを使ったいたり、大学の研究で活用されているんだ