Blog Archives

HTTP ベンチマークツール wrk についてメモ

モダンな HTTP ベンチマークツール wkr の簡単な使い方についてメモ。 wrk の特徴は以下。 C で書かれている マルチコア CPU を 活かした高負荷をかけられる スレッドと epoll/kqueue のイベントドリブンを活用して負荷をスケールさせる(NOTICE ファイルを読むと Redis Event Library(ae event loop) を拝借しているようです) Lua スクリプトで HTTP クライアントの処理や実行結果のレポートをカスタマイズできる Installing wrk in CentOS 6 まずはビルドに必要なパッケージをインストールします。 openssl-devel をインストールしていないと、make 時に以下のようなエラーが発生します。 次にソースコードから wrk をビルドします。 Usage 上の例では

Tagged with: , , ,
Posted in middleware

S3にBasic認証付きリクエストをすると400:Bad Requestになる

nginx で S3 にリバースプロキシしたサイトで、特定の URL 配下にしらーっとBasic認証を追加したら、S3 のリソースの取得が”400 : Bad Request” でことごとく失敗していた。 現象を再現させる まずはこの動きを確認してみる S3を用意 バケットを作成し、オブジェクトを public-read の ACL つきて PUT する。 public read が付いているので、anonymous user も GET できる。 Basic 認証付きでリクエスト 次に Basic 認証付きでリクエストしてみる みごとに 400 Bad Request エラーが発生した。 nginx での解決

Tagged with: , , ,
Posted in aws, middleware

[nginx]ホスト名に応じてレスポンスするファイルを振り分ける

nginx には ngx_http_map_module というハッシュテーブルを操作するモジュールがあり、リクエストヘッダーのホストやユーザーエージェントをキーと見立てて値を振り分けることができる。 このモジュールを使うと、複数のサブドメインをさばいていている時に、robots.txt のような各ドメインに必要なファイルをサブドメインに応じて振り分ける。 ngx_http_map_module の使い方 単純な例 まずは map を使った単純な例から これを Python っぽく置き換えると というように key-value ペアをまず定義し、リクエスト処理時に というようにリクエストヘッダーの http_user_agent をキーに値を取得する。 map の発展的な使い方 重複定義 というように、同じ変数($http_user_agent) に対して複数の map 変数($foo, $bar) を定義できる Key-Valueをファイル管理 Key-Value のペアはファイル管理して include しても良い パターンマッチング map の キーのパターンマッチングは prefix

Tagged with: ,
Posted in web

AWS CloudWatchにカスタムメトリックスを登録する

ゴール AWS のサービス(特に EC2)を監視するには aws マネージドサービスにデフォルトでついてくる CloudWatch を利用(aws おまかせ) カスタムメトリックスを CloudWatch に送信し、CloudWatch を利用(エージェントだけ自前実装) new relic のような ASP サービスを利用(エージェントだけ自前インストール) Zabbix などの監視システムを構築(サーバ、クライアントの両方を自分で面倒を見る) といった方法がある。 今回は2つ目の方法をメモ。 監視内容 EC2 インスタンス(OS は amazon Linux)からカスタムメトリックスを CloudWatch に送信する。 実験に使いやすいインスタンスに nginx がインストールされていたので nginx のメトリックスを送ることにする。 nginx のメトリックスを取得 ngx_http_stub_status_module モジュールを利用してメトリックスを取得する。 amazon

Tagged with: , , , ,
Posted in aws

nginx rewriteのlastとbreakの違い

nginx でリライトルールを書くには return または rewrite を使う。 rewrite を使った時の フラグ last と break の違いがわかりにくかったので、簡単にメモ。 return を使ったリライト syntax return code [ text ] (ex. return 403 や return 404 “not found”) return code URL (ex. return 301 http://www.example.org$request_uri; ) return URL (ex.

Tagged with: , ,
Posted in middleware

VarnishはVCL読み込み時にしか名前解決しない

VarnishはVCL読み込み時にしか名前解決しない Varnish の名前解決の仕様 結論から。 オフィシャルフォーラムで Varnish の中の人が名前解決の仕様についてコメントしている Varnish sticks to an IP address once it is resolved. You can force a new lookup by reloading the VCL. https://www.varnish-cache.org/forum/topic/91 by design でこの仕様になっているので、IP が変わりうるサーバをオリジンサーバに指定している場合、運用でうまく回避しなければいけない。 ザクッと検索すると、先人は次のような方法で回避している。 [名前解決を外に丸投げ]Varnishとオリジンサーバの間にサーバをはさみ、そこで名前解決させる [Varnishで頑張る]Varnish の設定ファイルを適宜リロードさせて、名前解決をやり直す 案1:名前解決を外に丸投げ Varnish で名前解決するのは諦め、IP アドレスが変わらない

Tagged with: , , ,
Posted in middleware

nginxでログをsyslogに出力する

やりたいこと オープンソース版の nginx はログを専用のファイルだけに出力するようになっている。 有償版 nginx を使うと、 ngx_http_log_module モジュール経由で syslog 出力可能。 今回は github で公開されているパッチ(yaoweibin / nginx_syslog_patch)を適用することで nginx のログを syslog 出力させる。 インストール syslog 出力設定 /usr/local/nginx/conf/nginx.conf を変更 最低限の変更は以下 syslog のファシリティを設定 main の名前で log_format を定義 server ディレクティブ内でログの出力先に syslog を指定 ログを確認 curl で nginx

Tagged with: ,
Posted in middleware
Archives
  • RT @__apf__: How to write a research paper: a guide for software engineers & practitioners. docs.google.com/presentation/d… /cc @inwyrd 4 months ago
  • RT @HayatoChiba: 昔、自然と対話しながら数学に打ち込んだら何かを悟れるのではと思いたち、専門書1つだけ持ってパワースポットで名高い奈良の山奥に1週間籠ったことがある。しかし泊まった民宿にドカベンが全巻揃っていたため、水島新司と対話しただけで1週間過ぎた。 それ… 4 months ago
  • RT @googlecloud: Ever wonder what underwater fiber optic internet cables look like? Look no further than this deep dive w/ @NatAndLo: https… 4 months ago
  • @ijin UTC+01:00 な時間帯で生活しています、、、 10 months ago
  • RT @mattcutts: Google's world-class Site Reliability Engineering team wrote a new book: amazon.com/Site-Reliabili… It's about managing produc… 1 year ago