タグ

scalabilityに関するrekramkoobのブックマーク (27)

  • 「実現したいことを計算機の問題に置き換えることが『技術力』」、伊藤CTOが“はてな流”大規模データ処理の極意を語る:CodeZine

    CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

    「実現したいことを計算機の問題に置き換えることが『技術力』」、伊藤CTOが“はてな流”大規模データ処理の極意を語る:CodeZine
  • 最速配信研究会 - Web2.0とC10Kに関する数々の誤解

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

    最速配信研究会 - Web2.0とC10Kに関する数々の誤解
  • The C10K problem

    [Help save the best Linux news source on the web -- subscribe to Linux Weekly News!] It's time for web servers to handle ten thousand clients simultaneously, don't you think? After all, the web is a big place now. And computers are big, too. You can buy a 1000MHz machine with 2 gigabytes of RAM and an 1000Mbit/sec Ethernet card for $1200 or so. Let's see - at 20000 clients, that's 50KHz, 100Kbytes

  • Web2.0の先にあるC10K問題 ― @IT

    個々のクライアントがサーバに要求する処理量は小さなものでハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする――。これが最近Web開発者の間で話題となっている「C10K問題」(クライアント1万台問題)だ。 プロセス番号が足りなくなる パンクするのは例えばプロセス番号だ。 Ajaxの実装として最近注目されている技術に“Comet”(コメット)と呼ばれるものがある。HTTPのセッションをあえて切断せずに、サーバとクライアント間でつなぎっぱなしにするテクニックだ。Cometを使えばクライアントからのリクエストに応えるだけでなく、サーバ側からも不定期に情報を送り出すことができる。例えば、Web上でチャットサービスを実装するには、通常はクライアント側からサーバに一定間隔でポーリングすることで、ほかのユーザーの発言分をサーバから取得して表示するが、Cometの

  • twitterブームの陰で注目を集める“Erlang” - @IT

    2007/04/27 “twitter”がブームだ。140バイト以内の短いメッセージで“現在進行形”の自分のステータスをほかのユーザーとシェアするだけのオンラインサービスだが、国の米国はもとより、日でも非常な人気を集めている。Alexaでアクセス数の推移を調べると、今年に入ってから格的にブレークしている様子が分かる。4月22日にはニューヨークタイムズもtwitterと、サンフランシスコ在住の創業者2人を記事で取り上げている。 twitterのコミュニケーションツールとしての新しさ twitterに参加してみると、チャットやメール、SNSといった、既存のコミュニケーションツールのいずれとも異なる、不思議なつながり方が新鮮で楽しい。熱心にメッセージを更新するユーザーを見ていると、CUSeeMe、ICQ、mixiなどが登場したときに人々が示した熱狂に近いものを感じる。 twitterでは、

  • J-tokkyo

  • バッチ処理での処理分割による実行時間短縮方法【流通工房】

    HOME 流通工房について 各フェーズ定義 トピックについて ◆基構想 ◆システム化計画 ◆要件定義1 (データ構造) ◆要件定義2 (ロジック) ◆基設計 ▼実装OnePoint! ワークテーブル オンラインバッチ 画面起動ログ バッチ処理のポイント バッチ処理時間短縮方法 ジョブスケジューラ活用 Link ■サイトマップ ■書籍・プロフィール ■サイト内検索 ------------------------- <吉田君> 夜間バッチの業務データ処理全体を3時間で終わらせる必要があるのですが今回の150店舗 の発注処理だけでいろいろチューニングをしても4時間かかってしまっています。 もう少し、全体のバッチ処理時間を確保できませんか? <早瀬> 店舗からの売上データの集信時間と翌日のオンライン開始時間、そしてバッチ処理全体で 多少予備時間を見ておかなければならないことを考えるとこれ以上

  • 浮浪プログラマの始末書:バッチ処理並列化

    単体でのチューニングでは限界があるプログラムがでてきた。しょうがないので同一処理を複数同時に起動して並行実行できないかを検討中。 しかし、データを一括更新するバッチ処理なので、ディスクI/Oがボトルネックになっているらしく、vmstatでのCPU使用率は数%しかないんだが、こういう場合に平行実行しても早くなるものなんだろうか? アムダールの法則ってやつで。DBと同じマシンで実行されるのでネットワークの遅延もないし。 参考: バッチ処理での処理分割による実行時間短縮方法 - 流通工房 http://www.rkobo.net/4000/4005.html

  • ハタさんのブログ : PHP で並行処理するとして

    PHPでスレッドがあったらいいなーと思ったのはここ最近の事なのですが、僕がそうを思ったのはApacheの外へ出てしまったPHPたちがバックグラウンドで仕事をしていることを想定していたんですね。 ブラウザから起動するクエリで非常に重たい処理(S2Daoでも何でもいいんですが)をする場合、いったんブラウザ上からバッチ処理みたいな感覚でプロセスを分離する必要があります。(でないと処理が終わる || タイムアウトまでブラウザが応答待ちになる) で、処理を投げるまではいいんですが、その後処理の経過を知るためにはステータスコードというか終了コードを見る。という方法を教えてもらったんですが、どうもこれってカッコワルイ気がしてます。 んで、どっかにプールしている仕組みがあればいいんじゃね?という誰もが行き着きそうな所に行き着いたワケで。 絵にするとこんな感じ んで、少し調べた程度だと、PHPではWeb

  • 【事例】PostgreSQLの不足機能を自作し,500万人分のデータを管理---郵便貯金カード普及協会「会員管理システム」(下)

    図2●独自作成したDBアクセス・モジュールの主な機能 1つのデータベースを複数のサーバーに分割する「クラスタリング機能」と,テープからリストアする際にダウン直前までの状態を復元する「ロールフォワード機能」を独自に作成した 検索処理で時間がかかるのは全件検索であり,一般的に全件検索ではディスクI/Oがボトルネックになりやすい。NTTデータが作成した「DBアクセス・モジュール」を使えば,ディスクを共有しないクラスタリング構成が実現でき,ディスクI/Oを分散できる。DBアクセス・モジュールは,参照時には複数のサーバーにSQL文を発行し,それぞれの結果をマージして返す機能がある(図2左[拡大表示])。 また,DBアクセス・モジュールにはデータの更新時に2台のサーバーにSQL文を発行する機能があり,データを2重化させることができる。2重化しておけば1台のディスク装置が壊れても,もう一方のディスクで処

    【事例】PostgreSQLの不足機能を自作し,500万人分のデータを管理---郵便貯金カード普及協会「会員管理システム」(下)
  • 【事例】PostgreSQLの不足機能を自作し,500万人分のデータを管理---郵便貯金カード普及協会「会員管理システム」(上)

    「PostgreSQLOracleを検証した結果,工夫すればPostgreSQLでも可能だと判断した」――郵便貯金カード普及協会のシステム開発を担当したNTTデータの渡部広志氏は,PostgreSQLの採用理由をこう説明する。 システムで処理しなければならないのは,約500万人分の会員データ。会員は今も増えており,システムの仕様としては会員数1000万人を想定している。PostgreSQLの検索性能は検証した結果高いことが分かったが,1000万人規模のシステムで使うにはPostgreSQLの標準機能だけでは足りなかった。 どんな検索でも10秒以内 図1●システム概要とシステム構築上のポイント 約500万人の会員データを管理するシステム。将来的には会員が1000万人になることが予想されるため,大量データに対する高い検索性能が求められた。また,オンライン処理は24時間365日利用するため,高

    【事例】PostgreSQLの不足機能を自作し,500万人分のデータを管理---郵便貯金カード普及協会「会員管理システム」(上)
  • PostgreSQLで効率的な負荷分散を実現し、モバゲーやmixiを追撃 ― TechTargetジャパン

    オープンソースのPostgreSQLでシステムを構築 10代、20代を中心に急激な普及を見せる“ケータイSNS”。会員数が865万人に達する「モバゲータウン」や月間118億ページビュー(PV)を誇る「mixi」(約6割がモバイル経由)など、大手SNSサイトが存在感を増している(数値はいずれも2007年12月現在)。そうした中で先行組を激しく追撃しているのが、オープンドアが運営する携帯電話向けのSNSサイト「大集合NEO」だ。 2007年1月にスタートした大集合NEOは、SNSのみならず、アバターゲーム小説、動画、日記、チャットなどのサービスをすべて無料で楽しめるのが特徴だ。アバターやサイト内通貨の使い勝手の良さで先行サイトと差別化を図り、2007年夏に50万人だった会員数が2008年2月時点で2倍の100万人に達している。 その大集合NEOのシステム基盤を担っているのは、MySQLとオ

    PostgreSQLで効率的な負荷分散を実現し、モバゲーやmixiを追撃 ― TechTargetジャパン
  • Ubuntu、Symfony、Lighttpdを使ってスケールするWeb 2.0サイトを構築する - PHPプロ!ニュース

    平素より「PHPプロ!」をご愛顧いただき、誠にありがとうございます。 2006年より運営してまいりました「PHPプロ!」ですが、サービスの利用状況を鑑みまして、2018年9月25日(火曜日)をもちましてサービスを終了させていただくことになりました。 サービス終了に伴いまして、2018年8月28日(火曜日)を持ちまして、新規会員登録ならびにQ&A掲示板への新たな質問、回答の投稿を停止させていただきます。 なお、ご登録いただいた皆様の個人情報につきましては、サービス終了後、弊社が責任をもって消去いたします。 これまで多くの皆様にご利用をいただきまして、誠にありがとうございました。 サービス終了に伴い、皆様にはご不便をおかけいたしますこと、心よりお詫び申し上げます。 件に関するお問い合わせはこちらよりお願いいたします。

  • 負荷対策概論 - 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▪ 海底捞:"吃出卫生巾"系人为当事顾客

  • mixi Engineers’ Blog » Tokyo Tyrantによる耐高負荷DBの構築

    連休中はWiiのマリオカートをやりまくってやっとVR7000越えたmikioです。愛車はマッハ・バイクとインターセプターです。さて今回は、分散ハッシュデータベースサーバTokyo Tyrantでmixiの最終ログイン時刻を管理するようにした時の苦労話を書きます。 ログイン処理は負荷地獄 mixiでは、全てのユーザについて、各々の最終ログイン時刻を管理しています。「マイミクシィ一覧」や「お気に入り」などの画面で、友人が近い時間にログインしていてコミュニケーションがとりやすい状態にあるかどうか確認できるようにするためです。 mixiのほぼ全てのページはログインしないと見られないページなので、ほぼ全てのページにアクセスされるたびにログイン確認が行われます。したがって、最終ログイン時刻はほぼ全てのページにアクセスされる度に更新されることになります。mixiの中で最も重いデータベースのひとつとして「

    mixi Engineers’ Blog » Tokyo Tyrantによる耐高負荷DBの構築
  • グーグル検索のダウンタイム、最短はブラジル--サイトモニタリング会社調査

    Googleを利用している米国人は、Googleの検索サイトへのアクセス時に問題に直面する確率が、ブラジル人の10倍にも上ることが、ある新しい調査で明らかになった。 2006年9月1日から2007年9月1日にかけて、32カ国におけるGoogleのアップタイムを計測した、スウェーデンのウェブサイトモニタリング会社Pingdomの調査によれば、ブラジルでのGoogle検索のダウンタイムはわずか3分だったのに対して、米国のそれは31分だったという。

    グーグル検索のダウンタイム、最短はブラジル--サイトモニタリング会社調査
  • mixiのシステム、海を渡る? MySQLの事例に

    印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 2004年2月にサービスを開始、わずか3年3カ月で1000万人以上のユーザを獲得したmixi。日を代表するソーシャルネットワーキングサービス(SNS)のシステムがMySQLの事例記事としてMySQL ABのサイトで紹介されている。 MySQL ABでは、MySQLのスケーラビリティを実証すべく「The 12 Days of Scale-Out」と呼ばれるキャンペーンを展開していた。mixiの事例はこの「番外編」のような形でDay Twelveの後に紹介されている。 MySQL ABによる事例記事の中ではmixiのシステム構成にも触れられている。同社はMySQLのマルチ・マスター・システムとパーティショニング機能を使ってスケーラビリティ

    mixiのシステム、海を渡る? MySQLの事例に
  • Milano::Monolog: mod_rewriteでサーバーの負荷が高いときだけリダイレクトする

    mod_rewriteでサーバーの負荷が高いときだけリダイレクトする ワタシが働いている会社のホームページは、たまーにYahooのトピックスからリンクされます。 トピックスに載るとそれはもう大量のアクセスが津波のように押し寄せてきて、あっというまにサーバーのリソースをいつぶしてアクセス不能になってしまいます。 こういうときのために、Contents Delivery Networkによるキャッシングも利用してます。 今までは、リンクされそうになったらmod_rewriteでリダイレクトって方法を使っていました。 でも毎回これをやるのが面倒になってきたので、なんとかならんかなーと思って、RewriteMapに初挑戦してみた。 RewriteMap使えばRewriteCondとかRewriteRuleにプログラムの出力結果を使うことが出来るようになるので、これでWebサーバーのロードアベレー

    Milano::Monolog: mod_rewriteでサーバーの負荷が高いときだけリダイレクトする
  • 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
  • naoyaのはてなダイアリー - Inside Hatena Bookmark's Backend の資料

    以下に置いておきました。遅くなってすいません。 http://bloghackers.net/~naoya/pdf/050404inside_hatena_bookmark.pdf 会場で前置きしたように、はてなブックマークは、はてなで一番大きなシステムであるはてなダイアリーあるいは同じ YAPC で発表のあった mixi に比べると、まだそこまで大きな規模ではありません。月間の PV はだいたい 4,000 万 PV 〜 というところです。 ただ、日でのトラフィックが上から 5 番目みたいな怪物サイトよりも、月間の PV が 1,000 万クラスのサービスの情報の方が、より現実的で役に立つのではないかと思い、はてなブックマークの裏側に絞って話しをしてみました。 ...という前提で見ていただけると嬉しいです。 はてなブックマークのデータのサイズもかなり大きくなってきたので、ぼちぼちパーテ

    naoyaのはてなダイアリー - Inside Hatena Bookmark's Backend の資料