今日は技術的な話題です。WebサーバーとしてApacheを使っているときに、「.htaccess」ファイルにたくさん処理を書くと重くなるといわれます。具体的に、どれぐらい遅くなるのでしょうか。試してみました。 .htaccessに2200行ほど書くと1リクエストあたり12ミリ秒の遅延になった一般的には、こう言われています。 .htaccessに処理を書くと、httpd.confに書くのに比べて、Apacheの動作は遅くなる 実際に測定してみた結論から言うと、たしかに遅くなるようです。 具体的には、私が行ったテストでは、.htaccessファイルに2200行ほどの設定を書いた場合、同じアクセス制御をhttpd.confに書いた場合と比べて、中央値で1リクエストあたり12ミリ秒ほど遅くなりました。 致命的だとも言えませんが軽視していいとも言えない速度低下ですね。 この時間はムダなので削りたいで
人間とウェブの未来(旧) 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 これまでのApache2.2系以前でのアクセス制御の書き方は賛否両論でした。僕はあまり好きじゃありませんでした。 過去のアクセス制御に関しては、以下の記事がとてもわかりやすくまとめられていると思います。 こせきの技術日記 – Apacheのアクセス制御をちゃんと理解する。 ここで、以下のように言及されています。 こんなバッドノウハウ、本当はどうでもいいと思う。Apache 3.0では、かっこいいDSL(VCL)で書けるようにする構想があるらしいのでがんばってほしい。 ということで、2.4系ではDSLとはいかないまでも、Require*というディレクティブを使ったモダンな書き方ができるようになったので、それを2.2系以前のアクセス制御の記述と比
先日、SaaSesのOsukini LTを契約。 初めてのVPSなので防備録的に色々書くことにします。 ※ CentOS5の32bitでいろいろ遊んでます。 バーチャルホストでCGIが動かなかったので、 /var/log/httpd/suexec.log を開いてみると command not in docroot (/home/MYDOMAIN/public_html/sample.cgi) だって。 「許可エリアじゃないから、そこじゃCGI動かせねぇよ、バカ」ってことですね、ハイ。 早速、docrootの設定を確認してみましょう。 # cd /var/sbin # ./suexec -V -D AP_DOC_ROOT="/var/www" そりゃ動くわけないですな。 バーチャルホストは/home以下に生成されるので、docrootの設定値は/homeでなきゃいけない。 あ~でもこれって
Apache + PHP-FPMでThread Safetyがdisabledとなる Apache + mod_phpはpreforkで動かす必要があると言われます。 preforkは子プロセスをforkして並べる方式で、起動した子プロセスの数 = 接続数の上限となるので、大量のアクセスをさばきたい場合は子プロセスを大量にforkする必要があり、メモリ効率が悪いし、子プロセスforkのオーバーヘッドが大きいです。 Apacheをworkerもしくはeventにするとやはりプロセスをforkして並べるものの、1つの子プロセスごとにマルチスレッドで複数の通信をさばけるので、メモリ使用率を抑えることができると言われます。 しかし、PHPの公式サイトには http://jp2.php.net/manual/ja/faq.installation.php#faq.installation.apach
こんにちは滝澤です。たまにはapacheネタということで一つ。 Apache HTTP ServerのパラメータチューニングではMaxClientsなどのMPM(マルチ プロセッシング モジュール)関連のディレクティブの設定値を調整することが多いです。本記事ではMPM関連のディレクティブのデフォルト値やディレクティブ間の関係を表にまとめたので紹介します。 注意事項 UNIX系OSにおける説明となります。バージョン2.2系および2.4系の両方について説明します。 関係式においてバージョン2.4系の場合はMaxClientsをMaxRequestWorkersに置き換えて読んでください。 ディレクティブ名には公式サイトのリンクを張っています。公式の説明も確認してください。 デフォルトの欄で括弧付きものはそのディレクティブそのものは設定不可ではあるが、内部的に設定されているデフォルト値を示してい
かなり今更感の漂う内容ではありますが、意外と情報が分散していたり、Apache2.4系を考慮した場合に足りていない内容があったのでこのエントリで一度まとめてみようと思います。 CGIを使うようなシステムでそれなりにアクセスが集中するサーバ、例えば日々のピーク時のApacheのbusyワーカー数が1000になるようなサーバで、かつ、それを処理可能なマシンスペックのサーバであることを前提にしています。 ApacheのMPMとCGI実行アーキテクチャの復習 ApacheでCGIを使う場合には、MPMとCGI実行アーキテクチャの組み合わせは大きく分けて以下の2つに分ける事ができます。 worker(event) + mod_cgid prefork + mod_cgi Apacheの2.4系から特にworker(event) + mod_cgidのモデルが推奨されているようです。また、2.4系では
Apacheのmod_proxyの設定をしたのでメモをする。 今回は、リバースプロキシ+ある特定のパスだけ、除外条件を書いて別サーバーへプロキシした。 インストール takuya@host $ sudo aptitude install apache2 #apache2のインストール takuya@host $ sudo a2enmod proxy #mod_proxyを有効化 takuya@host $ sudo a2enmod proxy_http #httpのプロキシを使う このほかにも proxy_balancer(プロキシ機能を使ったロードバランサ) proxy_ftp ftpサーバーのプロキシ機能がある。 proxy_ajp apache tomcat アプリケーション間通信プロキシなどがある。 proxy_connect #connect メソッド(HTTPSのプロキシで使う
直接公開するサーバがあったり、リバプロ経由で公開するサーバがあったりで、ポリシーがばらばらだったので、統一させることにしました。直接公開がMediawikiだけだったので、Mediawikiを別サーバに移行して、リバースプロキシからプロキシできるようにしました。 環境 Ubuntu 14.04 Apache 2.4 目標 リバースプロキシでBASIC認証して、認証OKなら、認証したUserIDをプロキシ先のMediawikiに渡して、Mediawikiで利用中ユーザとして右上に表示する。 新Mediawikiの構築とデータの移行 まず、新しくMediaWikiを立てた。 立てたらデータ移行する。移行対象は「MySQL」と「添付ファイルを含むディレクトリ」を移行すればうまくいった。 移行元サーバで全DBを出力。(本当はMediawiki関連だけで十分だとは思う) mysqldump -u r
今回やること SSL証明書を使用する場合、Apacheの再起動時に秘密鍵のパスワードの入力を求められます。 開発段階だと、VirtualHostの設定を変更する度に再起動したりすることが多く、一台に複数のアプリケーションを保持している場合は、それぞれのパスワードの入力が必要になります。 これが結構手間で割と安全に省くことができるので紹介します。 現状の確認 CentOS 6.8 Apache 2.2.15 $ sudo service httpd restart Stopping httpd: [ OK ] Starting httpd: Apache/2.2.15 mod_ssl/2.2.15 (Pass Phrase Dialog) Some of your private key files are encrypted for security reasons. In order t
参考サイト1)日々の思考と実験 参考サイト2)おいぬまの覚書 参考サイト3)Directory Index とか 参考サイト4)Debian mongrel_cluster けっこうはまった。ProxyPassが通らない!!こんなエラーが。 [warn] proxy: No protocol handler was valid for the URL /railapps/. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule. 確認の手順 1) /sites-abailabe/mainsite の問題か? mod_proxy 関係の問題かの切り分け /sites-abailabe/mains
問題 apache 2.4.1で、VirtualHostで指定したディレクトリがどうしてもForbiddenになる。 答え アクセス許可の仕方が変わっていた。下のように書き換えたら上手くいきました。 【修正前】 <Directory "/home/www"> Order allow,deny Allow from all </Directory> 【修正後】 <Directory "/home/www"> Require all granted </Directory> apache2.4系では、こんな基本的な設定部分が変わっているんですね。 NameVirtualHostの記述も必要なくなってるようです。 とりあえず全拒否の場合は、以下のように書く。 【修正前】 <Directory "/home/www"> Order deny,allow Deny from all </Direct
セッションのチューニング ここまでのチューニングは、必要か必要でないかを判断すればよく、手探りで最適な値を探し出すというものではなかった。しかし、これから紹介する「セッションのチューニング」はそうもいかない。ある程度の見通しは立てられても、最適な答えを見つけるのには手間がかかってしまう。 KeepAliveとセッションの切断 セッションのチューニングの手始めとして、「KeepAlive」について考えることにしよう。KeepAliveはHTTP/1.1から用意されたもので、クライアントとの接続を保持する仕組みである。HTTPは「ステートレス・プロトコル」と呼ばれるとおり、1回の要求(リクエスト)ごとに接続が切断される。しかし、今日では1つのWebページを表示するために複数のファイルが必要となる場合がほとんどなので、1リクエストごとに接続を切っていたのでは効率が悪い。そこで考え出されたのがKe
2015年3月2日(月) ■ apache の正しい再起動 _ うがー。またやってしまった。これまで何度も何度も同じ罠にひっかかってるのに、いつも後から気がついてやり直してる。ちっとは学習しろや。> 俺 _ apachectl restart は再起動ではない _ SIGHUP を送るだけ。設定の読み直しとログの reopen。親プロセスは生き残る。確実にプロセスを起動しなおしたいなら、restart ではなく stop/start する必要がある。 _ apachectl ではなく、/etc/init.d/ やら /usr/local/etc/rc.d/ やらにあるスクリプトを使う場合も、 case "$1" in ... restart) $0 stop $0 start ;; のようになっていれば restart でいいけど、 case "$1" in start|stop|rest
シンボリックリンク攻撃を防ぐための Apache HTTPD モジュールの解説はこちら: Apache HTTPD: mod_allowfileowner https://fumiyas.github.io/apache/mod-allowfileowner.html 背景 ロリポップの共有 Web サービス下のサイト改ざん事件で、 攻撃手法の一つとして 「他ユーザー所有のファイルへのシンボリックリンクを自分のコンテンツディレクトリ下に作り、Apache HTTPD 経由でアクセスする」手順が利用されたらしい。 参考: http://blog.tokumaru.org/2013/09/symlink-attack.html 当社サービス「ロリポップ!レンタルサーバー」ユーザーサイトへの第三者による大規模攻撃について http://lolipop.jp/info/news/4149/#090
日立オープンミドルウェアは、お客様の既存の財産を生かしながら、高い信頼性と柔軟性、自律性を備えたITシステムの実現を支えています。
なんかcapistranoでmongrelの操作を行おうとした際に、なぜか以下のエラーで失敗する。 *** [err :: 10.7.163.233] Couldn't find any pid file in '/home/troopergreen/www/image/current/tmp/pids' matching 'dispatch.[0-9]*.pid' *** [err :: 10.7.163.233] *** [err :: 10.7.163.233] (also looked for processes matching "/home/troopergreen/www/image/current/public/dispatch.fcgi") *** [err :: 10.7.163.233]本来であれば、{$install_dir}/current/tmp/pids/配下
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く