タグ

apacheに関するatomicmapのブックマーク (31)

  • RTFM

    ドキュメントを読まない輩 結論: ぐぐるな。ドキュメントに書いてあるとわかっているのになぜ google に頼る? 巷間でよく見られる、しかし Apache の配布アーカイブ一式に含まれているドキュメントをちゃんと読んでいれば起きないはずの設定ミスや、ミスではないがふしぎな設定について。 <Limit>: セキュリティ上のリスクがあるのですみやかに確認・修正されたし AddDefaultCharset: 穴ではないが修正が必要 LanguagePriority: ほとんどのサイトでは無意味 ScriptAlias: 管理者でなくエンドユーザがハマるのはしかたないけれど SetEnvIf: どこも間違ってはいないのだが… Apache のドキュメントは日語未訳なところが一部残っているけれど、全体として非常によくまとまった情報源である。少なくとも、「このディレクティブをどう設定するとどう動く

  • Rolling with Ruby on Rails

  • MODULE.JP - 「自信を持ってApacheを操るために」スライド公開

    Internet Week 2005で行ったチュートリアル「自信を持ってApacheを操るために」で使用したスライド資料をPDFで置いておきます。資料だけ見ると役に立つところが少ない、というかワケワカメですな。 Internet WeekのWebサイトでも後々資料の配布とビデオ配信される予定ですが、少し時間がかかると思うので先行してこちらに置いておきます。 T16:自信を持ってApacheを操るために 〜内部構造からたどるWebサーバ設定のキモ (PDF 800Kbyte) チュートリアルの概要についてはInternet Week 2005 Webサイトのプログラム詳細をご覧ください。当日お越しいただいた皆様、ありがとうございました。

  • YappoLogs: Apache 2.2.0 のロードバランス機能(mod_proxy_balancer)を使いこなす

    Apache 2.2.0 のロードバランス機能(mod_proxy_balancer)を使いこなす Apache 2.2がでました。 mod_dbdとか、mod_proxy_balancerとか気になる新機能てんこ盛りです。 ひげぽんさんの所に 誰か入れてみた人いますか? と有ったのでmod_proxy_balancerを試してみました。 超簡単でした mod_proxyとmod_proxy_balancerを参考にしました。 既に日語ドキュメント完備! 以下から駆け足で、またセキュリティ的によろしくない設定例が多々あります。 とりあえずこんな設定を仕込んでみました ProxyPass /lb balancer://TEST stickysession=sesid <Proxy balancer://TEST> #1 BalancerMember http://i.yappo.jp lo

  • mod_uploader

    ● [Apache] mod_uploader Rails の Upload progress 問題を調べているうちに mod_uploader という Apache ライブラリを発見しました。公式サイト等にある特徴をまとめると Apache のモジュールとして C++ で記述されているので,PerlPHP で作られた物に比べて高速. (表示は Pentium4 3G で 2000 req/sec さばけます) ファイルのアップロードおよび,ダウンロード以外では Disk IO が発生しないので HDD に優しい. 独自の簡易スクリプト言語によるテンプレート機能があるので,再コンパイル無しで手軽に見た目を変更可能. メモリを圧迫せずに巨大なファイルのアップロードが可能. Upload progress 表示が可能. 静止画、動画のサムネイル表示が可能. (それぞれ Image

  • 川o・-・)<2nd life - Visitors, a fast web log analyzer

    http://www.hping.org/visitors/ 高速なapache log analyzer。公式には No installation required, can process up to 150,000 lines of log entries per second in fast computers (20MB/s with my log files average length). と、一秒で150,000行さばけるとうたっている。うちの環境で実際に10万行ほどのログをわせたところ1秒ちょいと非常に高速にさばけた。出力ではhtml(サンプル)だけならずテキスト(サンプル)も選べる。 ログアナライザとして必要な機能は一通りそろってるし、Googleからの検索キーワードも表示できてGood。日語検索ワードだとeuc-jpやsjisやutf-8だったりするのでnkfをか

    川o・-・)<2nd life - Visitors, a fast web log analyzer
  • Techknow Movable Type: Apache 2.0 mod_proxy によるリバース・プロキシの構築

  • Apache 2.0のfilterを調べる - higepon blog

    最終目標 Apacheがクライアントに対して送信(出力)したContentを自作モジュールから参照したい。 filter? Apache 2.0に実装されたfilterを使用すればこれが実現できそうだ。ということでいろいろ調べています。 まずは公式ドキュメントを読み始めるも意味がよくわからん。 →How filters work in Apache 2.0 - Apache HTTP Server(英語) filterには protocol filter と resource filter の2種類があるようだ。 んで、多分目的のものは resource filter かな?。 勝手なイメージだが filter関数をフックしておくと何かのタイミングで Apacheの中の人が呼び出してくれるのだろう。 mod_deflateが filter を使っているっぽいのでソースを見てみる(Apach

    Apache 2.0のfilterを調べる - higepon blog
  • Poundで作るロードバランサとSSLラッパ(1/4) ― @IT

    Webサーバの負荷を軽減する方法として、リバースプロキシによる代行とロードバランサによる分散が考えられる。今回は、これらによる負荷の低減方法について解説する。(編集部) Apache自体のチューニングによる性能向上には限界があります。よりパフォーマンスを求めるなら、次にやるべきことはメモリの追加や高性能なCPUへの交換など、ハードウェアの見直しです。しかし、それにも限界があります。 リバースプロキシとロードバランサ ハードウェア単体による性能向上が限界に達した場合は、サーバ構成の見直しを行います。まず考えられるのが、リバースプロキシをWebサーバの前面に立ててクライアントからのアクセスを肩代わりさせる方法です。Webサーバがボトルネックになるのを防ぐとともに、セキュリティ向上にも寄与します。 もう1つの方法は、より高可用性を意図した構成として負荷の分散を図ることです。高可用性とは、サーバの

    Poundで作るロードバランサとSSLラッパ(1/4) ― @IT
  • Perl の use と mod_perl、あと LLDN 感想ちょっと。 - naoyaのはてなダイアリー

    それとperlのuseってどういうものなのか解らないんだけど、FastCGIのようなプロセス常駐させている場合、rubyのrequire*2したものがプロセスで共有されてて次回の起動コストはかからないんだけど、それとは違うのかな? use するとこんないいことがあるんだよ、って書こうとしたら引用もとのコメントに miyagawa さんが書いてた。二つあるけど、どっちかというと大きいのは mod_perlのスタートアップ時にロードしてforkしたchild間で共有してメモリ消費を減らせる(シングルスレッドなFastCGIなら不要?) ここですね。 mod_perl だと、リクエスト毎に子プロセスを生成してリクエストに応じてプロセスを生成しそれに応答、あとはそのプロセスを使いまわすわけなんですが、use と require の違いが、子プロセスのメモリサイズに大きく影響してきます。 miyag

    Perl の use と mod_perl、あと LLDN 感想ちょっと。 - naoyaのはてなダイアリー
  • mod_deflateによるコンテンツの圧縮転送

    サーバのマシン性能は十分でも、コンテンツの転送時間がボトルネックとなってパフォーマンスが出ない場合がある。このようなときの対処法として、コンテンツの圧縮転送がある。(編集部) 前回に引き続き、Apacheのパフォーマンスチューニングについて解説します。今回はナローバンドで効果を上げる、コンテンツ圧縮機能を取り上げます。 回線のボトルネック解消 ブロードバンドが広く普及したとはいえ、携帯インフラなど依然ナローバンドが主流の分野もあります。そして、Webサーバ自身のパフォーマンスよりも、回線のボトルネックがレスポンスに大きく影響を及ぼすことがあります。例えば、ダイヤルアップで多くのユーザーがApacheに接続した場合、1つの接続が占有するCPU時間が長くなるため、同時接続数が増大する傾向にあります。 このような場合は、限られた回線帯域を有効に利用するために、送信データの圧縮転送で状況の改善を図

    mod_deflateによるコンテンツの圧縮転送