アプリケーションでどうしても捌けない量のリクエストが一時的に押し寄せてしまう場合、アプリケーションサーバが死ぬのを避けるために GET は制限を掛けたいが、POST はリトライが面倒なのでなるべく通してあげたい、というような要求を nginx で処理できるかどうか。 実装として一番望ましいのは GET は 100 req/sec で制限 (超えたら503) POST は無制限 のようにメソッドごとに別々の制限を掛けることだったのですが、とりあえず HttpLimitReqModule を使うことで、メソッドごとに同一の上限を設定することはできました。 http { limit_req_zone $request_method zone=method:1m rate=100r/s; server { listen 80; location / { limit_req zone=method;
httpstatus コマンドで、HTTP のステータスコードをすばやくしらべる! 一般的な Web Programmer ならば、HTTP Status code はすべて暗記していると聞きました。 しかし、僕は初心者なので、なかなか覚えきれていないので、HTTPのステータスコードをさがすのに便利なツールを用意しました。App::httpstatus です。インストール方法は cpanm App::httpstatus です。というか依存とかないのでhttp://api.metacpan.org/source/TOKUHIROM/App-httpstatus-v1.0.0/httpstatus をコピーしてくればうごきます。 使い方は以下のとおりです。 4xx なコードを列挙する。 % httpstatus 4 400 Bad Request 401 Unauthorized 402 P
Labeled Tab-separated Values (LTSV) がブームのようです。 LTSV については、ラベルをつけることで柔軟に拡張できるという点が、その特徴として取り上げられますが、もう一点、タブをセパレータに使うことでログのパースが簡単になった、という点を忘れるべきではないでしょう。 特に httpd のログは NCSA httpd という HTTP/0.9 時代のWebサーバのログフォーマットがベースに拡張されてきたため、以下のようにセパレータとして空白、[]、ダブルクォート ("")*1が混在するという、とても処理しづらいものになっていました。どれほど複雑かは「404 Blog Not Found:perl - Apache Combined Log を LTSV に」の実装を見れば明らかでしょう。 127.0.0.1 - - [08/Feb/2012:23:52:4
先週金曜日にエンジニアサポートCROSS2013に行ってきた。目当ては @Jxck_ さんホストによる次世代Webセッション。セッション自体は前後半に分かれていて 前半はプロトコル編。SPDY (wikipedia) や HTTP/2.0 の動向やその課題点など 後半はアーキテクチャ編。プロトコルが変わった上で、その上で動くソフトウェアのアーキテクチャが云々 という内容でした。前半がより技術寄り、後半はテーマ的にもより広範の話題を扱うという感じでどちらも面白かった。 CROSS 2013レポート(2) - mad-pの日記 こちらに細かいログがあります。 話の前提になる SPDY や HTTP/2.0 周りの昨今については 【HTTP 2.0の最新動向】 第1回：HTTP/2.0の策定、ついに始まる - INTERNET Watch Watch 【HTTP 2.0の最新動向】 第2回：HT
GitHub には clone するための URL として [HTTP]、[SSH]、[Git Read-Only] の 3 つが用意されている。 いままで、SSH に慣れているという理由だけで [SSH] を利用していたのだけど、「SSH は転送速度が遅い」という問題がある。 SSH だとこんなに遅い… さっき、[SSH] で clone してみたら 20～60 KiB/s 程度の速度しか出なかった。 $ git clone git@github.com:nitoyon/tech.nitoyon.com.git Cloning into 'tech.nitoyon.com'... remote: Counting objects: 8856, done. remote: Compressing objects: 100% (2125/2125), done. remote: Total
最近上京してきたんだけど東京とか物価高くてやんなっちゃう。ほんともう特に家賃とか駅から徒歩30分とかそれってもう徒歩圏内じゃなくない？あ、どうも僕です。 今日はクライアント（ブラウザ）側で高速にページを表示させるために、最低限押さえておきたい簡単なテクニックを厳選してお届けしちゃうよ！ WebサイトやWebサービスを作る上で、ユーザを獲得するには応答時間を早めることがとても重要なファクターなんだ。 統計的にも応答時間とユーザのリピート率との相関性は実証されていて、例えば、表示までに時間のかかるサイトなんかは、もう二度と使わねぇとか思っちゃうよね！ それほど応答時間というものはユーザを獲得する上でもかなり重要なんだ！ HTTPリクエスト数を少なくする Webページが表示される際、まずはベースとなるHTMLが読み込まれてから、ページにリンクしてある画像ファイルやスクリプトファイルなどを読み込ん
Vim Advent Calendar 2012 の 4 日目の記事です。 「やった！コンプガチャで Vim 出た！」 「だって前の彼氏、Vim 使いじゃなかったんだもん」「マクドナルド店員「ご一緒に Vim など如何ですか？」」 こんな言葉が聞かれる様になって随分と経ちました(要出典)。 昨今、Vim はテキストエディタの枠を超え、アプリケーションプラットフォームへと変わりつつあります。 vital.vim 等を使う事で簡単にアプリケーションを作る事も出来る様になりました。手前味噌ではありますが webapi-vim の一部も vital.vim に取り込まれています。 このブログでも結構取り上げていますが webapi-vim とは一体何か。名前の通り、Web Application Programming Intreface を扱えるライブラリです。 webapi-vim とは we
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
