タグ

Serverとdevに関するwebmarksjpのブックマーク (6)

  • サーバーエンジニアが入れておくと便利なFirefoxアドオン7選 - Unix的なアレ

    サーバーエンジニアといえど、ページ表示のパフォーマンスチューニングなどブラウザで確認したりすることはよくあると思います。 自分自身のメモもかねて、そんな際に自分がよく使用しているアドオンを紹介したいと思います。 firebug JavascriptCSSのコーディングをやる方にはおなじみですね。firebugです。私はjavascriptのDebugだけでなく、各コンテンツの取得時間を見る際にも使用しています。 https://addons.mozilla.org/ja/firefox/addon/1843 Yslow firebugに付加機能として追加できるyslowです。これもパフォーマンスチューニングの際には効果を発揮します。 expireの期間や、gzipしているかなどからそのページのパフォーマンスのランクを表示してくれます。 https://addons.mozilla.org

    サーバーエンジニアが入れておくと便利なFirefoxアドオン7選 - Unix的なアレ
  • 最速配信研究会 - ロードバランサの運用.DSRって知ってますか

    id:hirose31くんがロードバランサについてあれこれ書いてる. そんなわきゃない>DNS RRはロードバランサの座を奪い返せるか この間彼から教えてもらったんだけどLVS(LinuxVirtualServer)は結構すごいという話. 「でも安定性がぁ」とか「ASICには勝てないよね」といかいうやつは、まずは試してみてみー きっとびっくりするから。 ロードバランサの1運用形態であるDSR(Direct Server Return)を知らない人だと「ソフトウェアでロードバランサ?ありえねー」とか思っててもしかたないと思う.DSRを知らないといつまでもベンダーに高いお金を払うことになるのでチョロチョロ書いてみる. DSRを知らない人がロードバランサーに持っているイメージは図の1の通りだと思う.つまり HUBを通してリクエストがロードバランサに届く(1,2) ロードバランサは適当にバランシン

    最速配信研究会 - ロードバランサの運用.DSRって知ってますか
  • MasteringMemcached

    2008-09-27 17:53:11 +0900 (78d); rev 114 この文書について 分散型メモリオブジェクトキャッシングシステムである memcached について、その仕組み、導入やプログラミング言語からの利用方法までを紹介します。 この文章は常に書きかけです。誤字脱字や間違いの指摘や情報提供などを歓迎します。 この文書の対象者 memcached の導入を検討しているひと memcached をプログラミング言語から利用する方法を知りたいひと memcached の仕組みや仕様を知りたいひと 環境について 以下のような環境を想定しています。 UNIX および UNIX ライク OS x86 アーキテクチャ memcached は x86 以外のアーキテクチャでも動作しますが、この文書では x86 前提として記述します。 memcached とは memcached は

  • 「1人で開発したmixiが、会員数1000万人の国民的インフラに」、ミクシィ 衛藤バタラ 取締役最高技術責任者

    「1人で開発したmixiが、会員数1000万人の国民的インフラに」、ミクシィ 衛藤バタラ 取締役最高技術責任者 衛藤バタラ氏は、2004年2月にSNS(ソーシャル・ネットワーキング サービス)の「mixi」を立ち上げた人物。現在は、運営会社であるミクシィで取締役最高技術責任者を務める。 mixiの会員数は今年7月末時点で1110万人に上る。「当初から、日国民全員に会員になってもらうことが夢だったが、正直言ってここまで成長するとは思わなかった」。サービスを提供するためのサーバーは当初2~3台だったのが、今では数千台になっている。 衛藤氏は、無料のオープンソースソフトウエア(具体的にはLAMP=Linux、Apache、MySQLPerl)を駆使してmixiのシステムを1人で開発し、サーバーの設置などもこなしたという。今では自分でプログラミングをすることはないというが、30人強に増えた技術

    「1人で開発したmixiが、会員数1000万人の国民的インフラに」、ミクシィ 衛藤バタラ 取締役最高技術責任者
  • 30days Album Information | 30days Album を支える技術 #0 〜 サーバ構成概要

    こんにちは、mizzy です。30days Album では、全体的なシステムデザイン、ストレージ API の開発、サーバ構築などを担当しています。このブログでは、「30days Album を支える技術」と題して、裏側でどういった技術が使われているのか、ご紹介していきたいと思います。もちろん、技術スタッフは私だけではないので、他のスタッフにも各自担当した技術について紹介してもらう予定です。 第0回目は、サーバ構成の概要についてです。30days Album の論理的なサーバ構成は、以下の図のようになっています。(実際には、1台のサーバが複数のコンポーネントを兼ねていますので、物理的な構成はこの通りではありません。) 各コンポーネントと、コンポーネント間の関係について、もう少し詳細に解説します。 リバースプロキシが、直接ユーザさんから見えている唯一のサーバで、ウェブブラウザからのリクエスト

    30days Album Information | 30days Album を支える技術 #0 〜 サーバ構成概要
  • ユメのチカラ: 500万倍のスケーラビリティ

    カーネル読書会で、mixiのバタラさんにmixiのシステムをどのようにスケールアップしたかの話を聞く。開催以来最多の90名の登録(会場の都合で90名で登録を終了した)で、会場は立ち見が出るほどの盛況であった。宴会も50数名の参加をえてこれも大盛況であった。(大よっぱらいの人もいたけど(笑)) 内容はYAPCでの発表をアレンジしたものである。ようさんの日記に詳しい報告がある。 システムを1ユーザから500万ユーザまで約2年半でスケールアップしたというお話で、苦労話満載の非常に興味深いものであった。様様な試行錯誤をへて現在のシステムにいたっているが、1ユーザから500万ものユーザをサポートするなどというスケーラビリティはあらかじめ設計されていたものではない。問題にぶつかるたびに一つ一つ問題を解決していって今に至るということである。この500万倍のスケールアップと言うのは当にとてつもないことで

  • 1