Kazuho@Cybozu Labs: キャッシュの上手な使い方
« C-0.05 | メイン | cygwin + mod_perl » 2006年02月08日 キャッシュの上手な使い方 キャッシュといっても、ウェブブラウザやウェブプロキシのキャッシュのことです。 ・Internet Explorer のキャッシュの動作 Internet Explorer は、同一ウィンドウ内で複数回同じウェブページを読み込む場合、２回目以降はキャッシュのデータを使用します (デフォルト設定の場合、 Last-Modified または Expires ヘッダがついている場合のみ)。 つまり、同じウィンドウの中で、 ページA を読み、次にページB を読み、そしてページA を再び読み込むようなケースでは、２回目にページ A を表示する際にはキャッシュのデータが使用され、ウェブサーバへの再問い合わせは行われません。 また、 Last-Modified ヘッダと Expire
Apache 2.2でWebサイトをパフォーマンスアップ！（1/3） ― ＠IT
■ドキュメントキャッシュ機能の見直し メモリキャッシュやディスクキャッシュなど、HTTPコンテンツの動的キャッシュ機能が強化されました。開発バージョン時よりも安定性が向上し、Apache 2.2では実用的なレベルになっています。キャッシュ機能を用いることで、一般的にHTTPサービスの応答性を向上させることができます。 また、Apacheをリバースプロキシサーバとして利用する場合もキャッシュ機能を利用可能です。 ■プロキシ機能によるロードバランシングの実現 プロキシでロードバランス機能を実現するmod_proxy_balancerモジュールが追加されました。HTTPやFTPサービスはもちろん、Apache Tomcatなどのサーブレットコンテナとの通信で使われるAJP13プロトコルのロードバランス機能も提供します。 バランシングの制御は、「リクエスト回数」と「トラフィック量」の2つのアルゴリ
GET と POST, Apache1.3系 と Apache2.X系 - inuzのブログ
HTTPで何かのコンテンツを取得するのは普通 GET だけれど、 POST /path/to/file.html HTTP/1.0(改行) (改行)こんなことをやるとどうなるか、という話。 POSTメソッドというのは、情報をサーバに送りつけるためのメソッドであって、コンテンツを取得するための物ではない。なので、POST本来の意味において、上記枠内のようなリクエストは不正であると言わざるをえない。何にも情報を送ってないからね。204 No Content なんていうHTTPステータスコードが、"コンテンツはないよ"なのに、204 なのは純粋にPOSTが情報を送るためのメソッドである証拠と言えましょう(2で始まるステータスコードはオッケーの証)。この話のネタ元の人によると、これは「エラーになった」とのこと。エラーってどんなだろう？と思ってかるくテストしてみたら、これがわりと面白かったので掲載。
cyano: mod_proxy_balancerで中〜大規模サーバー運用するときの勘所 - (1) mod_proxy_balancerの設定編
mod_proxy_balancerで中〜大規模サーバー運用するときの勘所 - (1) mod_proxy_balancerの設定編 Apache2.2から、ロードバランシングをしてくれるmod_proxy_balancer というモジュールが標準添付になりました。 このモジュール、その名前の通り、ApacheレベルでHTTPリクエストをバックエンドのサーバーに振り分けることでロードバランシングをしてくれるモジュールです。 Apacheの公式ドキュメントや試しに入れてみた人のBlogなどは散見されますが、実際の現場で運用している事例というのはまだ無いようです。 そこで、実際にピーク時にover 500 request/secでmod_proxy_balancerなサーバーを運用している経験をふまえ、つまずいた点などを公開していきたいと思います。 まず、mod_proxy_balancerの
ベイエリア情報局: Yahoo でカスタマイズされた apache のまとめ
元Vine SPARC開発者。2003年度未踏ユース採択者。海外でも活躍できる国際的なLinuxエンジニアになることを夢見て日本で頑張っています。ウノウ株式会社にて写真共有SNS「フォト蔵」を開発中。 Yahoo で使用されている独自カスタマイズされた apache についてのプレゼンテーション資料が公開されていたので、自分なりにまとめてみました。 Hacking Apache HTTP Server at Yahoo! HTTPヘッダーの "Server:" は出力しない apache 1.3 がベース 安定動作が重要 スレッドは使用しない(動作が複雑) ログフォーマットは独自フォーマット ログローテンションは独自の仕組みを持つ。シグナルもパイプも使用しない レスポンスコード 30x は最小限のものだけ出力 コンテンツは gzip 圧縮して出力(HTTP/1.1)。CPU 使用率が 90
Hidayet Doğan · PHP ve buna benzer şeyler hakkında
Yazdan bu yana özet gelişmeler… (Güncellendi) 07 Feb 2013 Bu yazı eski blogdan arşiv amaçlı alınmış olduğu için içerikte tutarsızlıklar olabilir. Uzun süredir bir şeyler yazamamıştım, en son Linux Yaz Kampı (Temmuz 2012) sonrası neler yaptım neler buldum kısaca bir özet geçeyim. Hem kendim için de bir hatırlama listesi olur. Etkinlik olarak 7-9 Kasım 2012, Eskişehir Anadolu Üniversitesi’nde gerçek
RTFM
ドキュメントを読まない輩 結論: ぐぐるな。ドキュメントに書いてあるとわかっているのになぜ google に頼る? 巷間でよく見られる、しかし Apache の配布アーカイブ一式に含まれているドキュメントをちゃんと読んでいれば起きないはずの設定ミスや、ミスではないがふしぎな設定について。 <Limit>: セキュリティ上のリスクがあるのですみやかに確認・修正されたし AddDefaultCharset: 穴ではないが修正が必要 LanguagePriority: ほとんどのサイトでは無意味 ScriptAlias: 管理者でなくエンドユーザがハマるのはしかたないけれど SetEnvIf: どこも間違ってはいないのだが… Apache のドキュメントは日本語未訳なところが一部残っているけれど、全体として非常によくまとまった情報源である。少なくとも、「このディレクティブをどう設定するとどう動く
MODULE.JP - 「自信を持ってApacheを操るために」スライド公開
Internet Week 2005で行ったチュートリアル「自信を持ってApacheを操るために」で使用したスライド資料をPDFで置いておきます。資料だけ見ると役に立つところが少ない、というかワケワカメですな。 Internet WeekのWebサイトでも後々資料の配布とビデオ配信される予定ですが、少し時間がかかると思うので先行してこちらに置いておきます。 T16:自信を持ってApacheを操るために 〜内部構造からたどるWebサーバ設定のキモ (PDF 800Kbyte) チュートリアルの概要についてはInternet Week 2005 Webサイトのプログラム詳細をご覧ください。当日お越しいただいた皆様、ありがとうございました。
mod_uploader
● [Apache] mod_uploader Rails の Upload progress 問題を調べているうちに mod_uploader という Apache ライブラリを発見しました。公式サイト等にある特徴をまとめると Apache のモジュールとして C++ で記述されているので，Perl や PHP で作られた物に比べて高速． (表示は Pentium4 3G で 2000 req/sec さばけます) ファイルのアップロードおよび，ダウンロード以外では Disk IO が発生しないので HDD に優しい． 独自の簡易スクリプト言語によるテンプレート機能があるので，再コンパイル無しで手軽に見た目を変更可能． メモリを圧迫せずに巨大なファイルのアップロードが可能． Upload progress 表示が可能． 静止画、動画のサムネイル表示が可能． (それぞれ Image
[_11_Install] intel compiler で Apache が 400% 高速化
「無料で30%のパフォーマンスUP!! - intel compiler」でも書いた intel compiler ですが、apache1.3.33 + mod_perl 1.29 を再構築してみました。apache bench で速度を測ってみたら、ナント 400% も高速化していました。?(￣□￣;)ﾅﾝﾄ!! 本当かぁ？？と思って数回試してみましたが、結果は同じでした。スゴイ！ 以下、インストールメモとapache bench のログです。 mv /usr/bin/gcc /usr/bin/gcc.bk ln -s /opt/intel_cc_80/bin/icc /usr/bin/gcc mkdir /usr/local/src/icc cd /usr/local/src/icc wget http://www.meisei-u.ac.jp/mirror/apache/dist/h
情報処理推進機構：「Tomcat」におけるリクエスト処理に関する脆弱性に関する解説.
本資料は、JVNで公表した「JVN#79314822：『Tomcat』におけるリクエスト処理に関する脆弱性」について解説するものです。 「Apache Tomcat」（以下 「Tomcat」）は、サーバ上で Java アプリケーションを動作させるためのソフトウェアです。Java サーブレット仕様と JavaServer Pages 仕様のリファレンス実装となっています。 「Tomcat」には、ウェブサーバと連動する機能があります。AJP (Apache JServ Protocol) 1.3 は連動のためのプロトコルの一つで、AJP 1.3 Connector (org.apache.ajp.tomcat4.Ajp13Connector) は AJP 1.3 を使用するコネクタの一つです。このコネクタを使用した場合、「Tomcat」はウェブサーバから AJP 1.3 リクエストを受け取り、
lighttpd + FastCGI は mod_perl + Apache1.3 より１割ほど高速 :: Drk7jp
巷で超高速 Web サーバとして話題になっている lighttpd を試してみました。lighttpd に関する日本語ドキュメントは非常に少なく、ちょっと込み入った設定ファイルの記述方法とかの解析に手間取りました。 lighttpd のコンセプトは、「セキュアで省メモリで高速に動作し、柔軟性もある」なのですが、「lighttpd 公式サイトのベンチマーク結果」や「UnknownPlace. - Catalyst ベンチ」で簡単な Catalyst - Hello.cgi のベンチマークが公開されているとおり、Apache 1系、Apache 2系よりも高速に動作するようです。特に static なページの処理は Apache の 2〜3 倍程度は高速に処理できるみたいです。 また注目すべき点として、Apache + mod_perl よりも lighttpd + FastCGI の方が１割
Web Server
全世界的に、Web サーバーとしては Apache が一番多く使われています。その Apache を利用する際になるべく最適な環境を作る方法についてまとめてみます。 1. はじめに Apache の設定ファイルは、httpd.conf、srm.conf、 access.conf と三種類ありますが、最近のバージョンではほとんど httpd.conf のみで行います。Apache 2.0 では、srm.conf, access.conf は無くなります。そこで、設定はすべて httpd.conf で行なうものと思って作業してください。 2. Apache のチューニング（httpd.conf） 設定ファイルでは、幾つかディレクティブがあります。その中で注意して設定することで、Apache を最適に動作させるディレクティブ説明と方法を記述します。 2.1. HostnameLookups
mod_ssl - Apache HTTP Server Version 2.4
Summary This module provides SSL v3 and TLS v1.x support for the Apache HTTP Server. SSL v2 is no longer supported. This module relies on OpenSSL to provide the cryptography engine. Further details, discussion, and examples are provided in the SSL documentation. Environment Variables This module can be configured to provide several items of SSL information as additional environment variables to th
mod_authz_iplist - なんとなく◎
mod_authz_host / mod_access による Deny や Allow のようなアクセス制御のために用います． Deny や Allow は .htaccess などに直接記述しますが， このモジュールでは IP アドレスやホスト名は別ファイルに記述します． .htaccess での Deny / Allow の記述はリクエストがある度に読み込まれパースされるが， このモジュールでは規制リストはファイル更新が検出されるまでメモリ上にキープされるため， 特に記述する IP アドレスやホスト名が多い場合パフォーマンス面で有利になる． 規制対象の IP アドレスやホスト名を動的に変更する場合， 規制リストが .htaccess とは別ファイルなので .htaccess を 直接書き換える場合よりもトラブルが発生しにくい． といったメリットがあります． このモジュールはマルチスレ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
39154 – Problem with webdav over SSL with client certificate autentication
*失 言 小 町* - はてなはパスワードを生データで管理してる？
12355 – POST incompatible w/ renegotiate https: connection
黄金城hjc30vip5678(中国)有限公司
Bugtraq