先週金曜日、BPStudy#25で、「パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ」という題目で話をさせていただきました。その際に使用した発表資料は以下のとおりです。 1. Happy Optimization 最初に、最適化の考え方として、上限値を予測し、それを元にリソース配分を考える、という手法を説明しました。
Kazuho@Cybozu Labs: パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ (BPStudy#25発表資料)
先週金曜日、BPStudy#25で、「パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ」という題目で話をさせていただきました。その際に使用した発表資料は以下のとおりです。 1. Happy Optimization 最初に、最適化の考え方として、上限値を予測し、それを元にリソース配分を考える、という手法を説明しました。
mysql と drizzle の負荷テストツール「skyload」が凄い！ - kazuhoのメモ置き場
tmaesakaさんがやってくれました。 ずいぶん前からSQLのベンチマークを測定するのに使いやすいプログラムないかなーと思ってました。個人的にはmysqlslapというのを使ってたのですが、幾らか気に入らない所があったりコマンドラインオプションが複雑で毎回 --help を読んだりしていました。余計な機能なんかなくて、指定したSQLを高速にくりかえしてくれる物が欲しいなぁって思ってたんです。 とあるIRCでこの前、tmaesakaさんから「いま作ってる」という話を聞いて、いろいろ要望を言ってたんですが、ついさっきチュートリアルが公開されました。速いw 名前はskyload。とても小さく、実装コードだと800行程度です。しかもオプションが少ないので使い方が単純です。試しに適当な INSERT の速度を測ってみました。 $ skyload --server=localhost --mysql
アルゴリズム - 同じ文字列のn回繰り返しをlog n回で作る方法 : 404 Blog Not Found
2009年01月31日01:00 カテゴリLightweight LanguagesMath アルゴリズム - 同じ文字列のn回繰り返しをlog n回で作る方法 これなのですが.... 同じ文字列のn回繰り返しを作る最速の方法を探求してみた - muddy brown thang ちょっとした事情により、ある文字列のn回繰り返しを作る関数 (PHPでいうところのarray_repeat(), Perlで言うところの「"..." x n」、RubyやPythonで言うところの「"..." * n」) を高速に実装しなければならない状況に遭遇したのでベンチマークをとってみたところ、その結果がとても新鮮で驚いたので、これを共有しつつもダメ出ししてもらえないかなーと思って晒してみることに。 なぜかもっとシンプルな奴がなかったので。 以下、比較。初期値はIEにあわせてあります。Firefox/Saf
アプリ高速化のための５つのノウハウ
sonsonの経験則です． １．大量のメモリを使わない，メモリの確保と解放の繰り返しは避けて，再利用 ・メモリを大量に使用すると目に見えて実行速度が低下する．また，memoryWarningによる割り込みのメッセージが多発する可能性があるため，その処理にも時間がかかる． ・TableViewでセルの再利用APIが提供されているようにインスタンスの確保と解放の繰り返しは大きく速度に影響を与える．（SDKが出る前，Jailbreak時代は再利用関数を自前で作ってたなぁ・・・） ２．恒久的に使いそうなオブジェクトはなるべく保持する ・利用しているクラスにメモリリークがあると，それの確保・解放を繰り返している内にメモリがどんどん食いつぶされる．怪しいクラスは特に注意して使うようにする．まぁ，なんら抜本的な解決策ではない気もしますが（アップル頼むよ）． ３．背景に透明色を使わない ・ついつい
JavaScript++かも日記: 【prototyoe.js】prototype.js＋scriptaculous.jsのロード時間
Ajaxで今よみがえる(^^;;-->[クロスブラウザ技術 ]DHTMLサンプル集 古籏一浩さんとのはじめての共著 発売中-->『Ajax実践テクニック』 古籏一浩/高橋 登史朗 (著)秀和システム 配本予約開始-->『入門Ajax 増補改訂版 』 高橋 登史朗 (著)ソフトバンククリエイティブ ; ISBN: 4797336242 このページは[ 入門 Ajax ](ソフトバンククリエイティブ )と[ だれでもカンタンJavaScriptサンプル集 ](秀和システム)と [ だれでもカンタンDynamicHTMLサンプル集 ](秀和システム)などの著者 でAllaboutのJavaScriptガイド とか牛久大仏の足元で草むしりをしながら 暮らしている【高橋登史朗】によるサポートページ 兼 無駄話ブログです *このスクリプト動かないよ〜、とかの情報は 各「コメント欄」へ書き込ん
naoyaのはてなダイアリー - サーバーを増やせばいいんじゃない、サーバーを増やすだけで解決できるように努力するのだ
ライブドアの技術の話について書いた、その記事のコメント欄。最初は感情的な批判などがあって話題とは別の方向で炎上し気味だったんでうーんと思ってたんですが、後半になってきて少し面白い議論が出てきました。 こんな反応があった。 アクセス数が増加している段階で、ApachやAppServerのスレッド数をいじろうが、ヒープサイズを増やそうが、DBのパラメータをいじろうが、はてまたアプリを書き直そうが、性能要求にミートするには相当のワークが発生しますし、どう最適化、チューニングしても追いつきません。そのようなチューニングにお金をかけるならサーバーを追加したほうが安く上がるのではないかと思うのですが、如何でしょう? それに対する僕の返信は、 確かに何千万もするファイルサーバーとか、ロードバランサーとかで問題が解決できる機会っていうのは存在すると思います。なので ”負荷が高ければ、結局サーバーを単純に増
ユメのチカラ: ５００万倍のスケーラビリティ
カーネル読書会で、mixiのバタラさんにmixiのシステムをどのようにスケールアップしたかの話を聞く。開催以来最多の90名の登録（会場の都合で90名で登録を終了した）で、会場は立ち見が出るほどの盛況であった。宴会も50数名の参加をえてこれも大盛況であった。（大よっぱらいの人もいたけど（笑）） 内容はYAPCでの発表をアレンジしたものである。ようさんの日記に詳しい報告がある。 システムを1ユーザから500万ユーザまで約2年半でスケールアップしたというお話で、苦労話満載の非常に興味深いものであった。様様な試行錯誤をへて現在のシステムにいたっているが、1ユーザから500万ものユーザをサポートするなどというスケーラビリティはあらかじめ設計されていたものではない。問題にぶつかるたびに一つ一つ問題を解決していって今に至るということである。この500万倍のスケールアップと言うのは本当にとてつもないことで
MySQL
HeatWave Use automated and integrated generative AI and machine learning (ML) in one cloud service for transactions and lakehouse scale analytics. Get faster insights from all your data with unmatched performance and deploy apps in your choice of cloud providers. Learn More » MySQL Enterprise Edition The most comprehensive set of advanced features, management tools and technical support to achieve
404 Blog Not Found:あなたのページを最速にする14の掟
2007年05月11日18:45 カテゴリiTech あなたのページを最速にする14の掟 人気Webサイトの管理人、必読。 紹介ページ: 14 rules for fast web pages (Skrentablog) PPTのスライド: http://www.web2expo.com/presentations/webex2007/souders_steve.ppt 実は、これらはYahoo!の"Chief Performance Yahoo!"(本当にそういう役職名)であるSteve Soudersによる以下のblog entriesをまとめたもの。 Performance Research, Part 1: What the 80/20 Rule Tells Us about Reducing HTTP Requests Performance Research, Part 2:
最速配信研究会 - ロードバランサの運用.DSRって知ってますか
id:hirose31くんがロードバランサについてあれこれ書いてる. そんなわきゃない＞DNS RRはロードバランサの座を奪い返せるか この間彼から教えてもらったんだけどLVS(LinuxVirtualServer)は結構すごいという話. 「でも安定性がぁ」とか「ASICには勝てないよね」といかいうやつは、まずは試してみてみー きっとびっくりするから。 ロードバランサの1運用形態であるDSR(Direct Server Return)を知らない人だと「ソフトウェアでロードバランサ?ありえねー」とか思っててもしかたないと思う.DSRを知らないといつまでもベンダーに高いお金を払うことになるのでチョロチョロ書いてみる. DSRを知らない人がロードバランサーに持っているイメージは図の1の通りだと思う.つまり HUBを通してリクエストがロードバランサに届く(1,2) ロードバランサは適当にバランシン
MySQLノウハウ
いろいろな本からメモってきたメモのメモ。出典を書いておくのを忘れた。思い出し次第補完するかも。 deleteのコストは高いので、無効化を示すフィールドを作ってupdateすべき slow query logに要注意 多くのエントリでほとんどのフィールドが同じ値を持つ場合はインデックスの効果が小さい →複合インデックスの効果が大きい 複合インデックスは指定の順番が大切。AとBという指定の場合、A単独でもインデックスの効果がある。逆は真でない。 インデックスが使われる場面は フィールド値を定数と比較するとき (where name = 'hogehoge') フィールド値でJOINするとき (where a.name = b.name) フィールド値の範囲を求めるとき (<,>,between) LIKE句が文字列から始まるとき (where name like 'hoge%') min(),
MasteringMemcached
2008-09-27 17:53:11 +0900 (78d); rev 114 この文書について 分散型メモリオブジェクトキャッシングシステムである memcached について、その仕組み、導入やプログラミング言語からの利用方法までを紹介します。 この文章は常に書きかけです。誤字脱字や間違いの指摘や情報提供などを歓迎します。 この文書の対象者 memcached の導入を検討しているひと memcached をプログラミング言語から利用する方法を知りたいひと memcached の仕組みや仕様を知りたいひと 環境について 以下のような環境を想定しています。 UNIX および UNIX ライク OS x86 アーキテクチャ memcached は x86 以外のアーキテクチャでも動作しますが、この文書では x86 前提として記述します。 memcached とは memcached は
mir the archive
Contents 更新:2007/08/31 MySQL内部アーキテクチャとソース解析 モジュールと相関図 主要クラスと構造体 ユーティリティ関数 プリプロセッサマクロ グローバル変数 ストレージエンジンインタフェース MySQL Hacking Tips InnoDB関連のソース解析 InnoDB起動プロセス InnoDBバッファプールに関するソースコメントの和訳 InnoDB Record構造 MySQLの拡張 可変引数を持つNativeなSQL関数の実装方法 WarningとErrorの出力方法 HelloWorldネタ GNU AutotoolsでHello World! その他 サンプルコード集 当サイトと管理者について
livedoor Techブログ : nowaのサーバ構成
こんにちはスエヒロです。 今回は弊社が提供しているブログサービス「nowa」(ノワ http://nowa.jp)の仕組みをサーバ構成を中心に紹介したいと思います。 nowaでは一般的なブログサービス要素とSNS要素の機能を実装しています。弊社には先行して提供している「livedoor Blog」、「フレパ」といった大規模なサービスがありますので、そちらの開発・運用で問題になった点などを参考にしつつ開発を進めています。具体的にはアクセスによる負荷への対策、データベースの分散化、画像のストレージング、冗長性、スケーラビリティといった点になります。 - ポータル(nowa.jp)、CMS(cms.nowa.jp) のサーバ構成 ポータルページ(nowa.jp)とCMSページ(cms.nowa.jp)は、静的なファイルのリクエストを捌く+動的なコンテンツへのリクエストをプロキシするフロントサーバ
ハタさんのブログ : Javascriptによる大規模開発の覚え書き。高速化編
前回書いた「Javascriptによる大規模開発の覚え書き」が凄いことになってました。 今回は、省略した「5.高速化せよ」について書きます。 僕にとってjavascriptは非常に高速な言語です。それは何が高速か 開発速度が高速である 開発速度、及びそこに至るまでの修得速度はとても高速です。動的言語を上手く操る開発者はもちろん、開発に不慣れな(言葉が悪いけど)新人達でさえ「動く」モノをサクっと作ってしまえる。 また、プラットフォーム(? というかブラウザ)が広く普及しているので、ググればスグに問題解決もできる。 それにローカルで簡単に作れる。javascript、それは動作環境を含めて高速です。 高速にUI操作ができる(UI操作が非常に簡単である) swingとかでUI操作をするには多くのオブジェクト操作をしなければならないけど、javascript(もといDHTML)は非常に簡単に
ステートレスとは何か
RestWiki をたまに見直すと新たな発見があって面白い。 たとえば先日、「ステートレスなやりとりとは何か(What is Stateless Interaction?)」という箇所を見つけて、興味深く読んだ。このページは以前も絶対に読んでいるはずなのだが、 人間は忘れてしまうものである。 RestWiki の例でも充分わかりやすいのだけれど、自分でも例を思いついたので書きとめておく。 ステートフルサーバとステートレスサーバはどう違うのか。 まずは、ステートフルの例: 客: こんにちは 店員: いらっしゃいませ。○○バーガーへようこそ 客: ハンバーガーセットをお願いします 店員: サイドメニューは何になさいますか? 客: ポテトで 店員: ドリンクは何になさいますか? 客: ジンジャーエールで 店員: +50円でドリンクをLサイズにできますがいかがですか? 客: Mでいいです 店員:
PHP コード最適化 Best Practices 63+ - カタコト日記
みたいなタイトルの記事を Digg 経由で発見。チートシート代わりにと思い超訳。*1 A Software Architect PHP 最適化 ベストプラクティス！ 01. static にできるメソッドは static として宣言しよう。（4倍速い） 02. echo の方が print より速い。 03. echo '文','字'; （カンマ区切り）の方が、'文'.'字' （ドット連結）より速い。 04. ループの最大値は、ループ「内」ではなく「前」にセットしておこう。 05. 大きい配列のような変数は unset() してメモリを解放しよう。 06. マジックメソッド（例： __get, __set, __autoload）は使用を避けよう。 07. require_once はハイコストなのです。 08. include や require でファイルはフルパスで指定しよう。 09
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ハイパフォーマンス Web サイト フロントエンドのパフォーマンスの重要性
Google Code Archive - Long-term storage for Google Code Project Hosting.