MySQL(InnoDB)のSQLパフォーマンスチューニングのエッセンス
はじめに MySQL(InnoDB)でSQLのパフォーマンスチューニングをするときに役に立つ知識をエッセンスとしてまとめました。結合(JOIN)やB-treeインデックスの探索の仕組み、実行計画の基本的な見方を紹介します。 想定する読者は、SQLのパフォーマンスを改善する必要があるが実行計画をみてもいまいちピンと来ない方です。インデックスの作成の経験や、複合インデックスやカーディナリティの知識があることを前提にしています。目標は、実行計画の内容がよく分からない読者が、実行計画をみただけでクエリが実行される様子をイメージでき、自信を持ってクエリの改善にあたることができるようにすることです。 ストレージエンジンはInnoDBを前提としています。また、インデックスはB-treeインデックスを想定しています。全文検索の転置インデックスや空間検索のR-treeインデックスについては触れません。 イン
書評: ISUCONを「ゴール」で終わらせない。『達人が教えるWebパフォーマンスチューニング ～ISUCONから学ぶ高速化の実践』 - その手の平は尻もつかめるさ
達人が教えるWebパフォーマンスチューニング 〜ISUCONから学ぶ高速化の実践 作者:藤原 俊一郎,馬場 俊彰,中西 建登,長野 雅広,金子 達哉,草野 翔技術評論社Amazon 著者のid:catatsuyさんよりご恵投いただきました。ありがとうございます。実は著者の方から本を頂戴するのってはじめてです。 さて、この書籍のタイトルをはじめて見たときは「オッ、ついにISUCONの攻略本が来ましたね、これでワシも優勝間違いなしや！！」と思ったものですが実際に手に取ってみると必ずしもそうではないことに気付きました。むしろ「ISUCONで勝つための小手先のテクニック」のような話題は極力排除されており、高速かつ高可用なWebアプリケーションをどのように構築・運用していくか、というような実戦的な内容がその多くを占めています。 まず書籍の冒頭では「『Webアプリケーションのパフォーマンス』の定義」か
#ISUCON本 こと「達人が教えるWebパフォーマンスチューニング」について - uzullaがブログ
達人が教えるWebパフォーマンスチューニング 〜ISUCONから学ぶ高速化の実践を献本いただいた、なお、私は書籍のレビュアーである。 （注釈 最近こういうのどこまで公開しておかないといけないのかよくわからんけど書いておく、金はもらってないが、献本はいただいた。いや、本をもらう以上に自分のレビュー作業に工数はかかっているので得をしているわけではないし、増版しても俺の懐はあたたまらない。注釈終わり） 達人が教えるWebパフォーマンスチューニング 〜ISUCONから学ぶ高速化の実践 作者:藤原 俊一郎,馬場 俊彰,中西 建登,長野 雅広,金子 達哉,草野 翔技術評論社Amazon さて、献本いただいたから書く、レビュアーだから書く、というわけではないのですが、実際面白い本であることには間違いないので、エントリを書いてみる。 まとめ ISUCONにこれで勝てるわけではない。 期待していた皆様（？）
書籍「達人が教えるWebパフォーマンスチューニング」はチューニングの考え方を教えてくれる良本 - Gマイナー志向
通称 #ISUCON本 を著者様からご恵贈いただきました。ありがとうございます。 gihyo.jp 所感 この書籍、言っていいのかわかりませんがまったくの初心者・初学者には難しい本かもしれません。私の感触では、Webサイトのプログラム作成、改修、構築、運用などに携わったり、Webサイトのパフォーマンスの問題に向き合ったことがある人が対象読者だと思いました。職種でいえばバックエンドエンジニア、インフラエンジニア、SREなどですね。もちろんそういった職種を目指している方や、純粋にISUCONに挑戦したい、パフォーマンスチューニングに興味がある、といった方も含まれます。 この本は特定の問題に対する直接的な答えではなく、パフォーマンスチューニングの考え方を教えてくれる内容になっています。この本を参考に実際に手を動かして実践するのが良いでしょう。現実のWebサイトをチューニングするでもいいですし、そ
Webフロントエンドパフォーマンスチューニング80選 - Qiita
こんにちは、ぬこすけです。 近年、Webフロントエンドではサイトのパフォーマンスの重要性が高まっています。 例えば、GoogleはCore Web Vitalというパフォーマンスに指標を検索結果のランキング要因に組み込みました。 また、近年の某企業が「パフォーマンスの改善に取り組んだ結果、セッション数〇％アップ、CVR〇％アップ...」などの事例は枚挙にいとまがないでしょう。 パフォーマンスチューニングするためには、定量的に計測してボトルネックを探すようなトップダウンなアプローチもあります。 しかしながら、時には千本ノック的にハウツーを片っ端から試していくボトムアップなアプローチも有効になることもあったり、日々のコーディングでパフォーマンスを意識したコードを書くことは大切でしょう。 この記事ではパフォーマンス最適化のハウツーを紹介します。 パフォーマンス改善の施策が思い浮かばない時やフロン
JS のビルドサイズを極限まで絞るための TIPS 集
ビルドサイズ限界まで絞りたい人向け。 あらゆる環境で実践するものではないが、知ってたら簡単に避けることができるのもあるので知っておくと便利なTIPS書いていく。 基本ポリシー 未使用コードはビルド時に全部落とす。 何が未使用コードで、何が定数かわかるようなインターフェースを人間が心がける。 用語 Dead Code Ellimination(DCE) Rollup や Terser で、未使用コードを削除すること
SQLが重いときに見るお気軽チューニング方法
SQLのチューニング方法 昔Qiitaで書いたものをzennにうつして、若干の修正、追加をしてみました。 ORACLEでの経験を元に書いていますがコストベースのリレーショナルデータべースなら大体共通の考え方だと思うので他にも使えると思います。 SQLのチューニングといえば比較的容易に済むインデックスをとりあえず作成する。といった対応を取られがちですが、数万レコード程度でのデータ量ではあまり効き目がなく（自分の経験則）、どちらかといえば、結合順が大幅に狂ってたりすることが原因のことが多かったりします。よって本当にインデックスがないことが原因なのか？を熟考する必要があります。（例えばID以外のフラグとかコードに単項目indexを貼ってるのもみたことがあります。怖いけど実話） また、インデックスを作りすぎるとオプティマイザが狂いやすくなって他のSQLにも悪影響を及ぼしたりするので結構熟慮して追加
Webサービスエンジニアが教えるサーバサイドのログ分析 情報を可視化して負荷状況を見よ
ログ分析勉強会は、日々の業務に役立てられる「ログ分析」についての情報交換を目的として活動しています。オンライン開催となった今回、AWSに詳しい山口氏がWebサービスのパフォーマンス改善に必要なログ分析について、日々の業務から得た知見を共有しました。後半は、サーバーサイドから見たログ分析について。 サーバ情報を可視化して負荷状況を見る 続いて、サーバの負荷状況を見るところですね。リソースの情報をコマンドで取得してサーバ情報を可視化しましょうというところです。 よく使うのは、1つ目はhtopですね。htopでプロセスごとにどれくらいのメモリやCPUを使っているかを取っていくのがあります。リクエストが多いときにこれを取っていって、どこが重たくなっているかを見るというのがいいかなと思っています。 例えばアプリケーションサーバと同梱されているものだったりとかすると、アプリケーションサーバの負荷がいき
画像の遅延読み込みにloading属性とJavaScriptを併用した最大限のパフォーマンスを発揮させる実装方法
画像やiframeの遅延読み込みに使用するloading属性と非サポートブラウザ用にJavaScriptを併用した現代的なアプローチで、最大限のパフォーマンスを発揮させる実装方法を紹介します。 Best way to lazy load images for maximum performance by Adrian Bece 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 はじめに 遅延読み込みのloading属性とは 遅延読み込みの現代的なアプローチ パフォーマンスとLighthouseスコアの向上 最大のパフォーマンスを得るための画像最適化テクニック はじめに 画像の遅延読み込みは比較的簡単に実装でき、パフォーマンスを大幅に向上させることができるため、Webサイトを最適化するために使用される選択肢の1つです。遅延読み込みで
0から始めるNode.jsパフォーマンスチューニング
近年の Node.js は API のサーバとしてはもちろん、Nuxt.js や Next.js といった SSR や BFF などフロントエンドのためのバックエンド言語としての人気が高まっています。 フロントエンドエンジニアがコンテキストスイッチ少なくバックエンドの整備ができることは非常に大きな利点です。 ですが、フロントエンド（ブラウザ側）とバックエンド（サーバ側）ではパフォーマンスチューニングで見るべき点が大きく違います。 しかし Node.js アプリケーションのパフォーマンスイシューの見つけ方などがまとまっている資料は少ないです。 そこで、本記事ではフロントエンドエンジニアが Node.js でパフォーマンスイシューを見つけ、改善するため自分が普段パフォーマンスチューニングを依頼されているときにみている基礎的なポイトをまとめていきます。 1. 計測ステップlink Node.js
Go初心者が気を付けること
Go初心者がやってしまいがちなやらない方がいいことを書き出してみました。 情報検索や環境構築 golang.jpを見に行ってしまう Golang（ごーらんぐ）と呼んでしまう(by hogedigo) depが最新推奨のパッケージマネージャだと勘違いする(Go標準の「go mod」を使おう) 「GO？？？」環境変数を理解せずに設定しまくる（わからない場合は一切設定しないのが正しい） しょっぱなからgvm,gobrew,goenvなどのマルチバージョンのマネージャを入れようとしてエディタ連携環境構築に失敗する （複数バージョンのGoの運用は既に標準のGoだけでできるようになっている） エディタにgoimportsやgolintを設定し忘れる OSのパッケージマネージャまかせで古いGoやgccgoをインストールしてしまう エラーハンドリング周り err変数名のバリエーションを増やしすぎる（ほとん
[PHP] PHP-FPMのチューニングをするときに考えたことと行ったこと - Qiita
pm (必須) プロセスマネージャが子プロセスの数を制御する方法。 使用可能な値: static / ondemand / dynamic static - 子プロセスの数は固定される。 pm.max_childrenの値 = 子プロセスの数 となる。 ondemand - プロセスを必要に応じて立ち上げる。 リクエストされるとpm.start_serversで指定しただけサービスを開始する。 dynamic <- 我々のサービスはこれを採用している。 - 関連する設定値の内容によって、立ち上がる子プロセスの数が動的に決まる。 pm.max_children pm.start_servers pm.min_spare_servers pm.max_spare_servers pm.max_children pmの設定がstaticの場合 作成される子プロセスの数 pmの設定がdynamic
![[PHP] PHP-FPMのチューニングをするときに考えたことと行ったこと - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/d9d520da7f88f22d3827574f7aa964f0dd382074/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZ0eHQ9JTVCUEhQJTVEJTIwUEhQLUZQTSVFMyU4MSVBRSVFMyU4MyU4MSVFMyU4MyVBNSVFMyU4MyVCQyVFMyU4MyU4QiVFMyU4MyVCMyVFMyU4MiVCMCVFMyU4MiU5MiVFMyU4MSU5OSVFMyU4MiU4QiVFMyU4MSVBOCVFMyU4MSU4RCVFMyU4MSVBQiVFOCU4MCU4MyVFMyU4MSU4OCVFMyU4MSU5RiVFMyU4MSU5MyVFMyU4MSVBOCVFMyU4MSVBOCVFOCVBMSU4QyVFMyU4MSVBMyVFMyU4MSU5RiVFMyU4MSU5MyVFMyU4MSVBOCZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1jbGlwPWVsbGlwc2lzJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9Y2YxNzA4NWM3YmYyY2M5MGRmMTYwYjVkMDM2MDIzYzc%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwbWFzYWhhcnUtc3VpenUmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTVhMjEzNjJjMTY3M2MzN2ZiZjIzNjhkOWJjODQ3MDBj%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D4627c314d34729b978e5299cced3fa35)
江添亮、職務質問される | スラド idle
自由ソフトウェア主義者、C++ Evangelist、C++標準化委員会の委員、ドワンゴ社員である江添亮氏が、警察官に職務質問された際の顛末をブログに書いている(本の虫の記事)。 リュックを見せる、見せないともめたのち、パトカーの応援も駆けつけ、最大7人の警官に法的根拠のない自称説得行為を受けつつ、公妨だ！拳銃を触った！と言いがかりをつけられたらしい。 ちなみに職務質問をした理由は、「うつむいて、下を向いて歩いていた」、「薬物中毒者はよくうつむいて下を向いて歩くものだ。本官は薬物中毒者を多数見てきた経験論から知っている。君とは社会経験が違うのだよ」ということなので、薬物所持を疑われたらしい。 みんなも昼間から、うつむいて、下を向いて歩いていると薬物中毒者と間違われるので気を付けよう！
原理的に避けられないギターの「フレット音痴」を解消する「Microtonal Guitar」
耳のいいギタリストなら一度は感じたことがある「このギター、チューニングが決まらねぇな」という問題の原因は、多くの場合がギターが十二平均律でチューニングされていることに起因しています。特に3度(長3度)の和音を弾いた時に顕著に感じられる平均律の弊害ですが、追加のフレットを貼り付けたり、可動式のフレットを搭載するギター「Microtonal Guitar (微分音ギター)」はそんな問題を解消することが可能です。 The Major 3rd Problem of All Guitars in the World - YouTube ムービーに登場するのは、微分音ギターによる創作活動を行っているトルガン・チョウル(Tolgahan Çoğulu)さん。トルコ出身のギタリストで、このムービーでは平均律をもとに作られたギターに工夫を施してフレットによる音痴を解消する方法を紹介しています。 チョウルさん
『楽器用チューナーの謎の印』
楽器のチューニングや練習にチューナーをお使いのみなさまへ ディスプレイ上の目盛の半端な位置に妙な印の付いたクロマチック・チューナーがあります。 赤丸で囲んだ印は何でしょうね？ 「この範囲に入っていればＯＫ」の目安ですか？ いいえ、違います。 よく見ると左右でその位置が微妙に対称ではありませんね。 左の印の位置に比べ、右の印の位置は中央からちょっとだけ遠いように見えます。 話がちょっと脱線しますが、合奏をする場合の音程は中央ピッタリ(0 cent)が正しい音程とは限りません。 じつは、チューナーは多くの場合、十二平均律で表示しています。 （詳しい解説は読み飛ばして結論を急ぎたい方は マークから続きをお読みください。） ある音の高さの２倍の周波数（周波数とは１秒間の振動数）をその１オクターブ上の音と定義します。 比で言うと１：２の関係になりますね。 そして隣り合う半音程（「ド」と「ド＃」、「ド
開発者のためのSQLパフォーマンスの全て
前書き - インデックスの作成はなぜ開発者のタスクなのか インデックスの 内部構造 - インデックスは何に似ているか インデックス リーフノード - 二重連結リスト 検索 ツリー(Bツリー) - バランス木 遅いインデックス パートI - インデックスを遅くする2つの原因 where 句 - 検索のパフォーマンスを改善するためにインデックスを作成 等価 演算子 - 一致するキーの検索 プライマリキー - インデックスの使い方を確認 複合インデックス - 複数列に対するインデックス 遅いインデックス パートII - 前の問題点が再び 関数 - where句の 中での関数 大文字・小文字を区別する 検索 - UPPERと LOWER ユーザ定義 関数 - 関数インデックスの制限 インデックスの作り過ぎ - 冗長性の排除法 パラメータ化 クエリ - セキュリティとパフォーマンスのために 範囲 検
第5回 チューニングのために理解しておきたいGCの4つのアルゴリズム | gihyo.jp
なぜアルゴリズムを学ぶのか GCによる停止時間が長くなり、アプリケーションの処理時間が短くなると、業務に使える時間が短くなってしまいます。その問題を解決するために、GCをチューニングすることで、アプリケーションの停止時間を短くすることが考えられます。 その際大事なのは、GCのアルゴルズムを把握しておくことです。 GCのチューニングを行うときは、GCで行われている処理の内、どの処理に時間がかかっているかをモニタリング⇒分析⇒チューニングする、という流れになります。しかし、GCのアルゴリズムを知らないと、モニタリング結果を見てもどこに問題があるかがわからず、分析やチューニングを行うことができません。 今回は、以下の4つのアルゴリズムをご紹介します。 マーク＆スイープGC コンパクション コピーGC 世代別GC GCのアルゴリズムはJVMの実装によって異なりますが、多くの場合、上記4つのアルゴリ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
