一定期間更新がないため広告を表示しています
はじめに † apache2のインストールについて 大体、ここに書いてある通りです。 わからない時は、ここを参考にしてください。 HTTPD - Apache2 Web Server http://doc.ubuntu.com/ubuntu/serverguide/C/httpd.html Ubuntuのページにも書いたのですが、server版で作業してます。 Desktop版でもある程度一緒のはずですが、違うところは読み替えてください。(とはいえ、Portable Ubuntu 9.04(coLinux)でも一応は確認しました) webサイトの確認は、Windowsから行っているのでスクリーンショットがWindowsでも誤解ないようにしてください(; ´д｀) ↑ インストール † インストール時のSoftware selection に LAMPをセレクトしておくと、インストールされて
Apache HTTP Server はインターネット上で Web ページを公開するための Web サーバーソフトウェアです。 Apache HTTP Server を構築するとその自宅や会社からホームページを公開することができるようになり、レンタルサーバーによくある容量制限や CGI 使用可否などに悩まされることなくウェブサイトを公開することができるようになります。 この Apache HTTP Server は世界一のシェアを誇り、高性能かつ信頼性の高い Web サーバーソフトウェアとして多くの支持を得ています。 Apache HTTP Server はかつて主流であった 1.3 系が新しく開発され 2.0 系となりましたが、ここでは現在最新の 2.2 系での解説となります。 Apache HTTP Server のインストール Apache HTTP Server は apt-get
Apacheのユーザー認証には、「Basic認証」と「Digest認証」がある。Basic認証は一般的に行われている方法だが、パスワードが暗号化されないため、機密性の高いデータへの認証には適していない。Digest認証はパスワードが暗号化されるが、これに対応しているのは比較的最近のWebブラウザに限られる。 ここではBasic認証を利用して、特定ディレクトリのWebページを開く際に「secret」というユーザー名でアクセスできるようにする（編注）。Digest認証を使う方法は、Apacheでユーザー認証を行うには（Digest認証編）を参照。
Summary This module provides directives to control and modify HTTP request and response headers. Headers can be merged, replaced or removed. Order of Processing The directives provided by mod_headers can occur almost anywhere within the server configuration, and can be limited in scope by enclosing them in configuration sections. Order of processing is important and is affected both by the order i
ちなみに、この分析のために必要とされるMapReduceのコードであるが、そのサイズはわずか20ステップだという。Yahoo!のプレゼンテーターである、エリック・バルデシュバイラー氏によると、たとえ経験の浅いエンジニアであっても、MapReduceによるプログラミングは可能であるとされる。 また、VISAのジョー・カニンガム氏からも、貴重なデータが提供されていたので以下に紹介する。同社では、1日に1億トランザクションが発生するため、2年間で700億強のトランザクションログが蓄積され、そのデータ量は36テラバイトに至るという。こうしたスケールのデータを、従来のRDBを用いて分析するには、約1カ月の時間が必要とされてきたが、Hadoopを用いることで13分に短縮されたという。 これまでは、Yahoo!にしろVISAにしろ、膨大なデータをRDBに押し込むほかに方法はなく、その分析に数十日を要する
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
前エントリ pound と apache をバランスよくチューニングする必要性について の続きです。Apache2 のチューニングによる高負荷（大量アクセス）対策を考えてみます。 ここまできてやっと、そもそも高負荷時に apache2 のプロセス数が足りていなく、静的コンテンツの応答時間が遅延しているのかも？という仮説を立てることができました。図解するとこんな感じです。 Apache2 はもちろん worker MPM で動作させています。worker MPM ってなんぞ？という方は、このブログを読んで頂けている方にはいらっしゃらないかと思いますが http://httpd.apache.org/docs/2.0/mod/worker.html あたりを読むと良いでしょう。 このマルチプロセッシングモジュール (MPM) は、マルチスレッドとマルチプロセスのハイブリッド型サーバを 実装して
KeepAliveの設定 HTTPはステートレスプロトコルです。クライアント／サーバ間のTCP接続を永続させず、要求に応じて接続の開始／切断を行います。しかし、Webページは通常HTMLドキュメントや画像など、複数のファイルで構成されています。クライアントが1つのWebページを取得する間に、ファイルごとにTCP接続の開始／切断を行うのは大変非効率的です。そこで、KeepAliveを利用して1つの接続を使い回し、複数のリクエストに応えられるようにします。 KeepAliveの動作にかかわる重要なパラメータが以下に挙げる3つのディレクティブです。 KeepAlive 「On」にすることで、KeepAliveを有効にします。 現在使用されているWebブラウザはApacheのKeepAliveに完全に対応しているため問題はありませんが、マイナーなクライアントや古いバージョンのWebブラウザではAp
ApacheのMaxClients,ServerLimitsで最大接続数を設定できるが、 それを超えた時の新規リクエストは全てエラーが返されると思っていましたが、 ListenBacklogで設定した数までは、キュー待ちになるそうです。 知らなかった。 ちなみに、ListenBacklogの設定値は変更することはあまり望ましくないとか。 デフォルトは511。 また、OSの制約値も関係してくる。 ListenBacklogよりもOSの方が受け付けられなくなると、 OSのエラーが発生するらしい。 以下、参考URL。 http://his.luky.org/ML/linux-users.a/msg02360.html
(Mon, 20 Nov 2006 21:16:10 GMT+9) ApacheのMaxRequestsPerChild Apacheのディレクティブ（設定項目）のひとつ。 ドキュメントをちゃんと読んでたり、そうでなくてもそれなりの知識があればこんな勘違いはしないのだが（こんなんばっか）、これを私はつい最近まで 「ひとつの子プロセスが同時に受けられる最大数」 だと思っていた。んで、「そんなにいっぺんに受けられるわけないやん」などと思いつつ150くらいにしていた。 正解は 「子プロセスを再起動するまでに受けるリクエスト数」 。どういうことかというと、OSのライブラリ不備やApache自身のバグなどでメモリリークしていたときの対策用。じわじわリークしていたとしても、「一定のリクエストを受けたら再起動する」ことで、リークの影響を抑えよう、というための設定。 0にすれば（明示的に指示しなければ）再
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く