タグ

apacheに関するmyfinderのブックマーク (30)

  • Contextの生成・破棄を任意のタイミングで制御可能にする Scope::Container(仮) - blog.nomadscafe.jp

    追記 CPANリリースしました http://search.cpan.org/dist/Scope-Container/ /追記 mod_perl のアプリケーションでは、Apacheモジュールの提供するpnotesを使うとリクエスト毎のデータを簡単に持つことができます。pnotesに入れたデータはリクエストの処理が終了したところで自動的にクリーンアップされます。これを利用したのがリクエストごとにインスタンスを作成破棄できる、Apache::Singleton(::Request)です。 また、pnotesはデータベースの接続の管理にもしばしば使われます。1リクエストを裁いている間だけデータベースとの接続を維持し、リクエストが完了したところで接続を閉じるような処理に利用されています。このようにすることでmod_perlのプロセス数分(数百)の接続がMySQLに常に張られることもなく、また1

  • 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

    Apache, Lighttpd, nginx における持続的接続と lingering close の実装について - kazuhoのメモ置き場
  • Test::Apache::RewriteRules で mod_rewrite のテストを書こう - 大西日記 - はてなダイアリー

    YAPC::Asia Tokyo 2010 で LT してきました。以下はその資料(に少し説明を追加したもの)です。 mod_rewrite 正規表現によるURL書き換えモジュール スイス製アーミーナイフ / 黒魔術 まだ Apache 使ってますよね? reverse proxy とか… はてなの mod_rewrite 活用事例 ほぼ reverse proxy URLにより用途別のbackendに振り分ける 用途によりbackendを分けリソース効率化 特定のアクセスをキャッシュサーバーに振る URL加工 Squidにキャッシュさせたいが同一URLで異なるコンテンツを返す場合がある →クエリに情報を付加する BAN! 便利な半面… 増える! $ cat jp.www.proxy.apache.conf | grep Rewrite | wc -l 179 テストしづらい! → 一行加

    Test::Apache::RewriteRules で mod_rewrite のテストを書こう - 大西日記 - はてなダイアリー
  • HadoopによるApacheのログ解析の実際

    こんにちは、ミツバチワークス stoneです。 今日は、DECOLOGで行われている、Apacheのログ解析について、 ご紹介してみようかと思います。 現在、DECOLOGでは、リバースプロキシが8台あって、 その8台の1日のApacheのログは、全部で、200Gバイト以上になっています。 これを、13台のHadoopのスレーブノードで解析を行っています。 全体の流れとしては、 1) リバースプロキシからHDFSにログを転送 2) 解析用のサーバーで、HDFSにログの転送が終わるのを監視 3) ログの転送が終わったら、Hadoopを起動、解析 4) Hadoopの解析結果をデータベースに保存 以下では、各々のステップを個別に見て行くことにしますね。 1. リバースプロキシからHDFSにログを転送 当初、Hadoopのプロセスが立ち上がっていないと、HDFSにはアクセスできない、 と思い込ん

  • く、くやしい・・・foregroundで起動できるなんて・・・ビ - (ひ)メモ

    2009-12-15 追記 nginxのオプションが間違ってたので修正>< × -g daemon=off ○ -g "daemon off;" 2009-12-16 追記 Apacheのrunファイルにpgrphackと補足文を追加。 daemontoolsのrunファイル。 Apache #!/bin/sh exec 2>&1 CONF=/usr/irori/etc/apache/httpd.conf DAEMON=/usr/local/app/apache/bin/httpd DAEMON_ARGS="-f $CONF -DNO_DETACH -DFOREGROUND" if [ ! -x "$DAEMON" ]; then echo "not executable: $DAEMON" exit 1 fi if ! $DAEMON $DAEMON_ARGS -t; then echo

    く、くやしい・・・foregroundで起動できるなんて・・・ビ - (ひ)メモ
  • プロのサーバ管理者がApacheのStartServers, (Min|Max)SpareServers, MaxClientsを同じにする理由 - blog.nomadscafe.jp

    kazuhoさんが「プロのサーバ管理者の間では存在価値が疑問視されて久しい (Min|Max)SpareServers だと思う」と書いたり、hirose31さんが去年のYAPC::Asiaで{Start,{Min,Max}Spare}Servers,MaxClientsは同じにしているよと発表したり、実際前職のサーバはそのように設定されていたのですが、自分でうまく説明ができてなかったので、調べながら書いてみた。 当はイントラブログ用に書いていたものですが、がんばったので転載。 前提として、CPUの使用率におけるsystemとfork Re: クラウドがネットワークゲーム開発者にもたらしてくれたもの - blog.nomadscafe.jpでも書いている通りforkってのはサーバにとって重い部類の処理になります。つまり負荷の高いときにforkを大量に行うのはしてはならないことの1つです。

  • Apache の起動 - Apache HTTP サーバ

    Windows 上では、Apache は通常は Windows NT, 2000, XP ではサービスとして、Windows 9x, ME ではコンソールアプリケーションとして実行されます。 詳細に関しては、「 サービスとして実行する」と「 コンソールアプリケーションとして実行する」をご覧下さい。 Unixでは、httpd プログラムが、バックグラウンドで常にリクエスト処理を行う デーモンとして実行されます。この文書ではどのように httpd を起動するかについて記述しています。 Apache の起動方法 もし、設定ファイル中で指定されている Listen がデフォルトの 80 (もしくは 1024 以下の他のポート) である場合は、Apache を起動するためには root 権限が必要になりますが、 これはこの特権ポートにバインドするためです。 起動して、一度ログファイルを開くといった準

  • 2010年代には Apache の mpm_prefork とか流行らない (もしくは HTTP keep-alive のメリットとデメリット) - kazuhoのメモ置き場

    HTTP の持続的接続の功罪について はじめに、HTTP の持続的接続 (keep-alive) のメリットについて。持続的接続を使うメリットは、以下の2点。 TCP 接続の確立にかかる時間の節約*1 TCP の接続と切断に必要な資源 (CPUとネットワーク) の節約 ウェブブラウザ〜データセンタ間の通信で、持続的接続を使う理由は、このうちの前者。特に太平洋を超えるようなケースだと、TCP 接続に0.2秒とかかかるので、メリットが大きい。 一方、持続的接続のデメリットは、 接続が切断されるまでの間、その接続を維持するためにコストがかかる (主としてメモリが無駄になる) という点になる。特に、1プロセス1コネクションを前提とするアーキテクチャ (例: mod_perl) だと、メモリの無駄使いが、とてもひどいことになる。 そこで、ブラウザからの接続を受ける HTTP サーバとアプリケーション

    2010年代には Apache の mpm_prefork とか流行らない (もしくは HTTP keep-alive のメリットとデメリット) - kazuhoのメモ置き場
  • 今からでも遅くない、本当に明日使えるApache mod_rewriteの小ネタ - (ひ)メモ

    RewriteCondでは、日時の情報も使えるので: RewriteEngine On RewriteCond %{REQUEST_URI} !^/0401/ RewriteCond %{TIME_MON}%{TIME_DAY} 0401 RewriteRule . /0401/ [R,L]enjoy! 追記 (2010-04-01) あわせて読みたい、というかこっちの方がちゃんと解説してあります。 mod_rewriteで期間指定のリダイレクト | gmt-24.net "<"や">"と[OR]を使って、日時の範囲を表現しています。すらばしす。 蛇足ですが、 RewriteCond ...1 RewriteCond ...2 RewriteRule ...3という書き方をしますが、マッチんぐの検査順は、上から順に RewriteCond ...1 RewriteCond ...2 Rew

    今からでも遅くない、本当に明日使えるApache mod_rewriteの小ネタ - (ひ)メモ
  • Apache, Cache-Control, 304, 大型サイトで静的ファイルを無駄なく配信 | バレで昼寝

    以前にも書きましたが私は某ポータルサイトのシスアド、兼プログラマをしています。月々1億から3億ページビューを裁いていますが、システムの一番大きなコストはトラフィックです。 100MBit専有とまでなると月40万は軽く行きます。そこでとにかくページビューをあげながらもトラフィックを減らそうと日々努力しています。この記事の目的はハウジングサービスからアマゾンのクラウドフロントに移行した成功例(または失敗例)について書いていきます。 まず、第一回は既存のシステム(静的ファイル用のサーバ)について簡単に説明します。長年、経験を積みながら行った設定です。あくまでも、サーバのスペック、サイトの用途によっても違ってきます。 OS: Gentoo HTTP Server: 最近lighttpdからまたApacheへ ※lighttpdはものすごくライトウェイトだが、バグの対応が遅い、ガンバレMade

  • Perl-Catalyst/環境設定/FastCGI/mod_fastcgi - yanor.net/wiki

    mod_fastcgi Apache + mod_fastcgiを使ってCatalystを動かす。 Apacheの設定 Apacheとfastcgiが通信する方法はいくつかあるが、ここでは外部サーバ方式を採用する。 以下はhttpd.confの一部。 <IfModule mod_fastcgi.c> FastCgiExternalServer /tmp/test1.fcgi -socket /tmp/test1.socket -idle-timeout 120 FastCgiExternalServer /tmp/test2.fcgi -socket /tmp/test2.socket -idle-timeout 120 </IfModule> <VirtualHost *:80> RewriteEngine on RewriteRule ^/(.*) /tmp/test1.fcgi/$1

  • Apacheの設定を変更し、単一IPアドレス上で複数のSSLサイトを運用する - builder by ZDNet Japan

    Apacheのバージョン2.2.12以降では、SNI(Server Name Indication)という、SSLプロトコルに対する拡張機能がサポートされているため、名前ベースのHTTPサイトを設定する場合と同じように名前ベースのHTTPSサイトを設定することが可能になっている。記事では、Apacheのこの機能について紹介する。 Apache Webサーバがバージョンアップし、成熟していくに伴い、新機能の追加やバグの修正が行われてきている。そして、バージョン2.2.12で追加された機能のうち、最も重要なものはおそらく、単一IPアドレス上で複数のSSLサイトを運用できるようにするという、長らく持ち望まれていた機能だろう。 これまでは、特定のIPアドレスに対してSSL対応のWebサイトを割り当てた場合、そのサイト1つしかSSL対応のWebサイトを運用することができなかった。つまり、IPアドレ

    Apacheの設定を変更し、単一IPアドレス上で複数のSSLサイトを運用する - builder by ZDNet Japan
  • Kazuho@Cybozu Labs: Apache で X-Reproxy-URL ヘッダを使えるようにするモジュール mod_reproxy を書いた

    ウェブアプリケーションにおいて、認証がかかっている画像や大きなファイルを配信する場合には、Perlbal 等でサポートされている X-Reproxy-URL ヘッダが有効なことが知られていて、その理由としては、 (メモリを大いする) アプリケーションサーバのプロセスを転送終了まで占有しない HTTP ベースの分散ファイルシステムとリバースプロキシが直接交信するので、ネットワーク負荷が低い といった点が挙げられます。「でも、Apache は X-Reproxy-URL ヘッダをサポートしてないんだよねー」という話が、先日の YAPC::Asia 2009 においても話題になっていました[要出典]。回避策としては、ワンタイムURLのような手法もあるのですが、セキュリティな懸念もあります。 なんとかしたいなと思っていたのですが、気が向いたので、Apache に X-Reproxy-URL ヘッ

  • mod_perl 2.0 の Server Life Cycle - daily dayflower

    mod_perl 2.0 のサーバ起動にまつわる文書を読み込んでいました。 サーバスタートアップスクリプトは,1.0 時代のドキュメントでは「PerlRequire」記述子で読み込むように書かれていることが多いが,実行される時点が中途半端。なので,PerlPostConfigRequire を使う方が吉。もし設定ファイル自体で Perl の機能を利用しているのであれば(普通そこまでコアなことやらなくて済むんだけど),PerlConfigRequire を使うとサーバ設定フェイズ(すなわちかなり早い段階)で実行される。 Apache 2.x では,graceful restart がうまくいくことの確証を得るために,一度サーバ設定フェイズが終わると,Apache 自身を再起動する。ということは,サーバ起動時に,スタートアップスクリプト等は 2 回実行される。このことで困るってことはたいていな

    mod_perl 2.0 の Server Life Cycle - daily dayflower
  • Catalyst::Manual::Cookbook::Deployment - libnitsuji.so

    Cookbook長いので分割。 デプロイについてのレシピ。Webサーバーエンジンとアプリケーションの効率化も含む。 http://search.cpan.org/~jrockway/Catalyst-Manual-5.700701/lib/Catalyst/Manual/Cookbook.pod#Deployment mod_perl Deployment mod_perlは多くのアプリケーションに対しての最適解だけど利点と欠点を述べる。他の方法としてはFastCGIがある。 Pros Speed mod_perlはとても高速で、それぞれのApacheプロセスのメモリにアプリケーションをロードすることによって恩恵を受けられる。 Shared memory for multiple apps 同じサーバーで複数のCatalystアプリケーションをする必要がある場合、mo_perlは共通のモジ

    Catalyst::Manual::Cookbook::Deployment - libnitsuji.so
  • 迷惑メール・電話対策本部

  • mod_fastcgi

    http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html http://www-306.ibm.com/software/webservers/httpservers/doc/v2047/manual/ibm/en_US/9acdfcgi.htm 日語訳が某所にあったのをgoogle経由で見つけたのですが、どうも、非公開っぽいものだったらしく、現在は403になってしまったので、その元となった英語マニュアルにリンクし直しました。 fastcgi.comのものには、suexec関連の記述が抜けているので、こっちの方が良いかもしれません。 「9acdfcgi」で検索すると、日語訳も、アチコチで発見できる様子……。合法かどうかは知らないが。 折角なので、今まで自分がmod_fastcgiを使ってきたノウハウ(という程のモノでもないが)を書

  • MacOSXでサーバー稼業 : パーソナルWeb共有をhttps接続できるようにしよう

    クリックで手軽にiOSやMacと親和性の高いサーバー運用ができる、そんな夢を背負ってデビューしたServer.appは、気がつけば、その役割を縮小し細々とした存在になってしまいました。同時に、その掲げられた夢にすがって恩恵を受けていたユーザーたちは、路頭に迷う時代になりました。 中小オフィス向けサーバーを簡単に構築、管理できるという位置づけでのServer.appの提供はなくなりました。しかし、その向こう側には、かつてと変わらないパワフルな環境が引き継がれています。ここでは、Server.appに頼らず、macOSの基構成を中心に、ちょっと小さなオフィスや自宅向けのサーバー環境を構築、運用する方法を考えていきます。

  • macOSでサーバー稼業 & どうせ疲れるなら、できあがったものをどう活かすかで疲れたいよね

    クリックで手軽にiOSやMacと親和性の高いサーバー運用ができる、そんな夢を背負ってデビューしたServer.appは、気がつけば、その役割を縮小し細々とした存在になってしまいました。同時に、その掲げられた夢にすがって恩恵を受けていたユーザーたちは、路頭に迷う時代になりました。 中小オフィス向けサーバーを簡単に構築、管理できるという位置づけでのServer.appの提供はなくなりました。しかし、その向こう側には、かつてと変わらないパワフルな環境が引き継がれています。ここでは、Server.appに頼らず、macOSの基構成を中心に、ちょっと小さなオフィスや自宅向けのサーバー環境を構築、運用する方法を考えていきます。

  • bayashi.jp

    This domain may be for sale!