タグ

負荷分散に関するakahigegのブックマーク (7)

  • DNS ラウンドロビンのすすめ - その1 | JWord 開発者ブログ

    JWordを支えるエンジニアたちによるブログ※記載されている情報は、全て執筆者個人の経験と環境に基づくものであり、その内容を弊社として保証するものではございません。 技術情報の適用については、各自の責任において行ってください。 こんにちは。ウラッチです。 ここのところUNIX案件とは無縁だったのですが(ひたすらコーディングでした)、久々にいじる機会が増えてきて「やっぱり面白いなあ」と思う今日この頃です。 JWordでは、WEBアプリケーションの運用にDNSラウンドロビンを用い、高可用性を実現しています。ミッションクリティカルなサービスはLVS配下に置いていますが、このDNSラウンドロビンは意外と便利です。DNSラウンドロビンは、下記のように複数のIPアドレスをサーバに割り当てて、DNS応答をランダムに返し負荷分散する仕組みです。 www IN A 192.168.1.2 www

    akahigeg
    akahigeg 2011/04/23
    ブラウザがよきに計らってくれるって知らんかった。でもIPv6の絡みでVistaではよきに計らってくれないらしい。Window7ではいけるように戻ってるらしい。
  • 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

  • http://www.res-system.com/weblog/item/618

    akahigeg
    akahigeg 2007/01/31
    mod_proxy_balancer導入時のハマリどころがよく整理されている
  • ウノウラボ Unoh Labs: PHPで書かれたwebサービスを高速化する2

    前回のエントリPHPで書かれたwebサービスを高速化するでは高速化のレベルのうち、最初の2段階「ハードウェアによる高速化」「ソフトウェアによる高速化」について書きました。 今回は第2弾として「プログラムの工夫による高速化」について書きたいと思います。 - DBへのアクセスは自分で抽象化する DBへのアクセスを高速化するためには、チューニングを行ったり複数台構成にするわけですが、 広く使われているPear::DBとかadodbは複数台構成のDBに接続することを考慮されていません。 Pear::DBやadodbはバックエンドに使って、ラッパークラスを作るようにしましょう。 - 更新系クエリと読み出し系クエリのユーザを分ける これは高速化とは関係ないんですが、ぜひ実行してもらいたいので書きました。 複数台構成のサーバにアクセスするときは更新系クエリはマスターに発行して、 読み出し系クエ

    akahigeg
    akahigeg 2006/06/07
    DBのマスターに接続するユーザとスレーブに繋げるユーザを別にしてスレーブに繋ぐユーザに更新権限がないように
  • 負荷対策概論 - Y-110's Wiki

    最新文章 2018-12-26 17:10▪ 致敬英雄,致敬不朽的精魂 2018-12-26 17:10▪ 四十年来闵行人的文化生活史一幕幕回放 2018-12-26 17:10▪ “笔尖上的童画”——欢图学员作品成果展将在东方网文化活动... 2018-12-26 17:10▪ “金色热线”12月27日将迎来年终特别节目 2018-12-26 17:10▪ 北京市发布持续低温蓝色预警信号 2018-12-26 17:10▪ 北京市网信办推进自媒体账号专项治理关闭11万个 2018-12-26 17:10▪ 有创意的崇明“橘农”让梦想和情怀扎根农场 2018-12-26 17:10▪ 突发!上海地铁3、4号线晚高峰运行延误系人员进入线路 2018-12-26 17:10▪ 中国经济总量将达90万亿关键时刻传递重要信息 2018-12-26 17:10▪ 海底捞:"吃出卫生巾"系人为当事顾客

  • authenticblog::MySQLの負荷分散

    MySQLの負荷分散 2006-03-31 Fri そこで登場するのが,データベースを分割することによる負荷の分散である。mixiでは,2段階のレベルでデータベース分割を行った。  まずレベル1では,テーブルの種類によってデータベースを分けた。どのテーブルがどのデータベースにあるかを示すパーティション・マップを用意する。利点は古いデータベースから新しいデータベースへの移行が容易なことだ。欠点はJOINができないこと。MySQL 5にはこの問題を解決するための「FEDERATED table」という機能があるが,当時はまだMySQL 5は正式リリースされていなかった。そこで,SELECTを2回投げる,あるいはテーブルが小さければ複製する,といった方法で対応したという。 ミクシィのCTOが語る「mixiはいかにして増え続けるトラフィックに対処してきたか」 ここ一年で二つほどPHP+MyS

  • GoogleのMapReduceはとても便利な技術 - llameradaの日記

    GoogleMapReduceはとても便利な技術である(使えないけど)。特に、ある単語(例えばGoogle)が出現した全てのテキスト・ファイル名を抜き出す際に便利だ。 このタスクは、ファイル数が1万ならば簡単に解ける。ワン・ライナーで十分である。例えば、Rubyならばこんな感じだろう。 ruby -rfind -renumerator -e "Find.to_enum(:find, '/tmp/textdir/').each{|fn| \ File.file?(fn) and open(fn).read =~ /google/ and puts fn}" ところがファイル数が10億となった場合、このタスクはとたんに非常に難しいタスクとなる。それは並列処理が要求されるからである。1ファイル10KBとしても、10億のファイルのサイズは10TBとなる。これだけのサイズのデータを取り扱うには並列

    GoogleのMapReduceはとても便利な技術 - llameradaの日記
  • 1