NginxでリバースプロキシをKeepAliveしたときの性能検証 - Qiita
Nginx + Luaを用いた、ハイパフォーマンスで動的なプロキシサーバを考察中です。 そのための施策の一つとして 上流サーバへのアクセスをKeepAliveする という方法がありますが その際、プロキシサーバにどの程度性能に変化があるのかを調査してみました。 リバースプロキシのkeepalive設定 前提条件として Nginx > 1.1.4 が必要。 upstreamに keepalive というattributeがあるのでそれを設定します。 それと同時に、プロキシヘッダーにHTTP/1.1設定などを行いましょう。 ちなみにproxy_passだけだとkeepaliveできないようです。upstream必須。 あと、もちろんバックエンドサーバ側もkeepalive設定しておきます。 upstream http_backend { server oreore.micro.service;
ありがとう t1.micro、こんにちは t2.small
このサイトも使っている超高速 WordPress 動作環境である『網元 AMI』が、Amazon EC2 の新しいインスタンス T2 に対応したので、早速移行したのが先週のこと。 それから一週間が経過したので、計測ツール CloudWatch を使ってサーバーパフォーマンスを検証してみました。 T2 インスタンスとは 新しく登場した T2 インスタンスは、バースト可能なパフォーマンスインスタンスと説明され、その名の通り CPU をバーストモードで動作させることができるようになっています。 これはつまり、突発的に CPU パワーが必要になった際にも、その要求にインスタンスが応えてくれると言うことで、ウェブサイト 用途で言えば突然のアクセス急増にもある程度対応できるということ（…になるはず）です。 AWS | Amazon EC2 | Instance Types （右上にある日本語を英語にし
microインスタンスはlimitかけると大きくパフォーマンスが向上する（※再追記あり） - アルパカDiary Pro
※2014/07/02 T2インスタンスタイプとの比較 を追記しました。 ※2014/03/13 他インスタンスタイプとの比較／m3.mediumの検証 を追記しました。 こちらの記事の二番煎じです。 cgroupで、お手軽CPU使用率制限 なるほど。 リソースにLimitかけるとstealを防げるためパフォーマンスも上がるというわけですね。 どのくらい変わるのか実験してみました。 cgroup前準備 sudo yum install libcgroup sudo chkconfig cgconfig on sudo service cgconfig start cgroup設定 上記参考URLとほぼ同じ設定です。 実行時はcpu.cfs_quota_usを変動させて比較してみました。 sudo vi /etc/cgconfig.conf # 以下を追加 group limittest {
EC2 Micro Instance の調査
EC2 Micro Instance は通常のインスタンスと違い短時間のバースト（高速実行）ができます．しかし Amazon Web Service の Web ページではその詳細が載っていないので，それについて調査を行いました． 高負荷時の挙動 EC2 Mirco Instance の CPU 接収形態は 2 種類存在します．このページでは高速モードと低速モードと記述します．調査により 2012 年 11 月時点では，高速モードの CPU 接収率（CPU が本来の速度と比較して制限されている割合）は平均 4 ％程度，低速モードの CPU 接収率は平均 90 ％程度となります． CPU を使用していない状態が続いている場合 EC2 Micro Instance は基本的に高速モードで動作していますが，高負荷をかけはじめしばらく経つと低速モードに移行します．調査により 2012 年 11 月
ただのメモ: Amazon EC2 の Micro インスタンスで使用可能な CPU リソースを調べる
2013年現在のデータで測定し直しました。 先日 Amazon EC2 Micro インスタンスを使う機会があり，色々と試してみた． 使っていると，すぐにターミナルの応答性が悪くなったり Ping の応答時間が不安定になるといったことが起きた． top コマンド実行してみたところ，Steal が極端に多くなっていた． Cpu(s): 2.2%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 97.8%st Steal は@ITの記事によると，使いたいけど使えなかった時間らしい． steal列には、ゲストOSがリソース要求を行ったにもかかわらずCPUリソースを割り当ててもらえなかった時間の割合が表示されます。 @IT リソース制御でサービスレベルを確保せよ CPUリソースはバーストできるじゃないのかよー，と思って調べてみた．
cgroupで、お手軽CPU使用率制限 - 海馬のかわり
先日無償公開されたSoftetherをAmazon EC2のmicroインスタンスへ入れてみた。 しかしCPU性能がしょぼいのか、暗号化処理に結構負荷がかかるのか、CPUを使い果たしてしまう事態に。 さらには仮想環境ということでstealが多発し、輪をかけて使い物にならない。 ※これはEC2/microインスタンスの特性らしい。 http://qiita.com/items/8248ec4654cb809504c9 http://memo-off.blogspot.jp/2011/08/ec2-t1microcpu-steal.html そこで今回はcroup/cgroupsを用いて当該プロセスのCPU使用率を制限、さらにはstealも発生しないようにする。 ※croupは、Redhat系ならRHEL6/CentOS6から利用可能。 まずは、何もしない時のSoftetherプロセス(vpn
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
How Far Can You Go With HAProxy and a t2.micro - :HIPSTER_DEV_BLOG
kiyoka.2012_05_08 -- [AWS][EC2] 失敗事例: Microインスタンスのスラッシング状態で 1日 $10課金された件