タグ

パフォーマンスに関するwarabiのブックマーク (9)

  • サイトの速度 - MOL

    Stopwatch | By wwarby Flickr! こんにちわ、あなたの@t32k、ごきげんいかがでしょう。みなさんはスマホWebアプリ作っていて、自分の作ったものは速いのか遅いのか気になりませんかね?僕は木に泣くりまくりすてぃです。 そうゆうわけなもんで、表示速度とか計測してみようって話になるじゃないですかー、まさかストップウォッチで計測しないとは思うんですけどー、一応どのようにスピードを計測、そのアプリの性能を評価すればよいのか一緒に考えてみましょう。 僕が昔、ゴメス・コンサルティング(現:コンピュウェア モーニングスター) のセミナーに行ってきた時の話ですが、ここの会社はサイトパフォーマンスの計測サービスを提供していて、計測で重要なのは『定期的かつ継続的かつ同手法にてパフォーマンス測定』と言っておられました。 サービスリリース時はスモールスタートなのでアプリもコンパクトですか

    サイトの速度 - MOL
  • 大きめのテーブルにカラムやインデックスを追加する際の注意 - LukeSilvia’s diary

    先日大きめ(といっても500万行くらい)のテーブルにインデックス付きのカラムを追加しようとして痛い目にあったので調査。 大きめのテーブルにカラムやインデックスを追加するとどうなるか 今回は単純に、「ALTER TABLE 〜 」で追加しようとしました。追加するカラムは3つで、 varchar(255) インデックスなし varchar(255) ↓のdate 型カラムとマルチカラムインデックスの形式のユニークインデックスあり date インデックスあり SQL を実行し、状況を「SHOW PROCESSLIST」で監視していたら、1つ目のカラム追加で次のような状態に… 最初にState が「copy to tmp table」状態になり、次の状態に遷移するまで1時間かかる 次にState が「Repair with keycache」状態になり、完了までに1時間かかる 次のカラム追加に対す

    大きめのテーブルにカラムやインデックスを追加する際の注意 - LukeSilvia’s diary
  • パフォーマンスを求めて - お前の血は何色だ!! 4

    結局、わかったことは、 次の4つ。 index から 実体へのシークは遅い。 すべてがindex内で完結するクエリーは早い。 limit をつけても where や order by すると意味がない。 indexを張るなら Using indexe をゲットできないと負けかな。 では、select で取得する値すべてに index を張りますか? 場合によっては可能ですが、テーブルに文字列なんかがふんだんに含まれていると難しいものがあり、現実的ではありません。 そこでこんな方法を提案します。2段階にわけてクエリーを打ちます。 A. task テーブルの 2008/6/5 〜 2008/6/18 のデータを開始日順にならべて、先頭5件だけ表示せよ。 select SQL_CALC_FOUND_ROWS * from task where task.task_starttime <= '20

    パフォーマンスを求めて - お前の血は何色だ!! 4
  • PHP - ファイル名から拡張子を取得する関数、ベンチマークもあるよ - たきゃはしです

    拡張子取得、それは十人十色の関数である 一般的な拡張子を取得する方法は '.'を区切り文字として配列を作り、最後の要素を取り出す 拡張子があるであろう箇所を正規表現で検索、置換して取得する 最後に出る'.'を検索して以降を抜き出す など、他にもたくさんあります。 でも、パフォーマンスにバラつきはあるはずだし、 どうせなら「一番いいのを頼む」って考えるのが人の性ってもんですよね 拡張子を取得する関数たち エントリーNo1 正規表現の関数で配列に分割して最後の要素を取得する <?php $filename = '大きい画像a_1010.jpg'; $exts = split("[/\\.]", $filename); $n = count($exts) - 1; $ext = $exts[$n]; echo $exts[$n]; エントリーNo2 関数で拡張子を正規表現で検索、置換して取得する

    PHP - ファイル名から拡張子を取得する関数、ベンチマークもあるよ - たきゃはしです
  • 基礎から理解するデータベースのしくみ(5):ITpro

    SQL文を実行する際のパフォーマンスに大きな影響を及ぼすものとして,もう一つ,インデックスがあります。インデックスについては,どう定義すべきかというデータベース設計上の問題と,インデックスを有効に使うためのSQL文をどう書くべきかというコーディング上の問題があります。 ここではテーブル設計上の問題を主に取り上げます。SQL文のコーディングについては囲み記事「SQL文を最速にする11のポイント」を参照してください。 インデックスは,テーブルの検索速度を向上させるためのものです。それぞれのSQL文に対して最適なインデックスを定義するのが理想的ですが,実際にはある程度限られたインデックスで,必要なパフォーマンス要件を満たすようにインデックスを定義する必要があります。加えて,どんなSQL文が実際に発行されるのかがあらかじめわかっていない場合は,適当な想定に基づいてインデックスを定義しておかなくては

    基礎から理解するデータベースのしくみ(5):ITpro
  • CSSセレクタの高速化の話し - Webtech Walker

    続・ハイパフォーマンスWebサイトを読んでCSSセレクタの高速化の話しが面白かった(というか全然知らなくてちょっとびびった)ので紹介します。 セレクタは右から左に解釈される これは正直知らなくて、結構衝撃でした。 #foo .bar {} これはなんとなく#fooを探して、その中の.barを探している気がしてたんですけど、実は.barを探して、その親要素に#fooがあるかを探すそうです。なので特に#fooが必要なければ .bar {} と書いたほうが高速だということ。 また、以下の様に要素名で指定すると、その要素を全て探します。 #foo a {} これは一度a要素を全て探すので、できればaにclassをふって #foo .anchor {} とするほうが高速のようです。(#fooをとるとより高速) 特にユニバーサルセレクタなどは、 #foo * {} とすると、全ての要素の親要素に対して

    CSSセレクタの高速化の話し - Webtech Walker
  • サービス終了のお知らせ

    サービス終了のお知らせ いつもYahoo! JAPANのサービスをご利用いただき誠にありがとうございます。 お客様がアクセスされたサービスは日までにサービスを終了いたしました。 今後ともYahoo! JAPANのサービスをご愛顧くださいますよう、よろしくお願いいたします。

    warabi
    warabi 2009/12/14
  • ヤフーの画像はなぜyimg.jpドメインなのか? サイト高速化の手法とヤフーの失敗例 | 初代編集長ブログ―安田英久

    ヤフーの画像はなぜyimg.jpドメインなのか? サイト高速化の手法とヤフーの失敗例 | 初代編集長ブログ―安田英久
  • 「はてな流大規模データ処理」を見てきた - もぎゃろぐ

    KOF2008:関西オープンソース2008というイベントに来ています。 はてなの伊藤さんの講演があったので、講演メモを公開。 #ボクがメモした内容であって、100%言ったとおりに書いてあるわけじゃないので、参考としてご覧ください。 (続き) アジェンダ 大規模なデータ OSのキャッシュ MySQLの運用 大規模データアプリケーションの開発 データの例 はてなブックマークのデータ量:五千万件くらいのデータ量 このデータに対して何百万人がアクセスしてくる状況でどういう作りにするか レコード数 1073万エントリー 3134万エントリー 4143万タグ データサイズ エントリー2.5GB 何の工夫もなく普通にアクセスすると...200秒待っても結果が帰ってこない 大規模データの難しいところ 開発サーバで開発者が作っている時は快適に動いていても、多数の人間がアク

  • 1