Content-Length: 227405 | pFad | http://b.hatena.ne.jp/H_Yamaguchi/performance/
Webアプリケーションを高速化する50のトリック
MicrosoftのInternet Explorer PMであるJatinder Mann氏は、BUILD 2012でHTML5アプリとサイトを高速化する50のパフォーマンストリックというセッションで、Webアプリケーションを高速化する多くのチップスを提供した。 Mann氏が提供したアドバイスは、以下の6つの原則を中心に構成されていた。 1. ネットワークリクエストに迅速に応答する リダイレクトを避ける。上位1,000のWebサイトのうち63%は、リダイレクトを使用している。これらはリダイレクトをやめることによって10%のパフォーマンスを改善することができる。 メタリフレッシュを避ける。世界のURLのうち14%は、メタリフレッシュを使っている。 可能な限りユーザーの近くにあるCDNを使用してサーバーの応答時間を最小化する。 異なるドメインからのリソースをダウンロードすることによって、同時
第3回 設計段階で性能を見積もろう
Webアプリケーションの画面を設計するとき、皆さんは性能について意識していますか。機能面の要望を取り込むことに集中するあまり、性能は二の次になっていないでしょうか。 あとになって性能が問題になるプログラムは、設計時に過ちを犯していることが少なくありません。そのような性能トラブルは、チューニングで簡単に解決しないことが多いものです。設計時に性能リスクを明らかにして早めの対策を打っておけば、致命的な性能トラブルの多くを防げます。 今回は設計段階で性能リスクを早期に発見するための性能見積もり手法について紹介します。設計段階で性能を作り込む手法には、多様なものがありますが、今回解説するのはその前段階として必要になるものです。どの機能に対して、工数をかけて性能を作り込むべきかを明らかするのが狙いです。 性能を見積もるメリットは二つ 設計段階では動作するプログラムが存在しないので、性能評価においては、
Twitterのクジラ解剖学、あるいは彼らがいかにサーバの処理能力を向上させたか
Twitterを利用していると、ときどきクジラの絵の画面が表示されることがあります。これはTwitterの処理能力がパンクして一時的に利用不可になったときに表示されるお馴染みの画面。 2月9日にTwitter Engineeringブログにポストされたエントリ「The Anatomy of a Whale」（クジラの解剖学）では、Twitterのエンジニアたちがこのクジラの内部に分け入ってどのようにTwitterサーバの処理能力を向上させたのか、という話が詳しく語られています。 彼らが行ったのは、まず詳細なデータを取得して原因がどの辺にあるのかを推測すること。そこから多数の無駄な処理を発見し、ソースコードの修正による性能の向上に成功します。 元記事は非常に長いエントリになっていますが、問題の調査から解決に至るアプローチについて多くのエンジニアの方の参考になりそうな内容が含まれていますし、T
MongoDBのパフォーマンスをBerkeley DB, H2, MySQLと比較 - kaisehのブログ
スキーマレスのドキュメント指向データベース、MongoDBがとても面白そうだったので、Javaから使用した場合のパフォーマンスを計測してみました。 MongoDBはCouchDBに似たデータベースで、任意のオブジェクトを保存できますが、MVCCやREST APIを採用しないことで高パフォーマンスを追求しているようです。インデックスやレプリケーションのサポートも充実しています。 RDBMSをKey-Value Storageとして使う場合のパフォーマンス計測（H2, MySQL編） - kaisehのブログ 前に上記のエントリーでBerkeley DB, H2, MySQLのパフォーマンスを比較したことがあるのですが、そのときと同等の条件になるようにして計測しました。 具体的な計測方法は以下の通りです。 Mac OS 10.5.7, 2GHz Intel Core 2 Duo, 4GB Me
Javaメモリ、GCチューニングとそれにまつわるトラブル対応手順まとめ - 日記のような何か
GC周りでトラブルシューティングした際の経験や、Web等で調べたことをまとめてみる。 前提 ・JVMは、Sun Javaを想定。(他は使ったことないです。。。) ・Sun Java 1.5-1.6を想定。 目標 マイナーGC、Full GCそれぞれが頻発することなく、かつそれぞれの実行時間を1秒未満に抑えること。 マイナーGCは1秒未満どころではなく、もっと短くなるべき。どれくらいが理想かは？(0.1秒未満ぐらいを目指したい？) 連続した負荷状態(想定されるピークアクセス)でもOutOfMemoryErrorが発生しないこと。 理想的な状態は、上記に加えて、Full GCの発生が低頻度であること。 具体的には、できるだけマイナーGCで短命オブジェクト(1回使ったらもう使わないようなオブジェクト。逆にセッションオブジェクト等は長命オブジェクトとなる)を破棄させて、短命オブジェクトが、Tenu
Googleに学ぶ、ウェブページのパフォーマンスを最適化する方法
Web Performance Best Practices 下記、ウェブページのパフォーマンスを最適化するポイントをまとめたものです。 キャッシュの最適化 往復遅延時間を減らす HTTPリクエストを減らす ロードサイズを減らす レンダリングの最適化 関連書籍 1. Optimize caching キャッシュの最適化 ブラウザのキャッシュを活用 JavaScriptやCSSファイルや画像などのスタティックなリソースは、HTTPヘッダを使用してキャッシュをロードするようにします。 アドバイス スタティックなリソースは全て、積極的にキャッシュにセットします。 時々更新するリソースのキャッシュには、ファイルパスにフィンガープリントを埋め込みます。 IEでも確実にキャッシュされるように、Varyヘッダは削除します。 URLを自動生成している場合は、Fxのディスクキャッシュで使用している8文字のラ
“Stop the World”を防ぐコンカレントGCとは？
この表2のパラメータは、動作させるマシンのCPUが2個以上かつ物理メモリが2Gbytes以上の場合には、自動設定される。 ■Heapの全体サイズを指定する コンカレントGCでも、スループットGCと同じくHeapの全体サイズを指定する。ヒープの全体サイズは、以下を考慮に入れて設定する。 OSの空きメモリ量 Heapの全体サイズは、ハードウェアの搭載物理メモリ量から、OSやそのほかのソフトウェアが必要とするメモリ量を引いた値以下にする。これは、Heapのサイズを大きくし過ぎると、スワップが発生し大幅に性能が劣化するためだ アプリケーションが必要とするメモリ量 ユーザーごとにHttpSessionに積み込むオブジェクトのサイズや、キャッシュされたオブジェクトのサイズなど、必要となるオブジェクトのサイズを積算し、それ以上の値にする 実際には、アプリケーションが必要とするメモリ量を積算することは難し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fetched URL: http://b.hatena.ne.jp/H_Yamaguchi/performance/
Alternative Proxies:
syboos.jp
IBM Developer