仕事でMySQLのパフォーマンスチューニングをしていて、インデックスについて分かっていないことが多かったので調べたことをメモ。基本的なところから学習しなおした。 MySQLのインデックスは、カラムが特定の値をもつレコードの迅速な検索に使用される。インデックスを使用すれば、数百とか数億ものレコードが入っているテーブルから、一組のレコードを迅速に見つけて取り出すことが可能になる。 しかし、インデックスは速度を改善することもあるが、挿入の邪魔になって遅くなることもある。 インデックスを適切に使うために、まずはインデックスの基本概念をおさえる必要がある。 インデックスの概念 インデックスとは インデックスの仕組みを理解するには、まずMySQLがどのようにクエリに応答するかを知る必要がある。 例えば、 SELECT * FROM phone_book WHERE last_name = 'Hoge'
CakePHPで書かれたシステムが妙に重いと思ったら、想像もしないところにボトルネックがあったのを発見してしまった、ということがありました。 もともとの状況 ローカル環境で開発を始めたのですが、データベースへのアクセスもほぼないであろう、固定的なテンプレートを取得するのにすら11秒以上かかっていることに気づいて、いくらビルトインサーバと言ってもさすがに「これはおかしい」と調べてみることにしました。 Xdebugを仕掛ける こういうときは慌てず騒がず、まずは「推測より計測」ということで、PHPにXdebugを入れてプロファイリングしてみることにしました。xdebug.profiler_enable_trigger = 1と設定しておくことで、XDEBUG_PROFILEという名前のGET/POSTパラメーター、あるいはCookieをセットすることで、必要なときだけプロファイリングを行うことが
僕みたいなどうしようもない人が今こうやって生かされているのも、大事だとおもった仕事を発見し、こだわってきたことに尽きる。能力もセンスもないから経験の長さと集中した時間で補うしかない。2000年、正確には1997年の私にとってそれがウェブ解析であり、アクセス解析だった。ウェブ解析にもとずいたビジネスの測定、ビジネスの改善は「これはずっと大事でありつづける」との確信からだった。 2017年になった。バックトゥザフューチャー2の未来は過去になり。ビフ・タネンみたいな人がトランプという名前で大統領になるとは思わなかった。2016年から不条理な仮説が現実になり続けている。私が2017年に20代だったらウェブ解析の専門家を目指すか?といえば答えはNoだ。いまや専門家はたくさんいて、改善方法も測定方法も研究され尽くされているので、根性も直感力もない私が伸びる可能性はない。 私がウェブ解析をやろうとして2
やっと表示速度の認知に火がつき始めた 2016年も、残り一ヶ月となりまして、WebサイトパフォーマンスのAdventカレンダーがスタートしましたので、今年のWebサイトパフォーマンスの動向を振り返ってみます。 今年の1月から3月、日本のECサイト売上上位150社に営業をかけて、色々とお話したのですが、ECサイト関係は、まだまだ表示速度の重要性を認知していない事が分かりました。 4社が興味を示してくれましたが、「配信品質管理」という認識まではやっぱり無かったです。 「日本はこのまま品質管理としてのWebサイトパフォーマンスが普及せずに今年も一年が過ぎてしまうのか?」と危機感を抱き、今年は、以下のカンファレンス等で講演の機会を頂きました。 関西フロントエンドUG主催 frontend conference 2016 「Webサイトパフォーマンスの基礎知識」 Movable Type Devel
At Tumblr, we’re always looking for new ways to improve the performance of the site. This means things like adding caching to heavily used codepaths, testing out new CDN configurations, or upgrading underlying software. Recently, in a cross-team effort, we upgraded our full web server fleet from PHP 5 to PHP 7. The whole upgrade was a fun project with some very cool results, so we wanted to share
現実的なWebサービス環境において、Docker化によるパフォーマンス低下がどの程度のものか調査するために、 ISUCON4 の予選問題のうち、Nginx と MySQL 部分を Docker 化してベンチマークをとってみた。 典型的なWebサービスシステムの3層構造(Proxy, App, DB)を構築し、ベンチマーカーにより高ワークロードを実現できるので、ISUCON の予選問題は適当な題材といえる。 Docker のパフォーマンスについて留意することは先日書いたエントリに全て書いてる。 上記のエントリを要約すると、Docker のパフォーマンスについて重要なこととは storage-driver の選択 (AUFS or Device mapper or ...) Volume の ON / OFF AUFS などの差分ファイルシステムをバイパスするかしないか Host networ
去年ソートに関する記事を書いたが、今日はその続きである。 MySQLでEXPLAIN SELECT...を実行するとExtraフィールドでよく見かける「Using filesort」という文字列。Filesortって一体なんだろう?と思ったことはないだろうか。単刀直入に言ってFilesortの正体はクイックソートである。 クエリにORDER BYが含まれる場合、MySQLはある程度の大きさまでは全てメモリ内でクイックソートを処理する。ある程度の大きさとはsort_buffer_sizeであり、これはセッションごとに変更可能である。ソートに必要なメモリがsort_buffer_sizeより大きくなると、テンポラリファイル(テンポラリテーブルではない)が作成され、メモリとファイルを併用してクイックソートが実行される。 Filesortは全てのソート処理において実行されるわけではない。前回の記事
下記のようなシステムでパフォーマンスが良さげな SQLite を使用予定ですが、もっと速いものが無いか確認のため他のデータベースのパフォーマンスを計測してみました。SQL 利用前提ですが、NoSQL が圧倒的な性能を出す場合は検討する必要があるので KVS も確認しました。 データ件数は 1 億件程度、JDBC SQL 利用可能 INSERT、UPDATE はバッチ SELECT は主キーアクセス性能を重視 将来スケールアウトのための分散はありえるが、スタンドアロンで遅いのはだめ データベースのパフォーマンス比較 計測したデータベース データベース名 タイプ 形態 評判 計測についての備考 SQLite RDB 組み込み ※2 おもちゃ、Android標準 JDBC操作 ※1 H2 RDB 組み込み ※2 組み込み最速 JDBC操作 ※1 Derby RDB 組み込み ※2 Java標準で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く