タグ

負荷対策に関するshin-uemonのブックマーク (17)

  • DSAS開発者の部屋:特集記事『Linuxロードバランサ構築・運用ノウハウ』を公開します

    Linuxロードバランサ構築・運用ノウハウ』を公開します! これはWEB+DB PRESS Vol.37の特集記事としてDSASチームが執筆したもので、技術評論社様の許可を得て今回公開するはこびとなりました。 一口でいうと、「Linux+IPVS+keepalivedを使って、冗長構成(Active/Backup)のロードバランサを作るまで」の解説記事で、 サーバ負荷分散一般についてのはなし Linuxでロードバランサを作ってみる ロードバランサを冗長化 といった構成になっています。 みなさんがLinuxロードバランサを導入・構築・運用する際の一助になれば、DSASチームとしてもうれしい限りですので、是非、ご覧になってください! 第1章 サーバ負荷分散概論 特集のはじめに なぜサーバ負荷分散をするのか? サーバ負荷分散の実現方法 ロードバランサのいる構成 ロードバランサはなにを元に分散す

    DSAS開発者の部屋:特集記事『Linuxロードバランサ構築・運用ノウハウ』を公開します
  • 負荷分散講習会 Apache編 | feedforce Engineers' blog

    ゴール 負荷分散のいくつかの方法に関して理解する mod_proxy_balancerによる負荷分散クラスタが構築できる 基礎知識編 基的な資料 主にクラスタによる負荷分散の資料。 - Apache モジュール mod_proxy_balancer - mod_proxy_balancerで中?大規模サーバー運用するときの勘所 - cyano あと社外秘資料。 負荷分散? 複数台のサーバにアクセスを分散して、個々のサーバにかかる負荷を減らし、全体的に処理できるアクセスを増やすこと。 以下のようなアプローチがある。 DNSラウンドロビン DNSでひとつのホスト名に複数のIPアドレスを割り当てる方法 シンプル しかしダウンしているホストにもアクセスが振り分けされてしまう 冗長化と併用でなんとかなるかな? 機能ごとにホストを分割 ウェブサーバとDBサーバの分割(基過ぎるが一応これも負荷分散)

    負荷分散講習会 Apache編 | feedforce Engineers' blog
  • 株式会社スタイルズ

    AWSアドバンスドコンサルティングパートナーの一員として活動する株式会社スタイルズが、AWS導入、移行、開発、セキュリティ、運用保守など、すべてのご相談に乗らせていただきます。 AWSを導入したいが何から始めたらいいかわからない 既存のベンダーが新技術に弱く、良い提案がもらえない クラウドの導入にセキュリティの不安がある AWSをとりあえず導入したが、さらに活用していきたい 社内にAWSの知見を持っている人がいない AWSならではのシステム開発を詳しく知りたい

    株式会社スタイルズ
  • ウノウラボ Unoh Labs: mod_expires と mod_rewrite を使ってウェブサーバへのアクセスを減らす方法

    最近、雨の日が続いて自転車通勤ができていない naoya です。 今日は、先週ぐらいからフォト蔵に導入した Apache で mod_expires と mod_rewrite を使ったウェブサーバへのアクセスを減らす方法を紹介します。 通常のウェブサーバは、更新されていないリリースに対してアクセスすると、ステータスコード 304 とIf-Modified-Since ヘッダをつけて応答データを返しますが、CSSJavaScript など比較的更新頻度の少ないファイルに対して、毎回応答を返すのはウェブサーバから見ると無駄なアクセスです。 Apache の mod_expires と mod_rewrite を使うと、この無駄なアクセスをブラウザキャッシュを有効活用にすることにより、静的なファイルに対するアクセスを減らすことができます。 まず、仕組みから説明すると、とても単純で mod

  • Web高速化 || パフォーマンスチューニングBlog: インターオフィス

    AWSアドバンスドコンサルティングパートナーの一員として活動する株式会社スタイルズが、AWS導入、移行、開発、セキュリティ、運用保守など、すべてのご相談に乗らせていただきます。 AWSを導入したいが何から始めたらいいかわからない 既存のベンダーが新技術に弱く、良い提案がもらえない クラウドの導入にセキュリティの不安がある AWSをとりあえず導入したが、さらに活用していきたい 社内にAWSの知見を持っている人がいない AWSならではのシステム開発を詳しく知りたい

    Web高速化 || パフォーマンスチューニングBlog: インターオフィス
  • サーバやPCのボトルネック箇所の簡単な見分け方(Linux編):佐野裕のサーバ管理者日記:ITpro

    前回はWindowsでのサーバやPCのボトルネック箇所の簡単な見分け方をご紹介させていただきましたが、要望がありましたので今回はLinuxの場合をご紹介いたします。 4つの主要ボトルネック要素の復習です。 サーバやPCには4つの主要ボトルネック要素があります。このいずれかがボトルネックとなった場合システム全体のレスポンスが低下します。 CPU使用率 メモリ使用量 ディスクI/O TCPコネクション数 Linuxにおいてはボトルネック箇所を以下のように見分けることができます。 1. CPU使用率 CPU使用率が常に100%に近い場合はCPUがボトルネックであることが判明します。CPU使用状況を簡単に調べるには3つの方法があります。「top」「w」「vmstat」コマンドを使う方法です。 -----------------------------------------------------

    サーバやPCのボトルネック箇所の簡単な見分け方(Linux編):佐野裕のサーバ管理者日記:ITpro
  • mod_proxyで負荷分散(ProxyPassReverse) - KamoLand

    サーバBが高スペックなマシンなので,こいつにWikiの処理を任せることにする. インターネットから入ってきたリクエストのうち,http://www.rensa.info/wiki/* 宛のリクエストを,Apacheのmod_proxyを使ってサーバBに転送する. そして,サーバB上でWikiの重い処理を実行してレスポンス(Webページ)を生成してサーバAに返し, それをブラウザへ返すという流れになる. ↑ 別案 (参考) なお,このように別のサーバへ処理を依頼するには,今回使わなかったが他の方法も存在する. stoneなどのリピータソフトを使って,リクエストを転送することも可能である. 具体的には, サーバAのApacheでmod_rewriteを使って,http://www.rensa.info/wiki/ へのリクエストを,別ポートへのリクエスト(例:http://www.rensa.

    shin-uemon
    shin-uemon 2007/06/13
    リバースプロキシの例
  • ウノウラボ 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

  • BlogFish: Scaling Rails with Apache 2.2, mod_proxy_balancer and Mongrel

    Unitl this week we used Lighttpd and FastCGI for MeinProf.de. The setup was nearly the same as described in the must read series scaling rails (1, 2, 3, 4) from poocs.net. We used this setup from day 1 but always had some small issues with Lighttpd. Lighttpd was crashing every couple of days. Nothing dramatic, we had a script that monitored Lighttpd and restarted it if necessary. During the last

  • cyano: mod_expiresとmod_rewriteを使ってサイトの帯域節約と体感速度を向上させる方法

    普通の帯域節約術としては、mod_deflateでdeflate圧縮するとか、CSSやJSファイルのHTTPレスポンスヘッダにLast-ModifiedやEtagを追加しておいて、ブラウザがHTTPリクエストヘッダにIf-Modified-SinceやIf-None-Matchを付加するようにし、コンテンツが変更されていなかったら304 Not Modifiedを返すという方法を取るかと思います。 しかし、HTTPサーバーはコンテンツの数だけ304 Not Modifiedを返さないといけないため、その分帯域を消費しますし、またCSSや画像などのパーツの304 Not Modifiedが返ってくるまで、そのパーツのレンダリングが行えないという問題があります(つまり体感速度に影響します)。 今回紹介するのはExpiresヘッダやCache-Control: max-age=31536000を

  • /dev/shm に参照系DBを持っていくと I/O 負荷が激減した件(当たり前だけど)

    前エントリーから一部の内容を分離して追加記事にしてみました。以下実施したメモリ増設の効果について。 ここ数ヶ月、自宅サーバの負荷がだんだんと上昇してきていて、そろそろ1台で高速にさばききる限界に近づいてきた感があったり。ここ数週間のロードアベレージはこんな感じ。グラフは× 100 の値になってます。CPU のコアが2個なんで、200 までは OK ということでまだ処理しきれているわけではあります。ちなみに mrtg グラフは瞬間値を示しているわけではなく平均値なので瞬間的にはもっと負荷が高いときとかあります。 でも月次処理が走るともっさり感満点。 ※緑:1分平均 / 青:15分平均 実は CPU の処理速度が追いついていないと言うより I/O 周りがボトルネックになっています。 ※緑:読取ブロック数 / 青:書込ブロック数 ということで、メモリを2GBプラスして、合計 4GB にして参照系

  • Webアプリの問題点を「見える化」する7つ道具

    Webアプリの問題点を「見える化」する7つ道具:現場から学ぶWebアプリ開発のトラブルハック(1)(2/3 ページ) その2:負荷生成ツール 負荷生成ツールは、Webサーバなどに対して複数のユーザーからの同時アクセスによる負荷を疑似的に発生させるツールである。 ■使いどころ パフォーマンスに問題がないかどうか確認したり、性能劣化などの現象が発生した場合、その現象を再現させるために利用する。Webシステムのトラブルやパフォーマンスの問題は、クライアントからのリクエストを大量に処理しているときに起こるものが多い。 例えば、10秒以内にユーザーが50人程度ログインしたときにシステムが無応答になる現象が発生している場合、再現を行うために人手でブラウザを操作するのは非現実的である。負荷ツールを利用すれば、何十、何百人分の負荷を簡単に発生させられる。 ■分析方法 負荷生成ツールの基的な使い方は、負荷

    Webアプリの問題点を「見える化」する7つ道具
  • TheC10kProblem - 「C10K問題」(クライアント1万台問題)とは、ハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする問題のこと

    TheC10kProblem - 「C10K問題」(クライアント1万台問題)とは、ハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする問題のこと 目次 この文書について C10K 問題 関連サイト まず読むべき I/O フレームワーク I/O 戦略 1. 各スレッドが複数のクライアントを受け付ける. そしてノンブロッキング I/O と レベル・トリガ型の完了通知を利用する. 伝統的な select() 伝統的な poll() /dev/poll kqueue() 2. 各スレッドが複数のクライアントを受け付ける. そしてノンブロッキング I/O と 変更型の完了通知(readiness change notification)を利用する. kqueue() epoll リアルタイム・シグナル fd 単位のシグナル (Signal-per-fd)

  • DSAS開発者の部屋:パソコン1台ではじめるロードバランサ体験

    昨日書いたの通り,記事を寄稿したWEB+DB PRESS Vol.37が,今日発売になりました.それを記念して(?),記事の内容が簡単に実験できるパッケージを公開します. これは,VMWareを使って,だれでも直ぐにロードバランサの実験を始められるパッケージになっています.何台もマシンを集めたり,Linux をインストールする必要は一切ありません.無償配布されているVMWare Playerがあれば,いつでもどこでも実験ができます. もちろん,このブログで去年の夏に公開した4つのエントリ こんなに簡単! Linuxでロードバランサ (1) こんなに簡単! Linuxでロードバランサ (2) こんなに簡単! Linuxでロードバランサ (3) 高トラフィックに対応できるLinuxロードバランサを目指して〜LVSをNATからDSRへ の実験もできます. ダウンロードはこちらからどうぞ(75MB

    DSAS開発者の部屋:パソコン1台ではじめるロードバランサ体験
  • 画像配信の負荷分散も比較的簡単?(その3) - 最速配信研究会(@yamaz)

    画像配信の負荷分散も比較的簡単?(その2)のつづき. 初めての方は画像配信の負荷分散も比較的簡単?(その1)からどうぞ. アクセス/保持データ量ともに多くなってきてどうにもならなくなったらどうするか?お金があるところはサーバを強化したりメモリを増やしたりするのも手だろう.ただもっと安上がりで効果的な方法がある. どうにかなるまで1台あたりのアクセス数と保持データ量を減らせばいいのだ. ずっこけた人がいるかもしれないけど,こっちは大真面目である(笑).別にアクセスが少なくなるまでサービスを縮小させろという意味ではないので,もうちょっと付き合っていただきたい. 下記のような仮想の実装例を考えてみよう. http://i.yimg.jp/images/search/head_050825.gif にアクセスがあったらURLを10で割ってその余りに応じて img0.yimg.jp img1.yim

    画像配信の負荷分散も比較的簡単?(その3) - 最速配信研究会(@yamaz)
  • 最速配信研究会 - Web2.0とC10Kに関する数々の誤解

    Web2.0 = Ajax/Cometなの?とかプロセスIDは今でも16ビットなの?とかはサテオキ、 個々のクライアントがサーバに要求する処理量は小さなものでハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする――。これが最近Web開発者の間で話題となっている「C10K問題」(クライアント1万台問題)だ。 AjaxやCometなどのクライアント側技術に伴うサーバ側の問題に関していろいろ誤解があるようなので,書いておきたい.きっとlingrの中の人はこの記事読んでニヤニヤしてるはず. 以下、記事にないことも書いてあるのでそのつもりで. 誤解その1 AjaxによるWebアプリの台頭でサーバ側の負荷が増大する Ajaxの典型的な使い方はサーバに問い合わせてページの一部分だけを 変化させるというモノだ.これはページ全体を書き換える従来の方法と違い, すでに

    最速配信研究会 - Web2.0とC10Kに関する数々の誤解
  • 404 Blog Not Found:perl - BSD::getloadavg

    2006年10月26日20:30 カテゴリLightweight Languages perl - BSD::getloadavg レポートを受け追記; BSD::Sysctlのことも追記 この部分がなんとも惜しいような気がしたので書きました。 Milano::Monolog: mod_rewriteでサーバーの負荷が高いときだけリダイレクトする my ($ldavg1, $ldavg2, $ldavg3) = `uptime` =~ /load average:\s+([.0-9]+),\s+([.0-9]+),\s+([.0-9]+)/; BSD::getloadavg CPAN http://www.dan.co.jp/~dankogai/cpan/BSD-getloadavg-0.01.tar.gz これで当該部分は、 #!/usr/bin/perl use strict; use

    404 Blog Not Found:perl - BSD::getloadavg
  • 1