Catalyst を daemontools で監視しつつ lighttpd の外部 FastCGI で走らせる方法とそのメリット - Craftworks Tech Blog - Branch
JPA セミナーの時に jshery 氏も勧めていましたし、近頃 Geek の話題で目立つようになってきた、Catalyst を mod_perl でなく、外部 FCGI として走らせる設定方法を紹介します。 Catalyst プロセスの起動管理は DJB 氏の daemontools による管理がお勧めです。プロセスが死んでも自動的に再起動してくれます。手動での再起動も楽です。screen からショートカットキー登録して Catalyst を再起動する方法も後ほど紹介します。 Catalyst の FastCGI 起動の設定 まずは daemontools の run スクリプトです。 run #!/bin/sh exec 2>&1 exec env - \ PATH='/bin:/usr/bin:/usr/local/bin:/var/www/www.example.com/scrip
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
lighttpd 2倍成長、7月インターネット - Netcraft | エンタープライズ | マイコミジャーナル
NetcraftがJuly 2008 Web Server Surveyにおいて報告するところによると、サイトベースでのインターネットは相変わらず急成長を続けているようだ。サーバの割合は若干の変化はあるものの先月とほとんど同じ。Apache 49.49%、Microsoft 35.57%、Google 5.70%、lighttpd 1.68%だ。大枠の割合は2007Q4よりほとんどかわっていない。 July 2008 Web Server Surveyで注目すべきはlighttpdが2倍の成長を実現している点にある。lighttpdの割合は1.68%と少ないが、全体でみた場合第4の勢力になっている。軽量高速のWebサーバに対する注目度や運用割合が上がってきているとみれそうだ。lighttpdはYouTube、Wikipedia、Meeboなどで採用されている。
第6回 よりよいパフォーマンスを求めて ～WEBrickからlighttpdへ～ | gihyo.jp
本連載も第6回を迎えましたが、第5回まではどちらかというとRedmineの業務機能面をメインに紹介してきました。今回からはシステム運用担当者向けに、Redmineを題材としてRuby on Railsアプリケーションをどうシステム運用・構築するかといった部分に観点を向け、役立つ情報をご紹介したいと思います。 とはいっても、システム運用という言葉は非常に広義で、本格的に行おうとすると様々な観点がありますが、今回は主にパフォーマンス（性能）向上に話を絞って進めたいと思います。 Redmineをより良いパフォーマンスで動かすためには Redmineを開発プロジェクト等で利用される方も多いかと思います。 特にRedmineは複数プロジェクトに対応したバグトラッキングツールですので、使い方によっては数多くのユーザからアクセスされるシステムとなります。 なので、個人用途で使う場合はそれほど気にしなくて
ajp-wsgiでDjangoを動かす - スコトプリゴニエフスク通信
ajp-wsgi http://www.saddi.com/software/ajp-wsgi/ajp-wsgiはAJPプロトコルでWSGIアプリケーションを動かすためのゲートウェイサーバ。flupと同じようなもの。ajp-wsgiとflupは作者も同じだし、flupもAJPをサポートしているけど、ajp-wsgiはすべてCで書かれているから、flupより速いらしい。作者自身が「もうflupなんて使わねーよww」(意訳)と書いているのを読んだ記憶がある。というわけで、ずっとflupからajp-wsgiに乗り換えたかったのだが、「AJPプロトコルだとフロントはApacheを使わないといけないのか？」と思うと二の足を踏んでいた。 ところが今日、lighttpd 1.5にはAJPプロトコルのProxyがあるということを知り、さっそく試してみた。lighttpd 1.5Subversionでソース
lighttpdに脆弱性、SSLエラーでコネクション切断 | エンタープライズ | マイコミジャーナル
lighttpdにセキュリティ上の問題があることが明らかになった。lighttpd 1.4.19またはそれよりも以前のバージョンにはSSLエラーによって引き起こされるDoS攻撃の脆弱性が存在する。この結果、たとえばダウンロードが完了する前にコネクションが切れるといった問題が発生する。 執筆現在、lighttpdのサイトに修正済みのバージョンは公開されていない。修正パッチを取り込み済みのパッケージシステムからインストールするか、たとえばFreeBSD Ports Collectionで取り込まれたパッチなどを参考にして自身でパッチをあててビルドすればいい。 lighttpdは軽量で高速であるように設計実装されたHTTPdサーバ。ほかのWebサーバと比較してメモリの使用量が少なく、大量の並列アクセスも高速に処理できるという特徴がある。拡張性も高く、パフォーマンスが必要とされる場合に採用対象とし
結局lighttpdからmungrel_clusterに移行
「 lighttpdで稼働しているrailsアプリでリダイレクトが効かなくなった」件だが，結局原因は判明せず。どうもyumの自動更新によってlighttpdがバージョンアップされたらしく，そのタイミングで動作がおかしくなった模様。 apacheとlighttpdの組み合わせは，mongrelの自動機能の設定を行うのが面倒そう，という安易な理由で選んだのだが，やはり世の中はapacheとmongrelの組み合わせが多数派なようである。いつまでも放置していると，ユーザ(とっても目の肥えた数人)に対して非常に恥ずかしく，最悪の場合「Ruby on Railsなんてそんなもんだよね」とか言われてしまうかもしれない。よって，mongrelに運用環境を移行することを決意。 さっそく手順を探していると，とってもよさそうなブログのエントリを見つけた。 「 mongrel_cluster」- バリケンのRu
プログラミングは素晴らしい - [Rails] Rails の動作環境と Location について
最近、プログラミング系のトピックについて全然書いていなかったので、今日は久しぶりに Ruby On Rails について書きます。 今回は複数 Rails 環境を VirtualHost ではなく、Location の違いによって実装する方法についてです。 背景 多くの Ruby On Rails アプリケーションを解説する文章では、virtual host 機能を利用して、/ の Location が Ruby On Rails として使われていることを前提に説明がなされています。 しかしながら、DNS の設定の権限を持っていない場合などでは、virtual host の利用は現実的な解ではありません。他に、http://localhost:3000/ などと、ポート番号指定で行うという方法もありますが、ポート番号指定はあまり好きではない方もいらっしゃるでしょう。そういう人たちのために、
![プログラミングは素晴らしい - [Rails] Rails の動作環境と Location について](https://cdn-ak-scissors.b.st-hatena.com/image/square/cfa89b12da2dca0057619c004dbe11af44691e31/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127082240160%2F17680117127082249643%2F1556344930)
moroの日記 - 動いた！
一昨日からなやんでいた、サブディレクトリ配下でrailsアプリを動かす(1サーバで複数のrailsアプリを動かす)方法ですが、ようやく動きました。 コメントをくださったid:osakanasさん、どうもありがとうございました。 教えていただいたhttp://blog.lighttpd.net/articles/2005/11/23/lighttpd-1-4-8-and-multiple-rails-appsを見ながらやってみました。心残りなのはstrip-request-uriを使ったlighttpd側の設定ではうまくいかず、railsアプリ側での対応となってしまったこと。もうちょっと調べる余地がありそうです。 とりあえずこのへんのテーマでRails勉強会のセッションに立候補してみましたので、興味があるかたはそちらもよろしくお願いします。 このへんはあとでちゃんとまとめまたいと思いますが、
CentOS で構築する自宅サーバ : Apache + lighttpd で Rails を動かす
Ruby on Rails は、圧倒的な開発効率から人気を博している Web アプリケーション・フレームワークですが、いざ本番稼動させる場合、どういった構成で稼動させるかにたくさんの選択肢があり、悩ましいところです。Web サーバに lighttpd を使い、 FastCGI アプリケーションとして動作させるのがひとつの解として少なくない採用を得ていますが、Web サーバ単体として見た場合は、Apache がまだまだデファクトスタンダードの地位にあり、特に Rails アプリケーション以外にも稼動させている Web アプリケーションがある場合は、lighttpd に完全移行するのは難しいのではないでしょうか？ しかし、CentOS 4.x や CentOS 5.x で標準採用されている Apache のバージョンでは、FastCGI の動作に不安がある（不安定である）という声も聞かれます。
LighttpdとFastCGIで、静的・動的ファイルを俺的に振り分ける - ヒルズで働く@robarioの技ログ
あまり「static/以下は静的」みたいな振り分け方は好きではなくて、「拡張子が有ったら静的・無かったら動的」として振り分けるようにしています。 Lighttpd + FastCGIだとこんな感じで「拡張子を含まないリクエストをfastcgiで処理する」という条件でできました。 $HTTP["url"] =~ "/[^/\.]*(\?|$)" { # "/[^/\.]*(\?.*)?$"でもOK fastcgi.server = ( "" => (( "socket" => "/var/run/lighttpd_fastcgi.socket", "check-local" => "disable", )) ) }Apache + ModPerlだと、これとは逆に「全てをmodperlで処理し、拡張子があるものだけはdefault-handlerで処理する」と書かないといけません→Catal
Lighttpd-Catalyst Technique
最小設定 lighttpd.conf server.document-root = "/path/to/root" server.port = 80
ONLamp.com -- The lighttpd Web Server
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ページを開く
CentOS 5 + lighttpd + FastCGI + PHP
ヽ( ・∀・)ノくまくまー(2007-08-20)
IBM Developer
We Ain't Seen Nothin' Yet. : Railsの運用方法紹介ページまとめ
BenCurtis.com » How to serve protected downloads with Rails
運用サーバ速度比較
http://letsgetdugg.com/view/Lighttpd%20Pound_with_Catalyst_or_Mongrel