ちょっと間が空いてしまいましたが、久々にメモを残しておきます。 Apacheが遅い/止まると言われてしまいまして 現在進めているプロジェクトで、やや大きめのサーバ構築をしてたんですが、ちょくちょく「レスポンスが遅い/Apacheが止まる」と言われてしまい、うーんなんでだろうと色々試行錯誤していたメモ書きです。 ちなみにDBはMySQL-Cluster、サーバサイドはPHPです。 (本当はPound側とかMySQL側にもいくばくかの問題があったのですが、主な問題はここだったのでほかは省略) MPMの話だった 原因に気づいたのはパフォーマンスチューニングの最中でした。Apache Benchでもそもそ検証してたんですが、
Apache で同一IPからの同時接続数を制限するためのモジュールで有名なのが mod_limitipconn です。決められた値以上の同時接続に対しては 503 のステータスコードを返します。 CentOS であれば EPEL から RPM を導入できます。EPEL の利用設定がしてあれば yum でインストールできます。 # yum install -y mod_limitipconn 設定ファイルは /etc/httpd/conf.d/limitipconn.conf です。これを修正します。 MaxConnPerIP 10 <Location /somewhere> MaxConnPerIP 3 NoIPLimit image/* </Location> <FilesMatch "\.(zip|mp?g|iso)$"> MaxConnPerIP 1 </FilesMatch> この
HTTP の持続的接続の功罪について はじめに、HTTP の持続的接続 (keep-alive) のメリットについて。持続的接続を使うメリットは、以下の2点。 TCP 接続の確立にかかる時間の節約*1 TCP の接続と切断に必要な資源 (CPUとネットワーク) の節約 ウェブブラウザ〜データセンタ間の通信で、持続的接続を使う理由は、このうちの前者。特に太平洋を超えるようなケースだと、TCP 接続に0.2秒とかかかるので、メリットが大きい。 一方、持続的接続のデメリットは、 接続が切断されるまでの間、その接続を維持するためにコストがかかる (主としてメモリが無駄になる) という点になる。特に、1プロセス1コネクションを前提とするアーキテクチャ (例: mod_perl) だと、メモリの無駄使いが、とてもひどいことになる。 そこで、ブラウザからの接続を受ける HTTP サーバとアプリケーション
Apache Software Foundationが2月3日、バージョン1.3系最後となる「Apache HTTP Server 1.3.42」をリリースした(SourceForge.JP Magazine、本家/.記事)。 以後、Apache 1.3系に対しては深刻なセキュリティ問題に対するパッチのみを提供するとのこと。Apacheでは2.2系への移行を推奨している。 ただ、さまざまな問題によりApache 2系へのアップデートが難しいユーザーも少なくないのではないだろうか。これからの対処が心配である。 ちなみに本家/.は#31015436にあるように、Apache 1.3.41で稼働しているそうだ。また、/.Jは1.3.34。Apache 1.x系向けのモジュールを使っているため、簡単には2.xに移行できないらしい。
suexecの実行可能なディレクトリ制限って鬱陶しくない? suexec使うからにはセキュリティ上必要な機能だっていうのはわかるんだけど、特にCentOSのhttpdパッケージに含まれるsuexecは「–with-suexec-docroot=/var/www」なんかでコンパイルしてあるもんだから、CentOSの流儀ではsuexecを使用する場合、DocumentRootを/var/www以下に設定しないといけない。 パッケージ如きにディレクトリ・レイアウトを強制されるのもムカつくのだが、じゃあ、最初からパッケージ使わずにソースからインストールすればいいじゃん?というのはごもっともなのだが、やっぱメンテナンス性を考えるとパッケージの利便性を選択してしまう。(昔は何かよくわからずにとりあえず最新を追いかけたかったからソースインストールばかりしてたけど) だったら、せめてSRPMから再ビルドす
HOMMEZ(オムズ)は男性の心と身体の健康を支援し、一人でも多くの人が子供を得る幸せや男性としての喜びを享受できる社会の実現を目指しています。男性の妊活、活力にまつわる情報や商品の力で性や妊活に悩む男性が効率的に納得感を持って活動できる機会を創出します。
Apache 2.0の必須設定と基本セキュリティ対策:実用 Apache 2.0運用・管理術(1)(3/3 ページ) Apache 2.0の基本設定 Apacheの設定のほとんどは、httpd.confだけで行えます。httpd.confを編集することでより高いパフォーマンスを引き出したり、セキュアなサイトを作れるなど、細かな挙動を制御できます。httpd.confの設定は奥深く、それだけを解説した書籍が発行されるほどのボリュームがあります。 ここでは、多岐にわたる設定項目の中から要点をかいつまんで紹介します。なお、ソースからインストールした場合は「highperformance-std.conf」ファイルなど、用途に応じてhttpd.confファイルを選択することもできます。 Webサーバとして最小限やっておくべき設定 httpdデーモン起動の前に、最低限動作に関係するディレクティブを確
Index of /dist/httpd Apache HTTP Server Source Code Distributions This download page includes only the sources to compile and build Apache yourself with the proper tools. Download the precompiled distribution for your platform from binaries/. Important Notices Download from your nearest mirror site! Binary Releases Current Releases Older Releases PGP Signatures Official Patches Name Last modified
おやじのサーバは、家族以外に開放しているわけでもないのですが、家族が勝手に CGI を置くことと、万が一のことを考え suEXEC 環境に移行することにしました。他人にサーバを貸す場合は、ユーザの利便性を保ちつつセキュリティや事故を防止する方法として WWW サーバを suEXEC 環境で動作させるのは非常に有効です。但し、いくつか制約が出てくるので、現用サーバを移行する場合は、十分テストしてから移行することを薦めます。設定ミスだけではなく、プログラムによっては、切り替えた途端に動作しなくなる場合もありますので注意が必要です。 通常、CGI や SSI を実行する場合、WWW サーバと同じユーザ ( apache や nobody 等 )で実行されます。 十分に試験された、あるいは広く流通している CGI ではあまり問題はないでしょうが、ユーザが作成した CGI や SSI を実行した場
suEXEC 機能により、Apache ユーザは Web サーバを実行しているユーザ ID とは 異なるユーザ ID で CGI プログラムや SSI プログラムを実行することができます。CGI プログラムまたは SSI プログラムを実行する場合、通常は web サーバと同じユーザで実行されます。 適切に使用すると、この機能によりユーザが個別の CGI や SSI プログラムを開発し実行することで生じるセキュリティ上の危険を、 かなり減らすことができます。しかし、suEXEC の設定が不適切だと、 多くの問題が生じ、あなたのコンピュータに新しいセキュリティホールを 作ってしまう可能性があります。あなたが setuid root されたプログラムと、それらから生じるセキュリティ上の問題の管理に 詳しくないようなら、suEXEC の使用を検討しないように強く推奨します。 始める前に この文書の
独自ドメインが使えるホスティングサービスは、どのように実現しているのだろうか? その鍵となるのが「バーチャルホスト」である。この機能を使うことによって、1台のマシンで複数のWebサイトを運用できるようになる。 バーチャルホストとは 今回は、Apacheの特徴的な機能の1つである「バーチャルホスト」について解説する。この機能により、少ないリソースで複数のWebサイトを構築することが可能になる。 なぜバーチャルホストが必要なのか 通常、Webサーバへのアクセスにはwww.atmarkit.co.jpやwww.tis.co.jpといったURLが利用される。URLの「atmarkit.co.jp」や「tis.co.jp」の部分はドメイン名、「www」の部分はホスト名と呼ばれる。第2回でも説明したとおり、実際にはURLをIPアドレスに置き換えなくてはWebサーバにアクセスできない。そこで、先方ドメイ
VirtualHostの設定 ■ VirtualHostとは apacheでは、「VirtualHost」を設定することで、アドレスによって設定を分けることができます。たとえば hoge.com、fuga.org、guho.jpはすべて同じサーバを指している http://hoge.com/ /home/hoge/public_htmlを表示 http://fuga.org/ /home/fuga/public_htmlを表示 http://guho.jp /usr/local/wwwを表示 というように、アクセスに使われたサーバ名によって表示する内容(をはじめとする設定全般)を使い分けることができます。 こうすると、あたかも別々のサーバで動いているかのように見せることができます。 ■ 設定 次の設定を、httpd.confに書き加えます。 WebサーバのIPが192.168.1.1である
Summary Any program assigned to the handler fcgid-script is processed using the FastCGI protocol; mod_fcgid starts a sufficient number instances of the program to handle concurrent requests, and these programs remain running to handle further incoming requests. This is significantly faster than using the default mod_cgi or mod_cgid modules to launch the program upon each request. However, the prog
The FastCgiServer directive defines filename as a static FastCGI application. If the filename does not begin with a slash (/) then it is assumed to be relative to the ServerRoot. By default, the Process Manager will start one instance of the application with the default configuration specified (in parentheses) below. Should a static application instance die for any reason mod_fastcgi will spawn an
mod_fastcgiとmod_fcgidは差がなくて、mod_perl/mod_speedycgiが一歩前に出てるという感じですね。worker動作(スレッドモデル)となると、対応しているのは mod_perl2 vs mod_fcgid だけ。mod_perl2 はいかんせん導入が面倒くさいので、手軽さでは mod_fcgid の方がよいのかもしれません。 本格的にパフォーマンスを求めたり、高負荷時のメモリ消費量の少なさを考えると mod_perl2 on worker MPM に優る選択肢はないのですが個人では必要ないでしょう。*2 ただ、どれも Apache にモジュールを組み込まないとならないので、お手軽に高速化したい場合はSpeedyCGI(ソースコード)をオススメします。パフォーマンスも(個人で使うには)十分ですし、Apacheからは完全にcgiとして見えるので(プロセスが完
ここでは、apache のモジュールの追加方法を説明します。 モジュール本体をコンパイルして今のapacheに追加する手順です。 apacheの拡張モジュールをビルドして、インストールしてくれる、apxsという便利なコマンドを使用します。 apxsコマンドは、apacheをインストールした際に、標準でついています。 mod_soというモジュールがapacheに組み込まれていないと、モジュールの追加はできません。 apache2.2.3での説明です。 Last Update : 2006年08月22日 apxsでapacheにモジュールを追加するの手順 mod_so の確認 ソースの用意とコンパイル。(試しに、「 rewrite_module 」を追加) ビルドとインストール httpd.conf の編集 apache 再起動とモジュールの確認 1. mod_so の確認 apacheにmo
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く