KOF2009「ウェブサービスのパフォーマンスとスケーラビリティ」 - stanaka's blog
KOF2009にて、「ウェブサービスのパフォーマンスとスケーラビリティ」と題して発表してきました。発表資料を以下に置いておきます。 Performance and Scalability of Web ServiceView more presentations from Shinji Tanaka. 概要は、「ウェブサービスのパフォーマンスを向上させスケーラビリティを高めるために、はてなでは様々な取組みを行っています。本セッションでは、はてなで採用している具体的な技術、ノウハウ、可視化手法と、それらの効果について紹介します。」というものです。 最近の、Interopやカーネル読書会あたりで話した内容をまとめつつ、レスポンスタイムの可視化という最近の取り組みについて話しました。 最近、レスポンスタイムについては、以下のようなグラフを使っています。 x軸がレスポンス時間、y軸がその時間内に収
MySQL Clusterが苦手とするJOINを如何にして克服するべきか。
シェアードナッシング型の負荷分散機能を持ち、なおかつ同期レプリケーションによるHA機能まで備えたMySQL Cluster最大の弱点といえば、JOINの遅さであろう。MySQL ClusterのJOINは偽りなく遅い。JOINを多用するアプリケーションでMySQL Clusterを利用するのはある意味マゾヒスティックな行為であると言えよう。何故MySQL ClusterはJOINが遅いのか？それはMySQL Clusterが分散データベースだからである。 ご存じの通り、MySQLにおけるJOINのアルゴリズムにはNested Loopしかない。他のストレージエンジンを利用していればそれでも十分実用に耐えうるぐらい高速なのだが、MySQL Clusterの場合はそうはいかない。JOINでは自ずとストレージエンジンからデータをフェッチする回数が増えるが、MySQL Clusterの場合レコード
Webでの非同期処理を考えてみる [長い記事だけどコメント求む!]
Photo by harry harris いまPhotoShareのサーバの実装を大きく変えようとして悩んでいます。 (参考: Life is beautiful: マルチスレッド・プログラミングの落とし穴、その２) Rails 2.2でThread safeになるとか、NeverBlockで12倍速くなるっていう話もあるんだけど、負荷が上がればレスポンスが悪くなるのは、どうしようもない。マシンを増やせば解決できる部分もあるけど、マシンを増やせばコストは上がる。 Life is beautifulで書かれていますが、確かに全部の処理を同期的に行う必要はないんですよね。 PhotoShareでも、既にいくつかのページは非同期にerbを生成して、それをRailsとerubisで読み込んで実行しています。 しかし、Railsだけではこういった非同期の処理やviewの一部を事前に生成するという処
![Webでの非同期処理を考えてみる [長い記事だけどコメント求む!]](https://cdn-ak-scissors.b.st-hatena.com/image/square/5bfe0ff7b7b40f7cbbbf772fcb58fe20116a468d/height=288;version=1;width=512/http%3A%2F%2Ffarm1.static.flickr.com%2F124%2F414124784_2ddd9e2e05_m.jpg)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
