タグ

performanceに関するclayfishのブックマーク (19)

  • Firefox、メモリ、キャッシュ、SSD、RAMディスク

    Core i7、DDR3メモリトリプルチャンネル6GB、Intel SSDWindows7。この環境なら、何かのアプリケーションが重くていらだつことはもうないだろうと思っていたあの頃。 SSDの読み込みの速さによる、Windows自体の起動の速さ、アプリケーションの起動の速さにも慣れ、残ったのはFirefoxの動作の重さ…。 まさかWebブラウジングするだけの処理がここまで重いとは…。前の環境で重かった画像処理は快適になったのに、なぜブラウザがここまで重いのか…。 「FirefoxのAutoPagerizeが重かった」の後、ページ先読み用アドオンは「AutoPager :: Add-ons for Firefox」に変えていました。PCのスペックも上がったことで、再びAutoPagerizeに戻していたわけです。でも、やっぱり重い。Greasemonkey版やExtension版のAut

    Firefox、メモリ、キャッシュ、SSD、RAMディスク
  • 速くてコンパクトな JavaScript 用の sprintf の実装 - latest log

    [javascript][sprintf] で検索してたどり着く方が多いようなので、uupaa-0.7.js から切り出して張ってみます。 /*!{id:"uupaa.js",ver:0.7,license:"MIT",author:"uupaa.js@gmail.com"}*/ window.sprintf || (function() { var _BITS = { i: 0x8011, d: 0x8011, u: 0x8021, o: 0x8161, x: 0x8261, X: 0x9261, f: 0x92, c: 0x2800, s: 0x84 }, _PARSE = /%(?:(\d+)\$)?(#|0)?(\d+)?(?:\.(\d+))?(l)?([%iduoxXfcs])/g; window.sprintf = _sprintf; function _sprintf(fo

    速くてコンパクトな JavaScript 用の sprintf の実装 - latest log
  • High Performance Web Design ~デザインから考えるハイパフォーマンスWebサイト~ | warikiru

    2009-11-24 High Performance Web Design ~デザインから考えるハイパフォーマンスWebサイト~ ラベル: performance CSS Nite in ISHIKAWAで話をしてから1ヶ月経ったので、薄れゆく記憶の復習も兼ねて思いの丈を綴ってみたw High Performance Web Design 1. What's High Performance?ここでいうパフォーマンスというのはWebサイトの表示高速化についてです。つまり、ページをいかに早く表示させるかという課題です。でも、そうゆうのってサーバー側の問題でしょ?システムエンジニアの管轄じゃないの?と思われがちですが「ハイパフォーマンスWebサイト」の著者であるSteve Soudersの調査によると、80:20。一般的にユーザーの待ち時間の実に80%がブラウザ側、フロントエンドで費やされて

  • Facebookが大規模スケーラビリティへの挑戦で学んだこと(後編)~キャッシュが抱えるスケーラビリティの問題とデータセンターにまたがる一貫性

    Facebookが大規模スケーラビリティへの挑戦で学んだこと(後編)~キャッシュが抱えるスケーラビリティの問題とデータセンターにまたがる一貫性 全世界で3億人を超える会員を抱え、世界最大のSNSとなったFacebook。同社の技術担当バイスプレジデント Jeff Rothschild氏が、10月8日に米カリフォルニア大学サンディエゴ校で行ったセミナー「High Performance at Massive Scale-Lessons learned at Facebook」の内容を再構成して紹介します。 (この記事は「Facebookが大規模なスケーラビリティへの挑戦で学んだこと(前編)~800億枚の写真データとPHPのスケーラビリティ問題」の続きです) キャッシュがスケーラビリティに大きな役割を果たしている Facebookの主な役割は、ユーザーが簡単に(友人たちの)情報を集めることがで

    Facebookが大規模スケーラビリティへの挑戦で学んだこと(後編)~キャッシュが抱えるスケーラビリティの問題とデータセンターにまたがる一貫性
  • Facebookが大規模スケーラビリティへの挑戦で学んだこと(前編)~800億枚の写真データとPHPのスケーラビリティ問題

    Facebookが大規模スケーラビリティへの挑戦で学んだこと(前編)~800億枚の写真データとPHPのスケーラビリティ問題 全世界で3億人を超える会員を抱え、世界最大のSNSとなったFacebook。同社の巨大なシステムは、3つのデータセンターにある約3万台のサーバと、PHPC++、Memcache、MySQLなどのソフトウェア群によって支えられています(同社のデータセンターの巨大さは、記事「3億のユーザーを抱えるFacebookのデータセンター。移動は自転車、希望は100Gbイーサネット 」を参照)。 同社の技術担当バイスプレジデント Jeff Rothschild氏は、Facebookが実現している大規模なスケーラビリティを、いかにしてこれらのソフトウェアで実現しているのか、10月8日に米カリフォルニア大学サンディエゴ校で行ったセミナー「High Performance at Mas

    Facebookが大規模スケーラビリティへの挑戦で学んだこと(前編)~800億枚の写真データとPHPのスケーラビリティ問題
  • ウノウラボ Unoh Labs: サーバのネットワーク速度の調査/測定方法

    こんにちは。kyagi です。先日データセンタ内のサーバ群のうち、なぜか特定の1台だけネットワークの速度が極端に遅いという問題がありました。今回はサーバマシンのネットワーク速度の測定方法と原因についてお話しします。同様のトラブルが発生している方のお役に立てば幸いです。問題解決までの手順としては以下になります。 1. 現在の状態を調べる 2. ハード/ソフト含めて考えられる原因をいくつか挙げる 3. 原因について改善されるまでひとつひとつ検証していく まず現在の NIC の HW 情報とドライバを lspci で調査します。ここでは Broadcom の NetXtreme BCM5722 という NIC を使用していることがわかります。 # lspci -vvv | grep Ether 01:00.0 Ethernet controller: Broadcom Corporation

  • Kazuho@Cybozu Labs: パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ (BPStudy#25発表資料)

    先週金曜日、BPStudy#25で、「パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ」という題目で話をさせていただきました。その際に使用した発表資料は以下のとおりです。 1. Happy Optimization 最初に、最適化の考え方として、上限値を予測し、それを元にリソース配分を考える、という手法を説明しました。

  • 「テキストプロトコルは遅くないよ」という話 - kazuhoのメモ置き場

    「バイナリプロトコルは速い」「テキストプロトコルは遅い」という言説を、ときおり目にするけど、それって当なのか。個人的には、それって昔の話だと思ってる。 SMTP みたいな、ペイロードについてもターミネータ(とエスケープ)を使うプロトコル*1は確かに遅い。で、FTPプロトコルでは、大容量のデータを「高速」に転送するために、制御用のTCPコネクションと転送用のコネクションを分けたりしてた。 だけど、HTTPプロトコルは、テキストプロトコルだけど、ペイロードについてはターミネータを使わない。keep-alive を行う際には、Content-Length ヘッダ(あるいはchunkedエンコーディング)を使うことで、ペイロードのパース/変換処理を不要にしている。別の言い方をすると、テキストプロトコルだからと言って、バイナリプトロコルよりペイロードの処理時間が長くなるとは限らない。HTTP 以降

    「テキストプロトコルは遅くないよ」という話 - kazuhoのメモ置き場
  • Kazuho@Cybozu Labs: 「サーバ書くなら epoll 使うべき」は、今でも正しいのか

    多数のTCP接続をハンドリングするサーバを書くなら、1コネクション1スレッドのモデルではなく、epollやkqueueのようなイベント駆動型のI/O多重化を行うべきだ、と言われます。だが、そのような主張は、「C10K問題」が書かれた2002年から7年経過した今でも有効なのでしょうか? echoサーバを書いて、ベンチマークを取ってみることにしました。 ふたつのグラフは、いずれも接続数とスループットの関係を表しています。最初のグラフは、全接続がアクティブに通信した場合、あとのグラフは、全接続のうち小数のコネクションが順次アクティブになっていく、というモデルです。これらのグラフから、以下ようなことが読み取れます。 epoll も per-thread モデルも、良くスケールする epoll は、ワークセットが小さい場合に (最大50%) per-thread モデルよりも高速 少なくとも、1コネ

  • 30分でできる!Webサイトを高速化する6大原則 (1/4)

    Webサイトを制作するとき、「パフォーマンス」を気にしたことがあるだろうか? もしまったく気にしたことがないなら、気をつけた方がいい。閲覧に時間のかかる“遅いWebサイト”はユーザーにフラストレーションを与え、閲覧をやめさせてしまう恐れがある。 下記のグラフは、「Simple-Talk」という海外のオンラインメディアで発表されたユーザー調査の結果だ。アンケートページの表示にかかる時間を意図的にコントロールし、表示時間によってユーザーが感じるフラストレーションの違いを調べたものだ。 縦軸がフラストレーション(10段階)、横軸が表示までの時間を表している。1~5秒以内にページが表示された人に比べ、ページ表示までに5秒以上かかった人は2倍以上もフラストレーションを感じている。フラストレーションがあまりに高ければ、せっかく何らかの目的を持って訪れてきたユーザーも待ち切れずにブラウザーを閉じてしまう

    30分でできる!Webサイトを高速化する6大原則 (1/4)
  • ディレクトリの中にある大量の小さなファイルを高速に読み込む方法 - 射撃しつつ前転 改

    ディレクトリの中にある大量のファイルを高速に読み込む方法が知りたかったので、実験してみた。想定しているシチュエーションは、一つ一つのファイルは数KB程度だが数が多い、という場合である。適当な順番でアクセスすると、ランダムアクセスになってしまいとても時間がかかる。個々のファイルを読み込む順番はどうでも良く、すべてのファイルを処理することさえできればいいので、原理的にはシーケンシャルアクセスで処理できてしかるべきである。 まず、ファイルシステムについて。HDDやSSDなどのハードウェアにアクセスする際には、ファイル名などという概念はもちろん存在しない。ファイル名と実際のディスク上の対応を管理するのがファイルシステムの主な役割である。ファイルシステムは、ファイル名からそのファイルに対応するブロック番号(メモリアドレスみたいなもんだな)を調べて、そのブロック番号を指定してHDDやSSDにアクセスす

    ディレクトリの中にある大量の小さなファイルを高速に読み込む方法 - 射撃しつつ前転 改
  • JavaScriptの最適化について、code.google.comの記事の適当訳 - それ図解で。・・・tohokuaikiのチラシの裏

    GoogleがWeb全体のスピードアップにいよいよ格的に着手, 一社だけではできないと強調 からリンクのあった、 http://code.google.com/intl/ja/speed/articles/optimizing-javascript.html が日語かと思ったら日語じゃなかった・・・・。 いやー、意外とというか文字列については、全然知らんかった。 Closureって便利だし、「おぉ〜俺って使ってるジャン」みたいな気になれるからついつい使っちゃうんだけど、高コストなのね・・・・。反省。 ということで、超適当翻訳。どっかの誰かが書いてるかも。 前おき 著者: Google Chromeエンジニア Gregory Baker, Software Engineer on GMail & Erik Arvidsson 推奨される経験:JavaScriptの実践的な知識 クライ

    JavaScriptの最適化について、code.google.comの記事の適当訳 - それ図解で。・・・tohokuaikiのチラシの裏
  • TechCrunch | Startup and Technology News

    Welcome back to TechCrunch’s Week in Review — TechCrunch’s newsletter recapping the week’s biggest news. Want it in your inbox every Saturday? Sign up here. Over the past eight years,…

    TechCrunch | Startup and Technology News
  • Google Slides: Sign-in

    Not your computer? Use a private browsing window to sign in. Learn more

  • マルチコア時代のサーバ設計について - Happy Hacking Diary

    来年も作りたい!ふきのとう料理を満喫した 2024年春の記録 春は自炊が楽しい季節 1年の中で最も自炊が楽しい季節は春だと思う。スーパーの棚にやわらかな色合いの野菜が並ぶと自然とこころが弾む。 中でもときめくのは山菜だ。早いと2月下旬ごろから並び始めるそれは、タラの芽、ふきのとうと続き、桜の頃にはうるい、ウド、こ…

    マルチコア時代のサーバ設計について - Happy Hacking Diary
    clayfish
    clayfish 2008/05/08
    マルチスレッドの設計パターンがうまくまとまっている
  • ゆーすけべー日記: YourAVHost その後

    サキとは彼女の自宅近く、湘南台駅前のスーパーマーケットで待ち合わせをした。彼女は自転車で後から追いつくと言い、僕は大きなコインパーキングへ車を停めた。煙草を一吸ってからスーパーマーケットへ向かうと、ひっきりなしに主婦的な女性かおばあちゃんが入り口を出たり入ったりしていた。時刻は午後5時になる。時計から目を上げると、待たせちゃったわねと大して悪びれてない様子でサキが手ぶらでやってきた。 お礼に料理を作るとはいえ、サキの家には材が十分足りていないらしく、こうしてスーパーマーケットに寄ることになった。サキは野菜コーナーから精肉コーナーまで、まるで優秀なカーナビに導かれるように無駄なく点検していった。欲しい材があると、2秒間程度それらを凝視し、一度手に取ったじゃがいもやら豚肉やらを迷うことなく僕が持っているカゴに放り込んだ。最後にアルコール飲料が冷やされている棚の前へ行くと、私が飲むからとチ

    ゆーすけべー日記: YourAVHost その後
    clayfish
    clayfish 2008/01/18
    YourAVHost のアクセスをさばけるようになるまでにやったこと。スタティックコンテンツ分離とExpireヘッダによる。
  • 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(),

  • ActionScript3 最適化・高速化Tips 簡易まとめ - actionscriptグループ - ConquestArrow.addEventListener( LifeEvent.WORK, this.studyActionScript);

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    ActionScript3 最適化・高速化Tips 簡易まとめ - actionscriptグループ - ConquestArrow.addEventListener( LifeEvent.WORK, this.studyActionScript);
  • 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:

    404 Blog Not Found:あなたのページを最速にする14の掟
  • 1