ゆーすけべー日記: YourAVHost その後
サキとは彼女の自宅近く、湘南台駅前のスーパーマーケットで待ち合わせをした。彼女は自転車で後から追いつくと言い、僕は大きなコインパーキングへ車を停めた。煙草を一本吸ってからスーパーマーケットへ向かうと、ひっきりなしに主婦的な女性かおばあちゃんが入り口を出たり入ったりしていた。時刻は午後5時になる。時計から目を上げると、待たせちゃったわねと大して悪びれてない様子でサキが手ぶらでやってきた。 お礼に料理を作るとはいえ、サキの家には食材が十分足りていないらしく、こうしてスーパーマーケットに寄ることになった。サキは野菜コーナーから精肉コーナーまで、まるで優秀なカーナビに導かれるように無駄なく点検していった。欲しい食材があると、2秒間程度それらを凝視し、一度手に取ったじゃがいもやら豚肉やらを迷うことなく僕が持っているカゴに放り込んだ。最後にアルコール飲料が冷やされている棚の前へ行くと、私が飲むからとチ
[rails][負荷分散]RailsのDB負荷分散調査のための資料 - yoshitetsuの日記
magic_multi_connections Magic Multi-Connections magic_multi_connectionsのページ Magic Multi-Connections: A “facility in Rails to talk to more than one database at a time” magic_multi_connections作った人の記事 Twitterのトラブルから見る、DB分割でスケーラブルなRailsサイト構築 magic_multi_connectionsの使い方がのってる Ruby on RailsでMagic Multi-Connectionsを使う magic_multi_connectionsの使い方がのってる 分散DB対応ライブラリ Magic Multi-Connections を試してみる magic_multi_
![[rails][負荷分散]RailsのDB負荷分散調査のための資料 - yoshitetsuの日記](https://cdn-ak-scissors.b.st-hatena.com/image/square/438548124851f1bc8c72d6b93ef644a077b1ada8/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127121096700%2F17680117127121100502%2F1557249666)
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込みです。
第2回 AP4RとRailsでつくる非同期アプリケーション | gihyo.jp
ちょっとしたニュース 今年11月にアメリカ東海岸のシャーロットで開催されるRubyConf 2007の発表枠応募にAP4Rが通りました！ いい機会をもらえたので、がんばって発表してきます。 Agenda for RubyConf 2007 : Introduction to AP4R, Asynchronous Processing for Ruby 手を動かしてみましょう 第1回では、AP4Rの開発に至った背景、システムの構成例、信頼性を保証するSAF機能について見てきました。 そして、非同期処理を利用する場合の一般的な利点と注意点に触れた後、AP4Rの「堅牢」かつ「軽量」という特徴について解説しました。 今回は、Ruby on Railsで作られたウェブアプリケーションをAP4Rと連携させて、非同期処理を実装してみましょう。作成するアプリケーションの機能と、非同期化する箇所を選び出した
livedoor Techブログ : nowaのサーバ構成
こんにちはスエヒロです。 今回は弊社が提供しているブログサービス「nowa」(ノワ http://nowa.jp)の仕組みをサーバ構成を中心に紹介したいと思います。 nowaでは一般的なブログサービス要素とSNS要素の機能を実装しています。弊社には先行して提供している「livedoor Blog」、「フレパ」といった大規模なサービスがありますので、そちらの開発・運用で問題になった点などを参考にしつつ開発を進めています。具体的にはアクセスによる負荷への対策、データベースの分散化、画像のストレージング、冗長性、スケーラビリティといった点になります。 - ポータル(nowa.jp)、CMS(cms.nowa.jp) のサーバ構成 ポータルページ(nowa.jp)とCMSページ(cms.nowa.jp)は、静的なファイルのリクエストを捌く+動的なコンテンツへのリクエストをプロキシするフロントサーバ
ドワンゴ 研究開発ブログ
こんにちは、研究開発部の溝口です。 弊社でも毎年恒例となりつつある技術系のインターンシップが始まりました。 今年のインターンシップに参加される学生さんは4名で、それぞれ2名づつ2チームに分かれ、ホストとなる社員とともに、研究開発本部のテーマに沿ったプロダクト開発を約1ヶ月にわたってフルタイムで行っていただきます。 今年のテーマは、やはりニコニコ動画関連です。 インターンの最後には社内で成果発表を行っていただきますし、その成果によっては世にでる可能性も十分にあります。 参加者のみなさんにはこの機会にネット・エンターテインメントの開発サイド、仕事としてのソフトウェア開発、多くのエンドユーザ様へのプロダクト・アウトについて経験していただけることを期待しています。 独立行政法人 情報処理推進機構(IPA)/財団法人 日本情報処理開発協会(JIPDEC)が主催となって8月13日〜8月17日にかけて、
TAKESAKO @ Yet another Cybozu Labs: ニコニコ動画勉強会に行ってきました
本日ドワンゴさんの会議室にてこっそり開催されたニコニコ動画勉強会に参加してきました。 日本の動画コメントサービス「ニコニコ動画」の裏側をドワンゴの開発者の方から 直接お話しを聞いて、参加者も一緒に意見交換ができる非常に面白い勉強会でした。 ドワンゴさんとしては会社で行なう技術者向けの勉強会初めての試みということもあり、 まずは開発者の知り合いベースで声をかけあって少人数で開催することにしたそうです。 六本木のクラブの人や、バイナリカンファレンスでご一緒した人とこんなところで お会いできるとは思っていませんで、さまに想定の範囲外でした。 その甲斐あって密度の濃い話ができたと思います。 以下、自分用のメモを公開できる範囲で書きます。間違っていたらすみません。（ご指摘いただければすぐに訂正します） ■ニコニコ動画の苦労話 (Sさん) ニコニコ動画の歴史 2006年10月 一人でプロトタイプを開発
Apache 2.2でWebサイトをパフォーマンスアップ！（3/3） － ＠IT
Apache 2.2でWebサイトをパフォーマンスアップ！ － 最新Apacheの機能と設定方法教えます － 鶴長 鎮一（book@tsurunaga.jp） 2006/3/14 ロードバランスクラスタを使う Apacheには、レスポンスの遅いサーバの代わりに応答するプロキシ機能が提供されています。Apache 2.0でも、通常のフォワードプロキシおよびWebサーバの負荷分散を可能にするリバースプロキシに対応していました。 Apache 2.2ではリバースプロキシ機能をさらに高め、トラフィック量やリクエスト回数に応じたロードバランシングが可能になっています。ロードバランスされるバックエンドサーバは、Apacheを再起動することなくオン／オフラインにできます。バックエンドサーバがダウンした場合は、自動的にそのサーバを切り離し、復旧後自動的に復帰させるといったことも可能です。 ■ロードバランス
ウノウラボ 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
ヽ( ・∀・)ノくまくまー(2007-06-05)
● 1. 一戸建てタイプ そのアプリ用に専用のマシンを準備できるケース。例えば、アクセス数が少ないβリリース時などは mongrel を直接80ポートで運用することもあるだろう。そして、負荷の増加、またはマルチコアを活かすという次の段階で、cluster 化した mongrel を扱う必要に迫られた場合、このタイプになる。この場合、フロントの仕事はバック(Rails)への割り振りだけだが、そのためにわざわざ Apache2 を持ち出すのは仰々しいと感じるかもしれない。そんな人にお奨めしたいのが Pound サーバだ。いきなり Apache から話が逸れてしまうが、このケースだとリアルでお奨めである。 Pound + mongrel Pound はリバースプロキシ用のWebサーバであり、特化しているだけあって、必要最低限かつ直感的で簡単な設定で済むため、敷居が低いのが魅力だ。それでいて、デジ
[Vol.1] RailsとMySQLによる大規模サイト構築実験
大規模サイト構築のための土台を作っていきます。 ASP事業に力を注入するとなると、２４H7D動作し続ける安定したサービスのためのインフラがまうます必須になるはずです。 アーキテクト WEBサーバ 何でもいい。 WEBアプリケーションフレームワーク Ruby on Rails DB MYSQL で実験していきます。 とりあえず、必要そうなもの。 1. WEB 負荷分散 ・冗長化 2. DB 負荷分散 3. DB 冗長化 4. Railsの拡張(DBへのコネクション周り) まず1番。 ロードバランサー使えばできるし現在のドリコムでも、DUOBLOG APIやCMS ASPはクリアしてます。DNSラウンドロビンは、障害検知が不可能なのでNGです。 次は、2番。 クエリは、参照系クエリと更新系クエリに分類されます。 今ドリコムでDBへのクエリを負荷分散させているプロジェクトは(僕の知っているところ
![[Vol.1] RailsとMySQLによる大規模サイト構築実験](https://cdn-ak-scissors.b.st-hatena.com/image/square/4eaa2c21ab0ee25aaa9581edc9de7790ee81dcf0/height=288;version=1;width=512/https%3A%2F%2Flh3.googleusercontent.com%2Fblogger_img_proxy%2FAEn0k_s27yaREMaTKhBvb0Bj9DzUtXXaiLzrmgNTLn20ziH3KhNj3LUOBRxBobwdzpp4UG3Wl7WhtzH43n9CiaJCQU5Us54TdCdomqcNr3tWbcA3mWHGmd6hcvhrxICuDQBO40mlx_NHmBjLoeYSe0M%3Dw1200-h630-p-k-no-nu)
LVS + keepalived + VRRP + DSR環境を構築する際のRed Hat Enterprise
_ [Server][Admin] LVS + keepalived + VRRP + DSR環境を構築する際のRed Hat Enterprise Linux/CentOSでのネットワーク周りの便利な設定方法 KlabのDSAS開発者さんのパソコン1台ではじめるロードバランサ体験は基本的にDebianをターゲットにされているため、Red Hat Enterprise Linux/CentOSで構築する場合固有の便利な設定方法が書かれていないのでそれを紹介したいと思います。既にDSAS開発者さんの手順で環境を作ったことがある人向けです。ここで紹介する方法で設定をしておけば、OS再起動後やネットワーク再起動も自動的に停止前と同じ状態になります。肝は/etc/rc.localを使わないこと。 上位ルータでの静的ルーティング設定 上位ルータがハードのスイッチではない + Red Hat Ente
Twitterのトラブルから見る、DB分割でスケーラブルなRailsサイト構築:TKMR.blog.show
最近、2.0な方々の間でTwitterが話題になってる。で、そのTwitter自体も面白いんだけど、TwitterについてDHHがブログを書いてRailsでの大規模サイト構築が話題になってるのが面白い。 Twitter trouble (Loud Thinking - DHH) まずTwitterの高負荷について言及、Twitterは11,000リクエスト/秒 の高負荷で問題となっているらしい。 そしてスケーラビリティの鍵はDB分割だ、と言っている。Railsは基本一つのDBを見るのでスケーラビリティの問題になる （確かにWebサーバはロードバランサがあればいくらでもスケールするしね、Sessionの共有だけ気を付ければ） ↓ Dr Nic » Magic Multi-Connections: A “facility in Rails to talk to more than o
DSAS開発者の部屋:パソコン1台ではじめるロードバランサ体験
昨日書いたの通り，記事を寄稿したWEB+DB PRESS Vol.37が，今日発売になりました．それを記念して(?)，記事の内容が簡単に実験できるパッケージを公開します． これは，VMWareを使って，だれでも直ぐにロードバランサの実験を始められるパッケージになっています．何台もマシンを集めたり，Linux をインストールする必要は一切ありません．無償配布されているVMWare Playerがあれば，いつでもどこでも実験ができます． もちろん，このブログで去年の夏に公開した4つのエントリ こんなに簡単！ Linuxでロードバランサ (1) こんなに簡単！ Linuxでロードバランサ (2) こんなに簡単！ Linuxでロードバランサ (3) 高トラフィックに対応できるLinuxロードバランサを目指して〜LVSをNATからDSRへ の実験もできます． ダウンロードはこちらからどうぞ(75MB
DSAS開発者の部屋:こんなに簡単！ Linuxでロードバランサ (1)
DSASのロードバランサは高価なアプライアンス製品ではなく、LinuxのLVS (Linux Virtual Server)を利用しています。 安価、というか、ハードウエア以外は金銭的コストがゼロなので、一般のクライアントからのアクセスを受ける外部ロードバランサのほかに、内部サービス用のロードバランサも配置しています。それぞれactive, backupで2台ずつあるので合計で4台もロードバランサがあることになります。(こんな構成を製品を使って組んだら数千万円すっとびますね) また、ネットワークブートでディスクレスな構成にしているので、ハードディスが壊れてロードバランサがダウンした、なんてこともありません。 ですので「ロードバランサは高くてなかなか導入できない」という話を耳にする度にLVSをお勧めしているのですが、どうも、 なんか難しそう ちゃんと動くか不安 性能が出ないんじゃないか 等々
Ywcafe.net
Ywcafe.net This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: Healthy Weight Loss Best Penny Stocks Cheap Air Tickets Credit Card Application Top Smart Phones Trademark Free Notice Review our Privacy Policy Service Agreement Legal Notice Privacy Policy|Do Not Sell or Share My Personal Information
cyano: 30万個ぐらいの静的ファイルを配信するサーバーの選び方
naoyaさんが公開されてるInside Hatena Bookmark's Backend の資料などを読むと、mod_perlなサーバーやMySQLサーバーの選び方の参考になったりするわけですが、世の中を見渡してみても、静的コンテンツ（画像とか）を配信するサーバーの指南書らしきものはなかなか見あたりませんでした。 なので、経験を元に書いてみることにします。 弊社の画像配信サーバーには、平均10kbぐらい（たぶん）の画像が30万個ぐらいあって、それをDell PowerEdge 1750+lighttpdを使って配信してます。 以前は搭載メモリ1GBのサーバーを使っていたのですが、その時のvmstatがこのような感じ。 procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---- r b sw
動画配信の負荷分散は比較的簡単 - 最速配信研究会(@yamaz)
http://d.hatena.ne.jp/naoya/20060407/1144376197 ではてなおやさんがYouTubeの負荷分散について語っておられる. mixiの負荷分散とは質が違うことについてはおおむね同意だけど, YouTube のシステムを見たときにその焦点になるのは、まず第一にネットワーク帯域。第二にストレージをどうしているかというところじゃないかなと思います。動画配信にリソースがいるポイントは、ネットワーク帯域とディスク I/O です。つまり YouTube の負荷分散で気になるところは * ネットワーク帯域 * ストレージ o 容量の管理 o 動画を格納しているストレージサーバーの I/O あたりです。 はちょっと踏み込み足りないなぁという印象なので書いておく.集合知.集合知. 動画配信は通常の画像配信と違って下記の特性を持つ. 画像のように1ページに複数個配信する
画像配信の負荷分散も比較的簡単？（その1） - 最速配信研究会(@yamaz)
30万個ぐらいの静的ファイルを配信するサーバーの選び方 で静的な配信サーバに関することが述べられている. naoyaさんが公開されてるInside Hatena Bookmark's Backend の資料などを読むと、mod_perlなサーバーやMySQLサーバーの選び方の参考になったりするわけですが、世の中を見渡してみても、静的コンテンツ（画像とか）を配信するサーバーの指南書らしきものはなかなか見あたりませんでした。 なので、経験を元に書いてみることにします。 ということらしい.書いてあることはすべて同意だけど, つい3ヶ月くらい前まで 平均15k×1万URL×50億httpアクセス/day 平均4KByte×100万URL×3億HTTPアクセス/day な画像サーバと某所で向き合ってたため,ちょっとは役に立てるかもしれないと思ったので,私の経験を書いてみようと思う. 動画配信の負荷分
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Web高速化 || パフォーマンスチューニングBlog: インターオフィス
