タグ

apacheに関するhiroto-kのブックマーク (56)

  • mt-search.cgiをmod_cacheで超高速化する!! - Ogawa::Memoranda

    Posted by: Hirotaka Ogawa @ February 12, 2007 03:45 AM | かなり前からApache 2.2.xを使っているのですが、mod_cache/mod_disk_cacheなんていうモジュールが存在することに全然気がついていませんでした。このモジュールはサーバサイドでコンテンツキャッシングを実現するもので、CGIなどを使って生成される動的なコンテンツのレンダリング結果の再利用を可能にします(静的なコンテンツもキャッシュできますが、応答時間が問題になることはありませんし、一般的にはクライアントサイドでキャッシングされます)。キャッシュするコンテンツは時間制約の強くないものである必要があります。例えば、コメンティングシステムなどではユーザが行った操作をコンテンツに即座に反映する必要があるために適していませんが、検索システムやCMSのように対象とな

  • mod_dosdetectorの反応への反応 - stanaka's blog

    先日(id:stanaka:20070204)、公開したmod_dosdetectorですが、ブクマ数が300users越えと予想以上の反響でした。その中で、いくつかFAQ的な反応があったので、それらに対する回答です。 mod_limitipconnでもできるんじゃないの? mod_limitipconnは、同時接続数を制限して、越えた場合は、接続拒否をするというモジュールです。mod_dosdetectorは、DoS判定したクライアントのみを対象とした制御が可能です。この手の定量的なアクセス制御モジュールは、これまでにいくつか開発されているのですが、ほとんどのモジュールが単純にアクセス拒否するだけ、というのも、mod_dosdetectorの開発動機の一つです。 パフォーマンスは? 確かに余分な処理が必要となっているため、CPU負荷は増えています。しかし、はてなのサーバ構成では、リバース

    mod_dosdetectorの反応への反応 - stanaka's blog
  • サーバにDoS耐性を付ける - stanaka's blog

    ウェブサービスでは、アクセスが集中して、サイトが落ちる、というのは、よくある話です。純粋に人気が出てアクセス集中するなら、サーバ管理側の責任と言われても、しかたないと思います。しかし、botやF5アタックによる突発的な集中アクセスで、落ちてしまう、というのは、運営側としても、あまり納得がいくものではありません。 そのような突発的なアクセスに対応するために、大量のアクセスをしてくるクライアントを検出し、優先度を落すか、アクセス禁止にする方法などがあります。 というわけで、Apacheモジュールでそれを検出するためのmod_dosdetectorを開発しました。(ちなみにコア部分の開発期間は、Apacheモジュールって、どう書くんだっけ、という状態から、3日でした。) mod_dosdetectorは、Apacheモジュールとして動作し、クライアントのIPアドレスごとにアクセス頻度を測定し、設

    サーバにDoS耐性を付ける - stanaka's blog
  • ウノウラボ Unoh Labs: データキャッシュを利用したウェブサーバの高速化

    こんにちは satoです Aapcheでproxyサーバを利用している場合、頻繁にアクセスされて、なおかつ 更新の少ないデータ、(フォト蔵や mixiでいう マイピクチャーなど) は proxyサーバにキャッシュするとレスポンスが良くなります。 mod_proxy_balancerと mod_disk_cache を利用して、proxyサーバに データをキャッシュする手順を紹介します <VirtualHost * *:443> ServerName example.com ProxyPass /img ! # cssやイメージファイルは proxyしないでローカル参照 ProxyPass /css ! <Proxy balancer://web> AddOutputFilterByType DEFLATE text/html text/css application/x-j

  • 徒然なるままにBlog - Apacheチューニング: ロギングを高速化する

    あまり知られていません(と思われる)がApache2(2.0.41以降)にはアクセスログの書き出しをメモリにバッファリングし高速化させるという機能があります。 今回はその機能を有効にするとどれぐらい速くなるのか調べてみました。 設定方法はhttpd.confに BufferedLogs On と追加するだけでログのバッファリングが有効になります。 以下ベンチマークを取った結果です。 バッファリング無効984 Request/Sec バッファリング有効1033 Request/Sec (参考)ロギング無し1055 Request/Sec ※小さなhtmlファイルに対してab -c 100 -n 1000を何度か繰り返した結果の平均です。 体感では違いを感じられないとは思いますがベンチを取るとおよそ5%程Request per secondの値が上がっていました。 静的なファイルが

  • mod_proxy_balancer + mod_disk_cache on Apache 2.2.3 - 積み重ねた日々

    Apache2.2.3の環境下で mod_proxy_balancer と mod_disk_cache を使い、キャッシュサーバを構築したのでメモしておきます。 イメージする構成としては、まずフロントエンドにApacheのReverse Proxy Serverがあり、そしてその裏側に実際にアクセスする複数台のWeb Server(以下の例では5台)があります。 クライアントからのアクセスを受けると、リバースプロキシは、負荷分散アルゴリズムにしたがって、実際のウェブサーバへリクエストを投げることになります。その際、画像コンテンツのみをキャッシュし、次回以降のアクセスではキャッシュファイルのみを返すようにします。 ということで早速設定してみます。 mod_proxy_balancerモジュールを有効にするためには、mod_proxyおよびmod_proxy_httpモジュールが有効になって

    mod_proxy_balancer + mod_disk_cache on Apache 2.2.3 - 積み重ねた日々
  • CGI 出力キャッシュ - なんとなく◎

    CGI 等で生成される動的コンテンツには,個別のリクエストごとに異なるレスポンスを 返さなければならないものもあれば,ある程度の時間内であればどのリクエストに 対しても同じレスポンスを返すものもあるでしょう.後者であれば,レスポンスを mod_mem_cache でキャッシュすることにより毎回 CGI 等を実行せずに済むので, かなり効果的にサーバの負荷軽減を実現することができます. # mod_mem_cache は Apache 2.0 ではまだ "experimental" という扱いですが, Apache 2.1 / 2.2 ではかなり改良されています. httpd.conf での設定は,例えば以下のような感じで.動的コンテンツでは Content-Length ヘッダを出力しないことが多いですから,MCacheMaxObjectSize の指定に際しては併せて MCacheMax

  • 負荷分散環境でブラウザキャッシュが効かないときは - ETagの解説 - : DSAS開発者の部屋

    ETag とはなんぞやというと、Apache が返すレスポンスヘッダのひとつで、 HTTP/1.1 200 OK Date: Mon, 24 Jul 2006 06:18:07 GMT Server: Apache Last-Modified: Wed, 13 Apr 2005 21:48:55 GMT ETag: "3b-60273fc0" ←これ★ Accept-Ranges: bytes Content-Length: 59 Connection: close Content-Type: text/html オブジェクトに付与される属性です。 で、何に使うかというと、ブラウザのキャッシュ管理に使われます。 一度、http://example.jp/index.html にアクセスした後でもう一度(リロードとかで) アクセスすると、ブラウザは最初のリクエストのときに得た ETag の値

    負荷分散環境でブラウザキャッシュが効かないときは - ETagの解説 - : DSAS開発者の部屋
  • トラックバックスパムよけにも使える「mod_security」

    Apacheをセキュアにするモジュールで「mod_security」というのがあるそうで。いわゆるWeb Application Firewall (WAF)というものに分類される仕組みなのですが、非常に機能が強力。ヘッダ、GET、POST、レスポンスを含むINとOUTの全リクエスト(HTTPS含む)に対してフィルタリング可能。通常では記録されないPOSTのログも記録可能。 で、この機能を使えばトラックバックスパムもサーバ側で始末できるので、PHPなどが動いて判定する前に処理でき、トラックバックスパムによる負荷が軽くなるというわけ。 設定の詳細などは以下の通り。mod_security用のブラックリストもダウンロードできるので設定も簡単です。 公式サイトは以下。 ModSecurity (mod_security) - Open Source Web Application Firewal

    トラックバックスパムよけにも使える「mod_security」
  • ウノウラボ Unoh Labs: mod_proxy_balancer 小技集

    こんにちは sato です。 ベンチャーでは高価なハードウェアバランサなどを購入することはできないですが、 apache2.2 から mod_proxy_balancerという apacheモジュールの ソフトウェアバランサが 追加されたので、フォト蔵でも使用しています。  今のところ proxy サーバがボトルネックになることはないです。 想定構成は以下とし、apacheは 2.x を使用しました。 proxy1 +------web1 +------web2 ... +------webN ・基設定 httpd.conf LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_balancer_module modules/mod_proxy_balancer.so ProxyPass / ba

  • サイト移転時の301リダイレクト処理の具体例:phpspot開発日誌

    Steven Hargrove: How to redirect a web page, the smart way サイト移転時の方法として、301リダイレクトにより、新しいサイトへの転送が最適な方法とされていますが、その301リダイレクト処理の各種具体例。 .htaccess で301リダイレクトを行う方法 特定ページのみの場合は次のようにします。 redirect 301 /old/old.html http://www.yahoo.co.jp 上記は、/old/old.html にアクセスした場合、www.yahoo.co.jp に301リダイレクトされます。 サイトのドメイン移転をした場合は次のように記述します。 RewriteEngine On RewriteCond %{http_host} ^www.from-url.com RewriteRule ^(.*) http:/

  • http://www.shimasoba.com/article.php?id=121

  • Y-110's Wiki/ 負荷対策概論

    最新文章 2018-12-26 20:54▪ 网络女主播与“阔绰”粉丝成恋人被骗25万元 2018-12-26 20:54▪ 中国警企“抱团”打假净化酒类市场 2018-12-26 20:54▪ 官宣!弗洛雷斯任申花新主帅吴金贵任俱乐部体育总监 2018-12-26 20:54▪ 广西钦州“无偿献血达人”病逝捐献眼角膜 2018-12-26 20:54▪ 陕西将集中整治中小学生校外培训机构 2018-12-26 20:54▪ 重医儿童医院谭大兵副院长当选全国后勤专委会副主任委员 2018-12-26 20:54▪ 黄浦区荣获2018年度“质量魅力城市” 2018-12-26 20:54▪ 从“仙境”到“天堂”!杭黄高铁列车今日首发,点这里见证历... 2018-12-26 20:54▪ 令人着迷的巴厘岛浪漫住宿地 2018-12-26 20:54▪ 抑郁症男子反对给继女买零斥太小气放

  • LiteSpeed

    (注意: 印はくまくまー調べなので鵜呑みにしてはいけません) [開発] Apache上での開発はまず無理である。WEBrick は Ruby標準な上に最低限の機能・スペックは満たしているので未だに愛用者は多く、Rails初学者には十分である。WEBrickの速度に限界を感じたユーザは Lighttpd(愛称 lighty)を利用する。速度も十分でや設定も容易だが、起動時の引数でポートを指定できないなど若干使いづらい面もある。lighty ユーザは Mongrel に進むという予言もある。 [運用] Webサーバのデファクトはやはり Apache で、Rails的には生CGIは無理だが、FastCGIなどのモジュールと併用することで速度的な問題はなくなる。RailsはLighttpdなどの開発向けのサーバで動かし、リバースプロキシを利用する手もある。完全に Rails のみで運用されるサイト

  • ウノウラボ Unoh Labs: PHPで書かれたwebサービスを高速化する

    尾藤正人です。 アクセス数の多いコンシューマ向けの web サービスは、処理速度がかなり重要になってきます。 応答速度が遅いと使用しているユーザにとってストレスになりますし、 処理に時間がかかればサーバに対する負荷も高くなります(厳密に言うと違う)。 そこでウノウではいろいろな工夫をして処理速度の高速化を行っています。 一口に高速化といってもいろいろな要素がありますが、大きく分けて3つの段階があります。 ・ハードウェアによる高速化 ・ソフトウェアによる高速化 ・プログラムの工夫による高速化 しかし、これら3つは独立ではなく、互いに影響しあっているので完全に分けて考えることはできません。 それぞれがどのような部分に影響を与えているのか、ちゃんと理解してチューニングすることが大事です。 ただし、高速化するときに忘れていけないのが、高可用性です。 いくら高速に動作しても安定して動作し

  • performancewiki.com - performancewiki リソースおよび情報

    This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.