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
Starlet が HTTP/1.1 に対応しました / wrkによるベンチマークとYAPC::Asiaのトーク宣伝 - blog.nomadscafe.jp
Starlet が HTTP/1.1 に対応しました。これによりでnginxのupstream keepaliveなどが捗ると思われます https://metacpan.org/release/Starlet https://github.com/kazuho/Starlet ながらくStarletはHTTP/1.0 + keepaliveなサーバでしたが、version 0.20にてHTTP/1.1に対応しました。具体的に対応したスペックは以下。 HTTP/1.1 keepalive Transfer-Encoding: chunked (Request & Response) Expect HTTP Pipelining StarmanやMonocerosとだいたい同じ動きをするようになっていると思われます。 なお、導入にあたっては、リバースプロキシ等と組み合わせた場合の動作パターン
Monoceros というPrefork型だけどC10Kの接続を捌くことができるPSGI/Plackサーバ書きました - blog.nomadscafe.jp
Monoceros というPSGI/Plackサーバ書きました https://metacpan.org/release/Monoceros https://github.com/kazeburo/Monoceros StarmanやStarletのようなPreforkなアプリケーションサーバでは、コネクションの維持イコールプロセスの占有なので、HTTPのKeepAliveは無効にするのが一般的ですが、負荷の高いサービスではTIME_WAIT状態のソケットが溜まったり、SYN-ACKの再送問題などあり、KeepAliveを使いたいという欲求があったりなかったりします。 Monoceros はリクエストを処理するworkerの他に、イベントドリブンで動くコネクション管理プロセスを立てて、クライアントからの接続ソケットをunix domain socketを使いプロセス間でやりとりします。待機
開発ブログ | プリントエフ
phpでWebSocketの実験をしてみたかったのですが、思ったより面倒そうだったのでサンプルWEBサーバー（ajax対応）その４のソースを拡張することにしました。 以前の記事は以下のリンクからどうぞ。 サンプルWEBサーバー（ajax対応）その１ サンプルWEBサーバー（ajax対応）その２ サンプルWEBサーバー（ajax対応）その３ 下準備 下準備としてajaxで返すデータの若干の変更と、クライアント側（JavaScript）でのWebSocket処理の追加を行います。 この段階ではWebSocketサーバーが用意できていないので、実行するとonerror()とonclose()によってアラートが表示されることと思います。 pos = message.IndexOf("POST /getSampleData "); if (mStatus == STATUS.CHECKING &&
)
XSP (Webサーバー) - Wikipedia
XSPとは、MonoプロジェクトおよびGNOMEプロジェクトによりオープンソースで開発が行われているWebサーバ用ソフトウェア（またはWebサーバサービス）である。 マイクロソフトがWindows向けに開発・提供しているWebアプリケーションフレームワークであるASP.NETおよびASP.NET MVCを、LinuxやMac OS Xなどの様々なOS上で動かすことを主目的としている。XSPは、MonoおよびC#を用いて開発されており、Monoが動作する環境であればOSを問わず動作する。なお、Windows上であればマイクロソフト製のランタイム(.NET Framework)でも動作する。さらにUNIX拡張機能を用いることでWindows上では動作しなくなるが、UNIX系OS固有の機能を用いたWebシステムを構築することも可能となっている。 XSPは安定して動作するため単体のWebサーバーと
Plack::Middleware::ReverseProxy でリモートホストを確認する理由 - blog.nomadscafe.jp
Reverse Proxyの後ろでApplication Serverを動かす際に、REMOTE_HOSTを本当のアクセス元に書き換えてくれる仕組みはいくつかありますが^1、Plackでは壇上氏の Plack::Middleware::ReverseProxy がそれにあたります。 ^1 例えば mod_extract_forwarded http://www.openinfo.co.uk/apache/ PM::ReverseProxy のSYNOPSISでもそうなってますが、このような仕組みを使う場合、REMOTE_HOSTを指定するのが安全です。 builder { enable_if { $_[0]->{REMOTE\_ADDR} eq '127.0.0.1' } "Plack::Middleware::ReverseProxy"; $app; }; 拙作の Plack::Buil
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
