先週金曜日、BPStudy#25で、「パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ」という題目で話をさせていただきました。その際に使用した発表資料は以下のとおりです。 1. Happy Optimization 最初に、最適化の考え方として、上限値を予測し、それを元にリソース配分を考える、という手法を説明しました。
Kazuho@Cybozu Labs: パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ (BPStudy#25発表資料)
先週金曜日、BPStudy#25で、「パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ」という題目で話をさせていただきました。その際に使用した発表資料は以下のとおりです。 1. Happy Optimization 最初に、最適化の考え方として、上限値を予測し、それを元にリソース配分を考える、という手法を説明しました。
Kazuho@Cybozu Labs: 「サーバ書くなら epoll 使うべき」は、今でも正しいのか
多数のTCP接続をハンドリングするサーバを書くなら、1コネクション1スレッドのモデルではなく、epollやkqueueのようなイベント駆動型のI/O多重化を行うべきだ、と言われます。だが、そのような主張は、「C10K問題」が書かれた2002年から7年経過した今でも有効なのでしょうか？ echoサーバを書いて、ベンチマークを取ってみることにしました。 ふたつのグラフは、いずれも接続数とスループットの関係を表しています。最初のグラフは、全接続がアクティブに通信した場合、あとのグラフは、全接続のうち小数のコネクションが順次アクティブになっていく、というモデルです。これらのグラフから、以下ようなことが読み取れます。 epoll も per-thread モデルも、良くスケールする epoll は、ワークセットが小さい場合に (最大50%) per-thread モデルよりも高速 少なくとも、1コネ
mysql と drizzle の負荷テストツール「skyload」が凄い！ - kazuhoのメモ置き場
tmaesakaさんがやってくれました。 ずいぶん前からSQLのベンチマークを測定するのに使いやすいプログラムないかなーと思ってました。個人的にはmysqlslapというのを使ってたのですが、幾らか気に入らない所があったりコマンドラインオプションが複雑で毎回 --help を読んだりしていました。余計な機能なんかなくて、指定したSQLを高速にくりかえしてくれる物が欲しいなぁって思ってたんです。 とあるIRCでこの前、tmaesakaさんから「いま作ってる」という話を聞いて、いろいろ要望を言ってたんですが、ついさっきチュートリアルが公開されました。速いw 名前はskyload。とても小さく、実装コードだと800行程度です。しかもオプションが少ないので使い方が単純です。試しに適当な INSERT の速度を測ってみました。 $ skyload --server=localhost --mysql
Velocity 2009 Day 2 | Carpe Diem
Surviving the 2008 Elections オープニングのあとの最初の講演。2008 年を通じて生き残った技術を紹介。資料は、こちら。 MySQL 3.23 系を使っているところが多い、停止してまで移行できるよい理由がない Proxy サーバとして、Apache 1.3 が使われはじめた Memcached は 2006 年から使われて Facebook をはじめ 2008 年でさらに使われるようになった Porxy サーバとしての Lighttpd、mod_magnet というリクエストをハンドリングモジュールにより使われるようになった(mod_magnet にMemcached のサポートが追加された) ハードウェアの進化、10 dual Xeon から 6 quad Xeons まで進化した(6コア使ってみたい…) NFS root がけっこう使われるとのこと 少ないコ
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
アルゴリズム - 同じ文字列の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
OProfileの使い方備忘録 - hogelogの日記
プログラムのボトルネックがどこにあるのか、なんて調べるときには計測する必要がありますね。プログラム中の特定処理の前後でrdtsc命令使って時間を計測して処理時間を求める、とかそういうこともできるんですけど、まあめんどうじゃないですか。プロファイラを使いましょう。 プロファイラとはなんぞや、Wikipediaの性能解析のページに色々書いてますね。 そういうわけでOProfileというLinuxで動くプロファイラを使っているので、未来の自分とか「OProfile動かしてみてーけどさっぱりわからん！」みたいな人のためにまとめておきます。 OProfileの特徴 OProfileは 計測したいプログラムに対して特別な処理をしなくてもいい 低レイヤーの情報も計測できる gprof形式のコールグラフも表示できる オーバーヘッドがとても小さい これらの特徴があるらしいです。使ってみて特に嬉しいと感じたの
アプリ高速化のための５つのノウハウ
sonsonの経験則です． １．大量のメモリを使わない，メモリの確保と解放の繰り返しは避けて，再利用 ・メモリを大量に使用すると目に見えて実行速度が低下する．また，memoryWarningによる割り込みのメッセージが多発する可能性があるため，その処理にも時間がかかる． ・TableViewでセルの再利用APIが提供されているようにインスタンスの確保と解放の繰り返しは大きく速度に影響を与える．（SDKが出る前，Jailbreak時代は再利用関数を自前で作ってたなぁ・・・） ２．恒久的に使いそうなオブジェクトはなるべく保持する ・利用しているクラスにメモリリークがあると，それの確保・解放を繰り返している内にメモリがどんどん食いつぶされる．怪しいクラスは特に注意して使うようにする．まぁ，なんら抜本的な解決策ではない気もしますが（アップル頼むよ）． ３．背景に透明色を使わない ・ついつい
スケーラビリティとユーザービリティの話
先日のPhotoShareのスケーラビリティのエントリーに関しては、さまざまなご意見をいただき、とても良い勉強になっている。ただし、少し分かりにくかった部分があると思うのでそこに関して補足しておく。 サーバーのスケーラビリティに関してはすでに色々なところに書かれているが、今回の私が注目しているのは、どうやってサーバーのキャパシティを増やすか、という話ではなく、サーバーのキャパシティを超えたトラフィックが来てしまった際にどんな挙動をするように設計しておくのが良いか、という話である。 限られた資源を使って数万人・数十万人の人たちにサービスを提供するかぎり、予想外の急激なトラフィック増加でサーバーに過負荷がかかったりすることはどうしてもあるわけで、そこで問題となるのは、その手の過負荷をどうさばくか。 たとえば写真に付いたコメントを表示させる場合、「最新の情報をすぐに」表示するのが良いのが当たり前
フツーな日常 - InnoDBを使うときのパフォーマンスチューニング
ストレージエンジンとしてInnoDBを使うときはMyISAMのときと触るべきポイントが違うので注意。 http://www.mysqlperformanceblog.com/files/presentations/OSCON2004-MySQL-Innodb-Performance-Optimization.pdf を読みながら取ったメモ。状況としてはRedHat AS3.0で動かしたときのDBT2*1のパフォーマンスを改善していくというもの。MySQL デフォルト状態での分析 Handler_read_nextが多い、つまりrange scanかindex scanが多すぎる slow query logで何が悪いかを引っかける 例では2秒以上処理にかかったqeuryを記録するようにしている 結果を分析 update文が遅かったけど、update文そのままではexplainできないので、
Vitamin Features » Serving JavaScript Fast
Learning to code can be fun! Get started today with a free trial and discover why thousands of students are choosing Treehouse to learn about web development, design, and business. Learn more With a starting salary of up to $75,000 per year, working in tech isn’t a job — it’s a career. Did you know? There are more than 500,000 positions in the tech industry waiting to be filled. Our Techdegree pro
JavaScript++かも日記: 【prototyoe.js】prototype.js＋scriptaculous.jsのロード時間
Ajaxで今よみがえる(^^;;-->[クロスブラウザ技術 ]DHTMLサンプル集 古籏一浩さんとのはじめての共著 発売中-->『Ajax実践テクニック』 古籏一浩/高橋 登史朗 (著)秀和システム 配本予約開始-->『入門Ajax 増補改訂版 』 高橋 登史朗 (著)ソフトバンククリエイティブ ; ISBN: 4797336242 このページは[ 入門 Ajax ](ソフトバンククリエイティブ )と[ だれでもカンタンJavaScriptサンプル集 ](秀和システム)と [ だれでもカンタンDynamicHTMLサンプル集 ](秀和システム)などの著者 でAllaboutのJavaScriptガイド とか牛久大仏の足元で草むしりをしながら 暮らしている【高橋登史朗】によるサポートページ 兼 無駄話ブログです *このスクリプト動かないよ〜、とかの情報は 各「コメント欄」へ書き込ん
Ajax なライブラリを使いまくって、自分のサイトが重くなってしまったら：Goodpic
This shop will be powered by Are you the store owner? Log in here
川o・-・）＜2nd life script.aculo.usのファイルサイズを軽減
http://www.goodpic.com/mt/archives2/2006/02/ajax.html で紹介されてる通り、script.aculo.usは通常のロードではファイルサイズが100KBを超えます。しかし、それはフルでロードしたときの容量なのです。script.aculo.usはロードするパッケージを選ぶことができる*1ので必要な機能だけを選べば良いのです。例えば、たいていの場合はscript.aculo.usのeffects.jsだけしか使わなかったりするので <script src="/js/scriptaculous.js?load=effects" type="text/javascript"></script> とすればOK。これでファイルサイズは34KBに収まります。また、二つ以上のパッケージを選択したい場合は <script src="/js/scriptac
Ajaxian Keeping your page load fast
Enterprise Strategy Group: Go-to-market Expertise to Help You Win
naoyaのはてなダイアリー - サーバーを増やせばいいんじゃない、サーバーを増やすだけで解決できるように努力するのだ
ライブドアの技術の話について書いた、その記事のコメント欄。最初は感情的な批判などがあって話題とは別の方向で炎上し気味だったんでうーんと思ってたんですが、後半になってきて少し面白い議論が出てきました。 こんな反応があった。 アクセス数が増加している段階で、ApachやAppServerのスレッド数をいじろうが、ヒープサイズを増やそうが、DBのパラメータをいじろうが、はてまたアプリを書き直そうが、性能要求にミートするには相当のワークが発生しますし、どう最適化、チューニングしても追いつきません。そのようなチューニングにお金をかけるならサーバーを追加したほうが安く上がるのではないかと思うのですが、如何でしょう? それに対する僕の返信は、 確かに何千万もするファイルサーバーとか、ロードバランサーとかで問題が解決できる機会っていうのは存在すると思います。なので ”負荷が高ければ、結局サーバーを単純に増
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
株式会社スタイルズ
https://labs.cybozu.co.jp/blog/kazuho/archives/2008/10/web_service_on_ssd.php
JavaScript++かも日記 - 1997年からの
123net :: 開発日記 � [雑記] 軽くした内容