Apache, Lighttpd, nginx における持続的接続と lingering close の実装について - kazuhoのメモ置き場
lingering close がなんであるかについては、Apache Performance Tuning - Apache HTTP Server Version 2.2 を参照。 Apache 2.2.16 と lighttpd 1.4.28 は、必ずアプリケーションレイヤでの lingering close を行う Apache は2秒、lighttpd は5秒 nginx 0.8.53 は直前に request body があった場合のみ SO_LINGER を利用する これは古い HTTP client が request body のあとに CRLF つけてくることがある対策だと思う HTTP pipelining の関係で RST が飛ぶ場合の対策コードはないかも 一方で、msie6 で POST の場合、あるいは safari だと常に keep-alive を disa
nginx+PHP+MySQL+Memcachedでマルチバイト・サブドメイン式のURL短縮サービス « D-Theory
跳.jpっていうサービスありますよね。http://○.跳.jpみたいな形の短縮URLです。○の部分に漢字が入り、http://亜.跳.jpとなります。サブドメインの部分には漢字のみ、それもJIS X0208企画に準拠したもののみ（6355文字）を使用しているみたい。 サブドメインもすごいけど何より日本語ドメインってところがすごい！素晴らしいサービスだなと思ったので僕も真似して作ってみました。本当に真似しただけですね。オマージュとかリスペクトって感じじゃないです。パクリですごめんなさい。ところで、最近t.coに強制的に変換されるようになったみたいですね・・・。つくったのはちょっと前ですが、今更的な記事で非常にアレですねー・・・。 略.tkを取って、先ずリダイレクトの仕組みから考えます。普通の短縮URLは http://hoge.jp/XaW9qa を http://hoge.jp/?cha
サイト閉鎖のお知らせ | ASCII Books
ASCII Booksのサイトをご利用いただき、ありがとうございます。 2016年12月6日をもちまして、サイトを閉鎖させていただくことになりました。 今までサイトをご利用いただき、ありがとうございました。 アスキー・メディアワークスを引き続き、よろしくお願いいたします。
何気に流行っているらしいロードバランサー nginx を使ってみる - 傀儡師の館.Python - 楽天ブログ（Blog）
2007.07.21 何気に流行っているらしいロードバランサー nginx を使ってみる カテゴリ：その他 Scaling Python for High-Load Web Sites を読んでいたら、この中で Load Balancer として nginx があげられている。Perlbal を試してみようかなと思っていたところなのだが、とりあえず nginx について先に調べてみる。pound とも最終的に比べる必要ありか。 Online Security Blog によるとGoogle Web server software distribution across the Internet の 4% が nginxらしい。 Netcraft では 2007年6月時点で 0.19% と少な目。でも Zope の 0.03% より多いし、thttpd や Resin よりも多いといえば十分
mod_php(Apache)とspawn-fcgi(nginx)でのパフォーマンス比較 « cat /dev/random > /dev/null &
PHPを使う場合Apacheとnginxどっち使えばいいん？と気になったのでパフォーマンス比較してみました こんな感じの構成で すべて仮想サーバ構成です 負荷元サーバー CPU=2 RAM=1000M がんばるサーバ CPU=4 RAM=1024M DBサーバ CPU=4 RAM=1536MB 使ったミドルウェア Apache 2.2.3 Nginx 0.7.64 PHP 5.3.1 （子プロセス=6 tcp接続） MySQL 5.5.1 spawn-fcgi 1.4.22 wordpress 2.9.1 早速基礎体力というか通常の戦闘力を測ってみます abで多重度1で100回リクエストしてみます 公平を期すために二回目の結果をとっています ab -c 1 -n 100 -H "Host: blog.xcir.net" http://192.168.1.123:82/
nginx+squidで画像キャッシュサーバーの作り方 - hideden.hatenablog.com
仕事で画像キャッシュサーバーを構築した時のメモ。大規模事例の設定例が検索してもあまり見つからなかったので同じような境遇の誰かの参考になれば。 ピーク時のトラフィックは数Gbps 画像総容量は数十TB バックエンドのstorageが複数種類 規模とアクセス量とアクセスされる画像の種類が多いので、squidでdisk cacheを使用するとCOSS等を使用してもdiskIOで詰まる為、全てon memory cache。cache容量を確保する為に必然的にcacheサーバーの台数も数十台。 1. squidをsibling構成で並列に並べる cache_peer 10.0.1.1 sibling 80 3130 no-query no-digest proxy-only cache_peer 10.0.1.2 sibling 80 3130 no-query no-digest proxy-o
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
