タグ

performanceに関するuchoのブックマーク (14)

  • IDEA * IDEA

    ドットインストール代表のライフハックブログ

  • blog.8-p.info: Facebook の BigPipe と TTI

    Posted at 2010/10/22 01:59, Modified at 2010/10/22 03:42 Facebook のフロントエンドは結構かわったことをやっていて、例えば、ログイン後の http://www.facebook.com/home.php には <div id="pagelet_home_stream"></div> みたいな空の HTML があり、その後に <script>big_pipe.onPageletArrive({ … });</script> <script>big_pipe.onPageletArrive({ … });</script> ... と script 要素が何個もならんでいる。 BigPipe: Pipelining web pages for high performance この仕組みは (変数名のとおり) BigPipe と呼

    ucho
    ucho 2010/10/30
    MXHRとか、通信の頻度やタイミングを制御して高速化するテクニックがいろいろ出てきている気がする。単なるチューニングより一歩進んだ高速化技法、って感じ。
  • GitHub - MSDN Blogs

    In Visual Studio 2022 17.10 Preview 2, we’ve introduced some UX updates and usability improvements to the Connection Manager. With these updates we provide a more seamless experience when connecting to remote systems and/or debugging failed connections. Please install the latest Preview to try it out. Read on to learn what the Connection ...

    GitHub - MSDN Blogs
    ucho
    ucho 2010/10/28
    JavaScriptの実行時間に占める割合ってめちゃくちゃでかいんだな! 「高速化にはフロントエンド改善が重要」というのも納得。
  • W3CがWebアプリケーションの実行性能に関する標準仕様のワークグループ「Web Performance Working Group」を設置

    W3CがWebアプリケーションの実行性能に関する標準仕様のワークグループ「Web Performance Working Group」を設置 HTML5などの普及によって、Webブラウザはドキュメント閲覧ツールからアプリケーションプラットフォームへと変わっていく方向で進化しています。このとき、Webアプリケーションの開発者にとって重要な関心事項となってくるのがWebアプリケーションの実行速度です。 そこでW3Cは、Webアプリケーションの実行性能に関する標準について策定する「Web Performance Working Group」の設置を発表しました。 ページのロードや命令の実行にかかる時間を返すAPI このワークグループは、ベンチマークプログラムのようなものを開発するわけではありません。「Web Performance Working Group Charter」(Web Perfo

    W3CがWebアプリケーションの実行性能に関する標準仕様のワークグループ「Web Performance Working Group」を設置
  • プログラミング言語の速度とアプリケーションの速度がいかに関係ないかがわかるグラフ - kなんとかの日記

    まずは次の表をご覧あれ。これはプログラミング言語のベンチマークとして有名な Computer Language Benchmarks Game のベンチマーク結果。上にいくほど高速で、下に行くほど遅い言語になる。 これを見れば、最速な言語は C/C++ であり、Java や Haskell や OCaml といった静的な言語は軒並み上位に登場する。これに対し、RubyPythonPHP といったスクリプトは全部下のほう (つまり遅い)。その速度差は非常に大きく、このベンチマークで見ると Python3 や Ruby1.9 は C/C++ の約50倍から60倍遅く、Perl は約90倍、PHP にいたっては約130倍遅いことになる。 (ちなみに JIT つきの Lua が驚異的に高速なのが目をひく。この結果が当だとしたら、言語の速度に大きく関係するのは動的か静的かではなく、どれ

    プログラミング言語の速度とアプリケーションの速度がいかに関係ないかがわかるグラフ - kなんとかの日記
  • なぜTwitterは低遅延のままスケールできたのか 秒間120万つぶやきを処理、Twitterシステムの“今” − @IT

    ユーザー同士のつながりを元に時系列に140文字のメッセージを20個ほど表示する――。Twitterのサービスは、文字にしてしまうと実にシンプルだが、背後には非常に大きな技術的チャレンジが横たわっている。つぶやき数は月間10億件を突破、Twitterを流れるメッセージ数は秒間120万にも達し、ユーザー同士のつながりを表すソーシャル・グラフですらメモリに載る量を超えている。途方もないスケールのデータをつないでいるにも関わらず、0.1秒以下でWebページの表示を完了させなければならない。そのために各データストレージは1~5ms程度で応答しなければならない。 Twitterのリスト機能の実装でプロジェクトリーダーを務めたこともあるNick Kallen氏が来日し、2010年4月19日から2日間の予定で開催中の「QCon Tokyo 2010」で基調講演を行った。「Data Architecture

  • Twitterが分散フレームワーク「Gizzard」公開! Scalaで書かれたShardingを実現するミドルウェア

    Twitterが分散フレームワーク「Gizzard」公開! Scalaで書かれたShardingを実現するミドルウェア Twitterは独自に開発した分散フレームワークの「Gizzard」をオープンソースとして公開しました。GizzardはScalaで書かれたJavaVM上で動作するミドルウェアで、PHPRubyといったWebアプリケーションからの要求を自動的にデータベースに分散することで、大規模で可用性の高い分散データベースを容易に実現するためのものです。 Gizzard:フォルトトレラントな分散データベースを実現 The Twitter Engineering Blog: Introducing Gizzard, a framework for creating distributed datastores Twitterのブログにポストされた「Introducing Gizzard

    Twitterが分散フレームワーク「Gizzard」公開! Scalaで書かれたShardingを実現するミドルウェア
  • Twitterのクジラ解剖学、あるいは彼らがいかにサーバの処理能力を向上させたか

    Twitterを利用していると、ときどきクジラの絵の画面が表示されることがあります。これはTwitterの処理能力がパンクして一時的に利用不可になったときに表示されるお馴染みの画面。 2月9日にTwitter Engineeringブログにポストされたエントリ「The Anatomy of a Whale」(クジラの解剖学)では、Twitterエンジニアたちがこのクジラの内部に分け入ってどのようにTwitterサーバの処理能力を向上させたのか、という話が詳しく語られています。 彼らが行ったのは、まず詳細なデータを取得して原因がどの辺にあるのかを推測すること。そこから多数の無駄な処理を発見し、ソースコードの修正による性能の向上に成功します。 元記事は非常に長いエントリになっていますが、問題の調査から解決に至るアプローチについて多くのエンジニアの方の参考になりそうな内容が含まれていますし、T

    Twitterのクジラ解剖学、あるいは彼らがいかにサーバの処理能力を向上させたか
    ucho
    ucho 2010/02/15
    どうやってボトルネックを見つけ出し、性能を改善するか
  • 漢(オトコ)のコンピュータ道: MySQLを高速化する10の方法

    ちょっとキャッチ−なタイトルをつけてしまったが、今日は独断と偏見でMySQLを高速化する方法を10個紹介しよう。MySQLサーバをチューニングするときや初期導入する場合などに参考にしてもらいたい。 1. バッファを増やす、または減らす チューニングの基中の基であるが、適切なバッファサイズを設定することはパフォーマンスチューニングの要である。主なバッファは次の通り。 innodb_buffer_pool_size・・・InnoDBだけを利用する場合は空きメモリの7〜8割程度を割り当てる最も重要なバッファである。余談だが、実際にはここで割り当てた値の5〜10%ぐらいを多めにメモリを使うので注意が必要だ。 key_buffer_size・・・MyISAMだけを利用する場合は、空きメモリの3割程度を割り当てるといい。残りはファイルシステムのキャッシュ用に残しておこう。 sort_buffer_

    漢(オトコ)のコンピュータ道: MySQLを高速化する10の方法
  • マルチスレッド・プログラミングの落とし穴、その2

    ずいぶん前に、「マルチスレッド・プログラミングの落とし穴、その1(かもしれない)」というエントリーを書いたが、今回はPhotoShareサーバーを運営していて、まさにこのあたりの深い考察が必要になって来たので、良い機会なので続編エントリー。 PhotoShareのバックエンドのようにCRUD(Create/Read/Update/Delete)のAPIをサポートするバックエンドを作る場合、Create/Update/Deleteのリクエストに対してはクライアントからのAPIコール時にすぐに(HTTP Requestに返事をする前に)データベースに変更を加え、Readの際にも(キャッシュを使う・使わないを別にして)データベースの最新の状況を反映するデータを返すように設計するのが普通である。 このアーキテクチャの問題は、ユーザーのアクティビティが増えた時に、データベースやI/Oがボトルネックと

    ucho
    ucho 2008/09/23
    バックエンドのDBやファイルの処理をHTTPのハンドリングと非同期にして応答時間を短くしたらどうか?という話。コメント欄の議論も参考になる
  • サーバー並行性は現実,クライアント並行性は未来 - Radium Software

    Sutter's Mill - Server Concurrency != Client Concurrency Exceptional C++ の著者として有名な Herb Sutter さん。最近はソフトウェアの並行性 (concurrency) に関する啓蒙活動を精力的に行っている。その活動の一部は Dr. Dobb's の記事や氏のブログなどで見ることができる。 ソフトウェアの並行性や,それによって得られるスケーラビリティが,どれだけ重要なことかというのは,例えば Google が提供している様々なサービスなどを見てみれば実感できることで,最近ではそれほど珍しい考えではなくなっていると思う。 でも,それはあくまでもサーバー側の世界で起こっていることの話。 Google が持っているようなサーバーには,気の遠くなるような量のデータが格納されていて,それに対してとんでもない数のリクエス

    サーバー並行性は現実,クライアント並行性は未来 - Radium Software
  • MOONGIFT: ? サイトのパフォーマンス向上を目指そう「YSlow」:オープンソースを毎日紹介

    AjaxやCSSや様々なJavaScriptライブラリによって、サイトが豪華になっていく反面、全体的なシステムパフォーマンスは急激に悪化している。JavaScript等で、このサイトは重いなと感じる事が少なからずあるはずだ。 便利な機能を提供する限り、これは変えられないのだろうか。いや、そんな事はない。変えるべきポイントは幾つも存在する。それを的確にアドバイスしてくれるのがこのツールだ。 今回紹介するオープンソース・ソフトウェアはYSlow、Firebugと連携するパフォーマンスチェッカーだ。 YSlowはYahoo! Inc.により開発、提供されているソフトウェアで、FirefoxのアドオンであるFirebugと連携して利用する。パフォーマンスを改善したいサイトにアクセスし、YSlowのアイコンをクリックすれば良いだけだ。 チェックされる項目はHTTPリクエストの数、Gzip圧縮されてい

    MOONGIFT: ? サイトのパフォーマンス向上を目指そう「YSlow」:オープンソースを毎日紹介
  • IT戦記 - 一行で IE の JavaScript を高速化する方法

    以下の一行をすべての JavaScript の前に読み込む /*@cc_on _d=document;eval('var document=_d')@*/ この一行を読み込むことによって IE での document へのアクセスが 5 倍速くなります。 たとえば 以下のように、読み込む前と読み込んだ後を比較してみます。 // Before var date = new Date; for (var i = 0; i < 100000; i++) document; alert(new Date - date); // 643 /*@cc_on _d=document;eval('var document=_d')@*/ // After date = new Date; for (var i = 0; i < 100000; i++) document; alert(new Date -

    IT戦記 - 一行で IE の JavaScript を高速化する方法
  • Technologies for UI

    Technologies for UI List view Topics copyright livedoor 上下カーソルキーでスライドを切り替えられます。 表示されない場合はこちらから

  • 1