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
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
追記＠2009-10-20： もっとちゃんとした reproxy モジュールを書きました。こちらの新しい記事を参照ください。 lighttpd 大好きっ子な村瀬です。 突然ですが、perlbal というロードバランサーをご存じでしょうか。この perlbal には reproxy という機能があります。 これは、このロードバランサー下のWebサーバーが X-Reproxy-Url: http://example.com/ などというヘッダを返すと、perlbal がその URL の内容を取得し、コンテンツボディをその URL の内容に置き換えてくれるという物です。 MogileFS や Amazon S3 との相性のいい機能ですね。 これを lighttpd でもやりたくなったのでがんばってみました。 mod_fastcgi_reproxy 既存の mod_fastcgi に reprox
この時期にも花粉症に苦しむ村瀬です。こんにちは。 軽量で高速な動作がウリの lighttpd ですが、動的コンテンツで大きなファイルのやり取りを行おうとするととたんにパフォーマンスが落ちるという問題があります。 この問題は、lighttpdで動的コンテンツを扱う場合FastCGIを使用することが多いのですが、その構造に問題があります。 FastCGIを使用する場合のデータ通信の構造は以下のようになっています。 ブラウザ <---(1)---> lighttpd <---(2)---> FastCGI ブラウザとlighttpdとのデータのやり取り lighttpdとFastCGIプロセスとのやり取り プロセス数が有限なFastCGIでは、即座にデータを受け取り即座にレスポンスを返すというのが鉄則で、ここで時間のかかる処理をしてしまうとすぐにプロセスが埋まり待ち状態が発生してしまいます。 つ
Apacheとlighttpdの安定性はどのくらい？ 「第2回：性能検証！早いのはどっち？（http://www.thinkit.co.jp/article/119/2/）」は、Apacheとlighttpdのパフォーマンス面について、2種類のベンチマークツールを利用して、どちらのWebサーバーが速いのか検証を実施しました。その結果、リクエストの処理量でlighttpdがApacheを下回ることは無く、パフォーマンス面ではApacheと比較してlighttpdの方が優れている結果となりました。 しかしシステムとして多少パフォーマンスが良くても、安定したサービスが提供できなければ実際に運用するのは厳しいでしょう。そこで、今回はApacheとlighttpdの安定性について取り上げ、どのくらい安定して稼働することができるかを検証していきます。 何をもってして安定していると評価するか Webサー
lighttpdとApacheの処理性能を比較 「第1回：lighttpdを知っていますか？（http://www.thinkit.co.jp/article/119/1/）」では、軽量Webサーバーであるlighttpdの概要や特徴、機能面の紹介、Apacheとの違いを簡単に解説しました。 その中で、lighttpdは一般的に軽量で高性能と言われていることについて触れましたが、今回は実際にベンチマークツールを使用して、lighttpdがApacheと比較して本当に性能が良いのか、どのくらい性能差があるのかを検証していきます。 検証環境の構成 図1の上に今回の性能試験で利用するサーバーのスペックを、下に検証環境を示します。サーバー機器としては一般的なスペックのものを用意しました。このサーバーの上位にあるスイッチングハブに、クライアントとして、ほぼ同スペックの機器を同一ネットワーク内に接続し
lighttpdとは？ Webサーバーソフトウエアといって思い浮かべるのは、代名詞的な存在の「Apache」でしょうか、それともMicrosoft社製の「IIS」でしょうか。 今回、紹介する「lighttpd（http://www.lighttpd.net/）」は、軽量かつ高速性を重視して設計された比較的新しいWebサーバーソフトウエアです。 lighttpdは、BSDライセンスで公開されているオープンソースソフトウエアで、無料で利用することができます。そのため国内外を問わず、多くの著名な大規模Webサイトで利用されており、特に画像や映像などといった静的コンテンツの配信に使われることが多いようです。 さらにCGIやFastCGIといった外部プログラムのインターフェースもサポートしているため、近年流行のWebアプリケーションフレームワークであるRuby on Railsや、Python（Dj
lighttpdのモジュールを書くことを覚えてしまったせいで、 ついついlighttpdのモジュールで仕事を進めてしまうクセがつきました。 「なんでもおもっど」状態です。 全パスに対するアクセス数をTokyoCabinetに記録したり、 特定のパスに対してはmemcachedから値を取得したり、 Sennaで特定のキーワードにリンクを付与したり、 まあ、やりたい放題です。パフォーマンスも出てます。 ああ毛が立っちゃう。 lighttpdのbufferやarrayを使えば、 メモリリークなどに悩まされることはほぼありません。 意外と安定して開発・稼動できたので正直ビックリしています。 まあ、cookieをパースしたりする便利関数がないので、 そこらへんは根性で書く必要はあります。 どうにかしてくれよ（そろそろ飽きてきた）。 lighttpdのモジュールの欠点は、 ビルドシステムがちゃんとして
何も考えずに $HTTP["host"] == "backend.example.com" { proxy.server = ( "" => (("host" => "127.0.0.1", "port" => 3000))) } などとしてしまうと、$c->uri_forが http://backend.example.com:3000/ になってしまって都合が悪い。、大抵バックエンドには直接リクエストは送れないからね。 で、こんな時はCatalyst側でusing_frontend_proxy を 1（@see Catalyst::Engine::CGI）にして、X-Forwarded-Hostがbackend.example.comになるようにすれば良い。 ApacheやZeusのmod_proxyは自動的にX-Forwarded-Hostを付けてくれるんだけど、Lighttpd（v
Applications Using lighttpd¶ Lighttpd works nicely with most web-projects. To get them setup easily some are providing special lighttpd setups. RubyOnRails Drupal Wordpress Wordpress with permalink structure Trac Mailman Moveable Type 3.2 Using a Perl dispatcher instead of mod_perl¶ I just received a mail from Alex Shah <[email protected]>: I thought you might like to include this in the distribut
This article discusses how to setup lighttpd with the scripts in script/process as introduced in the 0.14.1 release (aka 1.0RC1). I publish this in the hope that it is useful to you but won’t take any guarantees or blames for you screwing up your server. Introduction Welcome to the wonderful world of deploying Ruby on Rails with lighttpd in the 1.0 series. From 1.0 RC1, Rails applications have a s
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
lighttpd-1.5.xから導入される予定のmod_deflateは、 static/dynamicを問わず、レンダリング出力を 圧縮してくれる便利なモジュールですが、 残念ながらlighttpd-1.4.x系では使うことができません。 しかし、非常に便利な機能なので、1.5.x系から バックポートするための様々な試みがなされています。 今回は、lighttpd-1.4.8にパッチを当てて mod_deflateを使う方法を紹介します。 以下のようにlighttpd-1.4.8のソースと、パッチを ダウンロードし、パッチを適用します。 1 # cd /usr/local/src 2 # wget http://www.lighttpd.net/download/lighttpd-1.4.18.tar.bz2 3 # tar xvjf lighttpd-1.4.18.tar.bz2
RailsのFastCGIで動かしてるアプリケーションのconfig(enviroment.rb)やライブラリの再読込って最初やり方が解らずに、lighttpdを毎回毎回毎回再起動というアホらしいことをしていたんだけど、先日RailsFCGIHandlerのソースを見たら特定のSIGNALを送ればいいことが解った。ソースには SIGNALS = { 'HUP' => :reload, 'TERM' => :exit, 'USR1' => :exit, 'USR2' => :restart } と定義されてるている。reloadとrestartの一番の違いはreloadだとライブラリなどの再読込はされるけど、enviroment.rbは再読込されず、restartは両方再読込されることだろう。で、コレを知ってからはアプリケーションがwikiならばwikiがpathに含まれているので $ fo
平素より「PHPプロ！」をご愛顧いただき、誠にありがとうございます。 2006年より運営してまいりました「PHPプロ！」ですが、サービスの利用状況を鑑みまして、2018年9月25日（火曜日）をもちましてサービスを終了させていただくことになりました。 サービス終了に伴いまして、2018年8月28日（火曜日）を持ちまして、新規会員登録ならびにQ&A掲示板への新たな質問、回答の投稿を停止させていただきます。 なお、ご登録いただいた皆様の個人情報につきましては、サービス終了後、弊社が責任をもって消去いたします。 これまで多くの皆様にご利用をいただきまして、誠にありがとうございました。 サービス終了に伴い、皆様にはご不便をおかけいたしますこと、心よりお詫び申し上げます。 本件に関するお問い合わせはこちらよりお願いいたします。
Now, next, and beyond: Tracking need-to-know trends at the intersection of business and technology AI/ML Few technologies have the potential to change the nature of work and how we live as artificial intelligence (AI) and machine learning (ML). Future of the Firm Everything from new organizational structures and payment schemes to new expectations, skills, and tools will shape the future of the fi
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
