タグ

Apacheに関するoinumeのブックマーク (139)

  • Apache HTTP Server: MPMパラメータ チートシート

    こんにちは滝澤です。たまにはapacheネタということで一つ。 Apache HTTP ServerのパラメータチューニングではMaxClientsなどのMPM(マルチ プロセッシング モジュール)関連のディレクティブの設定値を調整することが多いです。記事ではMPM関連のディレクティブのデフォルト値やディレクティブ間の関係を表にまとめたので紹介します。 注意事項 UNIX系OSにおける説明となります。バージョン2.2系および2.4系の両方について説明します。 関係式においてバージョン2.4系の場合はMaxClientsをMaxRequestWorkersに置き換えて読んでください。 ディレクティブ名には公式サイトのリンクを張っています。公式の説明も確認してください。 デフォルトの欄で括弧付きものはそのディレクティブそのものは設定不可ではあるが、内部的に設定されているデフォルト値を示してい

    Apache HTTP Server: MPMパラメータ チートシート
  • ApacheとNginxの性能比較でevent_mpmの本気を見た

    はい、これは僕がいつも良く見るApacheとNginxの性能差に見えます。大体、ApacheはNginxの75%程度の性能に落ち着きます。数十バイトの静的コンテンツに対するリクエスト処理はNginxの得意分野だと思っていたので、大体こんなものです。 そこで、真面目にevent_mpmのチューニングを行ってみました。で、幾度となくベンチを試した結果導き出した、静的コンテンツに対する同時接続数100程度に対して最高のパフォーマンスを示すevent_mpmの設定は以下のようになりました。 [program lang=’apache’ escaped=’true’] StartServers 4 MinSpareThreads 4 MaxSpareThreads 4 ThreadsPerChild 2 MaxRequestWorkers 2 MaxConnectionsPerChild 0 [/p

    ApacheとNginxの性能比較でevent_mpmの本気を見た
  • 複数のWebサーバでSSLセッションキャッシュを共有してSSL処理を高速化(Apache + mod_ssl + mod_socache_memcache) - 元RX-7乗りの適当な日々

    HTTPS(SSL利用)サイトがSEO的に優遇されるトレンドで、世間的にもHTTPS接続でサイト運用するサービスが増えてきています。 これが、ハイトラフィックサイトになってくると、このフロントエンドでSSL処理させることが負荷的にもなかなか辛いのです。 で、Apache 2.3以降では、Shared Object Cache Providerとして、memcachedが選択できるようになっています。 この仕組みを利用して、Apacheとmemcachedを並べることで、各サーバでユーザのSSL Session Cacheを共有しながらHTTPSリクエストを負荷分散できる構成を作ってみました。 WebサーバでSSLオフロード 常時SSLを利用したWebサイトを運用するために、SSLアクセラレータといったアプライアンス製品だとか、ソフトウェアだとApacheやNginxのSSLモジュールを使う

    複数のWebサーバでSSLセッションキャッシュを共有してSSL処理を高速化(Apache + mod_ssl + mod_socache_memcache) - 元RX-7乗りの適当な日々
  • GoAccessでリアルタイムにアクセスログを解析する - Qiita

    GoAccessとは GoAccessは、ターミナル上で動作するリアルタイムログ解析ツールです。 Apacheのログをコマンドライン引数に与えると、リアルタイムにリクエストされているURLやアクセス元ホスト、ステータスコードなどを集計し、画面に表示します。 導入 Macユーザーであれば、Homebrewを使うと、brew install goaccessを実行するだけでインストールできます。 *NIX系の環境であればGoAccessのインストール方法を参照してインストールしましょう。 Ubuntuでは、apt-get install goaccessでもインストールできるようですが、Ubuntu 12.04ではGoAccessのバージョンが0.4.2(GoAccessの最新バージョンは0.7)となっていたので、可能であればソースからインストールするのがよいでしょう。 環境によってはlibg

    GoAccessでリアルタイムにアクセスログを解析する - Qiita
  • SSL のパフォーマンスでお嘆きの貴兄に - What I’ve found has never been enough@Hatena

    SSL アクセラレータの価格に胃を痛めている貴兄、それが買えず SSL のためだけにサーバの台数をニョキニョキ増やしている貴兄、そうでなくとも SSL のパフォーマンスでお嘆きの貴兄のために、いろいろまとめてみましたよ。 SSLセッションキャッシュのタイムアウト設定を長くしよう SSL の負荷のほとんどはセッションの生成によるものなので、当然のようにサーバ側の SSL セッションキャッシュを有効にしておられると思いますが、そのタイムアウトの設定がデフォルトのままという方が多いのではないでしょうか。 たとえばApacheでしたら、設定サンプルのまま SSLSessionCache shm:/usr/local/apache/logs/ssl_gcache_data(512000) SSLSessionCacheTimeout 300 としている方が多いのではないでしょうか。 各サーバのデフォ

    SSL のパフォーマンスでお嘆きの貴兄に - What I’ve found has never been enough@Hatena
  • 【自動化】PageSpeed ModuleでWebサイトのパフォーマンスチューニング #1 インストール編 | DevelopersIO

    パフォーマンスチューニングって手間ですよね。 そんな時にお金(サーバーのスペック)とちょっとしたスキルでぱぱっとパフォーマンスを改善できるのがPageSpeed Module(Mod Pagespeed)ってやつです。 対象者 この記事では黒い画面(コンソール)からsshでサーバーにアクセスし、LinuxコマンドやViを使った各種操作を行う必要があります。 自分もWebデザイナー上がりなのでWebデザイナーやコーダー、フロントエンジニアのような方にも黒い画面やサーバー側に興味を持ってもらい挑戦してもらえると仲間が増えて嬉しいな〜なんて思ってます。 PageSpeed Moduleって? PageSpeed ModuleはWebサイトのロードタイムを高速化するためのツールです。 PageSpeed Moduleをサーバーにインストールし適切な設定を行うことでWebサイトをほとんど調整すること

    【自動化】PageSpeed ModuleでWebサイトのパフォーマンスチューニング #1 インストール編 | DevelopersIO
  • ロリポップのサイト改ざん事件に学ぶシンボリックリンク攻撃の脅威と対策

    既に報道されているように、ロリポップ!レンタルサーバーに対する改ざん攻撃により、被害を受けたユーザー数は8428件にのぼるということです。ここまで影響が大きくなった原因は、報道によると、(1)「WordPressのプラグインやテーマの脆弱性を利用」し、不正なファイルがアップロードされた、(2)パーミッション設定の不備を悪用されて被害が拡大した、ということのようです。 29日夜の時点では、攻撃者の改ざん手法について「WordPressのプラグインやテーマの脆弱性を利用」し、不正なファイルがアップロードされて「wp-config.phpの」の設定情報が抜き出されたと説明していたが、30日午後7時過ぎの説明で、この脆弱性が侵入経路となって同社のパーミッション設定の不備を悪用されたことが原因だったことを明らかにした。 「ロリポップ」のWordPressサイト改ざん被害、原因はパーミッション設定不備

    ロリポップのサイト改ざん事件に学ぶシンボリックリンク攻撃の脅威と対策
  • 有効なWikiNameではありません

    2019-03-28 Python/インスタンス生成 2018-01-02 Python/クロージャ Pythonを読む 2018-01-01 Python/メソッド呼び出し 2017-12-31 Python/build_class後編 2017-12-30 Python/読解対象とするPythonコードと解析方法 2017-12-24 Python/build_class前編(というよりPyTypeObject) 2017-12-07 Python/ビルトインがビルトインされるまで 2017-12-03 Python/C関数実行とPyObject 2017-10-22 Django/テンプレートシステムを読む(レンダリング) Djangoを読む 2017-10-21 Django/テンプレートシステムを読む(テンプレートのパース) 2017-09-24 Django/テンプレートシステ

  • mod_cidr_lookup

    Overview mod_cidr_lookupは、アクセスしてきたクライアントのIPアドレスが、起動時に読み込んでおいたCIDRブロック群のいずれかにマッチするかどうかを判別するためのモジュールです。Apache 2.0と2.2系に対応しています。 マッチした結果は、環境変数 (X_CLIENT_TYPE) とHTTPリクエストヘッダ (X-Client-Type) にセットするので、Apache自身とバックエンドのWebアプリの両方で同じ情報を参照することができます。 使用例 ※IPアドレス帯域の正確性などについては、情報提供元にお問い合わせください。 クローラからのアクセスは別のサーバにreverse proxyする モバイル用のクローラには、送信元IPアドレスを公開しているものがあります。 Google モバイルウェブクローラー モバイル版Yahoo! livedoor DeNA 

  • mod_spdyから学ぶSPDYとストリーム並列処理の実装

    人間とウェブの未来(旧) 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 HTTP関連の研究をしているので、そろそろ古い技術を詰めるばかりではなく(これはこれでとても大事な事なのですが)、新しい技術についても調べておきたいところです。 ということで、僕のSPDYに関する現状の理解を、mod_spdyに関する情報を元にまとめておきたいと思います。 SPDY概要 SPDYの概要を表す図としては、下記が良く用いられます。 TLS上にのせたSPDYストリーム上でHTTPやWebSocketを扱うプロトコルで、特徴としては、以下の4つがあげられます。 ストリームの並列化 フレームレイヤーやヘッダーの圧縮 リクエストの優先処理 サーバからのリソースプッシュ HTTP/2.0についても、SPDYを元に仕様が検討されています。では

    mod_spdyから学ぶSPDYとストリーム並列処理の実装
  • Apacheのリクエスト処理時間(%T or %D)は正確には何の時間か — ありえるえりあ

    Apacheのログに%T or %Dでリクエスト処理時間を載せることができます。%Tと%Dは内部的には同じ計算値で、単位が異なるだけです(%Tは秒、%Dはマイクロ秒)。 このリクエスト処理時間は、いつからいつまでの処理時間でしょうか。つまり計測時間の開始と終了はどのタイミングでしょうか。 終了はレスポンスデータをsend(2)し切ったタイミングです。 開始として思いつくのは次の3つのタイミングです。 listenキューに入ったタイミング(3wayハンドシェイクの最初のACKを受けたタイミング) accept(2)が返ったタイミング(3wayハンドシェイクの最後のACKを受けたタイミング) リクエストデータをrecv(2)する前 実はどれも間違いです。正解は、リクエストデータの1行目のリクエスト行を読み終わったタイミングです(ソースコードで言うと server/protocol.cのread

  • app serverがリクエストの処理にかかった時間をログに記録する

    Webアプリケーションのパフォーマンスをトラッキングするために、app serverの処理にかかった時間を記録したい。 方法を、以下のように分類できる。 1. reverse proxy側で、proxy先のapp serverがレスポンスを返してくるのにかかった時間をログに記録する場合 1.1 nginx 1.2 apache 2. app serverでリクエスト処理にかかった時間を出して、ログに記録する場合 2.1 reverse proxyで記録する場合 2.2 app serverでログに記録する場合 1と2とでは出てくる数字が違うだろうけど、件に必要なのはパフォーマンス改善を示す一貫した指標なので、どっちでもいいと思う。 1. reverse proxy側で取る場合 1.1 nginx log_formatディレクティブに$upstream_response_timeという変数

  • regexp - で Apache Combined Log を Parse する : 404 Blog Not Found

    2013年02月09日22:30 カテゴリTipsLightweight Languages regexp - で Apache Combined Log を Parse する けだし同感。 ましてや Apache Combined Log を LTSV に を書いた後では。 combined2ltsv.plの最初のバージョンのparserはこうなっていました。 sub parse_line_ng { my $line = shift; my %rec; ( $rec{host}, $rec{ident}, $rec{user}, $line ) = split ' ', $line, 4; $line =~ s/^(\[.*?\]) //; $rec{time} = $1; $line =~ s/^\"(.*?)\" //; $rec{req} = $1; ( $rec{status},

    regexp - で Apache Combined Log を Parse する : 404 Blog Not Found
  • ApahceのServerLimitディレクティブ - shibainu55日記

    これまでprefork MPMで使っていたApacheを、負荷増加のためworker化することにした。(MPMについては以前のブログ)で紹介した。そんなわけでhttpd.confのMPMに関する設定値を再検討することになったわけだが、ServerLimitのディレクティブのMPMにより違いをうっすらとしか覚えていなかったのでもう一度調べてみた。 prefork MPM の場合 ServerLimitはApacheプロセス稼働中におけるMaxClientsに設定可能な上限値を設定する。これは、preforkの場合は「同時クライアント数 = サーバプロセス数」になるため。 prefork MPM では、MaxClientsを256 (デフォルト) よりも大きな値に設定する必要がある時にだけ使用する。 希望の MaxClients数とくらべて、必要以上に大きな値を指定することは避ける。 work

    ApahceのServerLimitディレクティブ - shibainu55日記
  • combinedに代わるオレ流ログフォーマット - (ひ)メモ

    こんにちは、combinedログ撲滅委員会のひろせです。 ApacheのcombinedやNginxのデフォルトのlog_formatは、機械処理(日付でのソートやパース)がしづらい上に、人の目にもあまり見やすいフォーマットとはいえないと思っています。 なので自宅のサーバーでは、 日付は ISO8601 にする sortコマンドとかで簡単にそぉーっとソートできるようになる 日付、レスポンスコード、所要時間とか固定長的なフィールドは左に寄せる URLとかUAとか可変長で長いのは右に寄せる リクエスト(%r)も右に寄せた方ががいいような気がしてきた。。。 数値だけだとわかりづらいのでなんとなくわかるようにフィールド名も添える フィールド名を長くするとわかりやすくなる反面、ログサイズが大きくなるので注意 という観点で次のようなログフォーマットにしています、 # Apache LogFormat

    combinedに代わるオレ流ログフォーマット - (ひ)メモ
  • Apache2.2/Tips - PukiWiki

    ログ振り分け† ローカルアクセスやロボットのログを分けてみる。 #ローカルIPアドレス SetEnvIf Remote_Addr 127.0.0.1 local nolog SetEnvIf Remote_Addr 192.168.x.x local nolog #クローラ SetEnvIf Remote_Host msnbot search nolog SetEnvIf User-Agent googlebot search nolog #ログ振り分け CustomLog logs/access_log combined env=!nolog CustomLog logs/search_log combined env=search CustomLog logs/local_log combined env=local ↑ Ciphersの指定† SSLCipherSuiteで弱い奴を弾

  • https://jp.techcrunch.com/2012/10/11/20121010googles-mod_pagespeed-is-now-out-of-beta-and-ready-to-make-your-sites-faster/

    https://jp.techcrunch.com/2012/10/11/20121010googles-mod_pagespeed-is-now-out-of-beta-and-ready-to-make-your-sites-faster/
  • Apacheのアクセス ログをPythonで解析するには? - Mixnuts@BetaNews

    Apacheログを効率よく解析するのは、SEO対策の面でも、パフォーマンス チューニングの面でも、かなり有効です。Apacheで一般的に使われるのはcommonとcombined形式のアクセスログで、かつcombinedio形式を独自にカスタマイズしたものなども使われます。とりあえず、一般的なcommon形式とcombined形式を正規表現化してみましょう。 commonの場合、 ^([0-9]{,3}\.[0-9]{,3}\.[0-9]{,3}\.[0-9]{,3}) ([^ ]{1,}) ([^ ]{1,}|\-) \[([0-9]{2}\/[A-Za-z]{3}\/[0-9]{1,4}:[0-9]{1,2}:[0-9]{1,2}:[0-9]{1,2} [+\-][0-9]{4})\] "([A-Z ]+) ([^"]*) ([^"]*)" ([0-9]{3}) ([0-9]{1,}|

    Apacheのアクセス ログをPythonで解析するには? - Mixnuts@BetaNews
  • rummelonp.com

    rummelonp.comNameKazuya Takeshima Blogrummelonp.hatenablog.com Mastodon@[email protected] Twitter@rummelonp GitHub@rummelonp

  • WebLog Expert - Apache log analyzer

    You can download free fully functional 30-day trial version of WebLog Expert Std/Pro/Ent. The program is also an IIS log analyzer, it can analyze IIS log files in W3C Extended format. The program supports Combined and Common log formats of the Apache web server. We recommend you to use the Combined log format because the Common log format doesn't contain information about referrers and user agents