strace コマンドの使い方をまとめてみた : sonots:blog
「もうさばき切れない」アクセスが激増したECプラットフォームにおける負荷対策 - BASEプロダクトチームブログ
はじめに CTOの川口 (id:dmnlk) です。 5月にオンラインmeetupをさせて頂きその中で「具体的な負荷対策に関しては開発ブログで！」と言っていた件ですが気づいたらもう9月になりかけていました。 コロナ禍においてネットショップ作成サービス「BASE」の利用者様が急増しました。 www.nikkei.com 5 月には 100 万ショップを超えるショップオーナー様にご利用していただいております。 今まで EC 事業を行っていなかった飲食店様や様々な業種の方が利用をはじめていただき、ショップオーナー様も購入者様共に短期の見通しでは想定をしていないアクセスが発生しました。 その途中でシステムとして対応しきれない面もあり、アクセス負荷によるサービスの不安定を招き皆様にはご不便や販売時間を変更していただくお願いなどをしてしまい大変申し訳ありませんでした。 現在では安定しておりますが、その
Index Hintの使いどき - Qiita
通知が多すぎて担当日を見逃してしまい、大遅刻。ごめんなさい！ Index Hintとは MySQLにはIndex Hint機能が実装されています。 ドキュメントから引用すると、こんな具合の構文ですが、要は使うINDEXを指定することができます。 tbl_name [[AS] alias] [index_hint_list] index_hint_list: index_hint [, index_hint] ... index_hint: USE {INDEX|KEY} [FOR {JOIN|ORDER BY|GROUP BY}] ([index_list]) | IGNORE {INDEX|KEY} [FOR {JOIN|ORDER BY|GROUP BY}] (index_list) | FORCE {INDEX|KEY} [FOR {JOIN|ORDER BY|GROUP BY}]
MYSQL効率化 - Qiita
テーブルを作る時の注意点 テーブル作る時気づいてなかったが、後でデータの量増えたらスピードに影響があるところはいくつある 1. textよりcharかvarcharの方がいい charとvarcharの長さは固定で、設定できるもので、デフォルト値も指定できるが、text長さもデフォルト値が指定できない。それでハードウェア上にcharとvarcharの方が効率が高い。charの長さは255の定数で、足りない分はMYSQLがスペースで補充する。varcharの長さはv5.0.3以降65535まで設定できて、長いカラムにおすすめ。 2.NULLを許可しないように、デフォルト値を指定 MYSQLでNULLと""は大きさが違って、NULLは実際1バイトを持つ。そして、WHEREにIS NULLなどNULLを判断する文を追加すると、インデックスをやめて全テーブルをスキャンしてしまうので、デフォルト値が
速いSQLを書くコツ！！
このページでは、SQLの実行速度を速くし、少ないメモリで実行するためのテクニックを紹介いたします。と言っても、実は『プログラマのためのSQL 第2版』の受け売りがほとんどでして、この本を読んでいただければ、ここを読む必要はありません。 また、SQLの最適化の実行前と実行後で、SQL文の解析結果を比較することが重要です。適当にSQLをいじって速くなったからそれでよし、という非科学的な態度じゃダメですよ。SQLの解析方法については、別の文章で説明します(ただしオラクルのみ。僕がオラクルしか使ったことがないので)。 なお、SQLの応答速度が遅い場合、その原因はSQL単体にあるとは限りません。索引の使用が不適切だったり、メモリの使用効率が悪かったり、ファイルI/Oが多くなっていたり、という他の原因も考えられます。 サブクエリーを引数に取る場合、IN述語よりもEXISTS述語を使え 繰り返す。サブク
UNIONを使うとWHERE a OR bより早いよ！って内容に対する調査 - Qiita
概要 WHERE a > xx OR b > xxのようなクエリはUNION使った方が早いよ！って記事があったので「本当に！？」と思って調べてみました。 準備 環境 MySQL 5.7.22 テストデータの作成 CREATE TABLE `test` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `a` int(11) NOT NULL DEFAULT 0, `b` int(11) NOT NULL DEFAULT 0, PRIMARY KEY (`id`), KEY `a` (`a`), KEY `b` (`b`) ) ENGINE=InnoDB; insert into test () values (); insert into test (id) selet 0 from test; insert into test (id) s
StackProfを使ってrubyプログラムのプロファイリングをする方法 - Qiita
計測エンジニアになろうとしたら苦労したという記事を技術ブログに書いたのですが、技術的な部分を備忘録も兼ねてまとめておきます。 Spring_MTさんのブログには大変お世話になりました。(というかREADME + このブログ記事のまとめでしかないような、、、汗) profilingとは プログラムが実行された際、どの部分のコードの実行にどれだけの時間がかかったのかを計測することです。 ではなぜ人はプロファイリングするのでしょうか？ プロファイリングはパフォーマンスのボトルネックを発見し、”遅いプログラムを速くする”手助けになります。プログラムの中で無駄に何度も呼ばれている部分、不要なのに呼びだされている部分、不自然に遅い部分を発見すれば、それを効率化することでプログラムの実行を速くすることができます。 StackProfとは Rubyプログラムのプロファイリングに関してはいくつかのツールがあ
TestProf: Ruby/Railsの遅いテストを診断するgem（翻訳）｜TechRacho by BPS株式会社
概要 元サイトの許諾を得て翻訳・公開いたします。 英語記事: TestProf: a good doctor for slow Ruby tests 公開日: 2017/08/25 gemリポジトリ: test-prof/test-prof 著者: Vladimir Dementyev サイト: Evil Martians’ team blog 2017/10/10: 初版公開 2023/07/04: 更新 テストを書くことは、開発における重要なプロセスであり、RubyやRailsのコミュニティには特に当てはまります。私たちはテストでgreenが点灯するまで長時間待たされていることに気づいて、初めてテストスイートのパフォーマンスというものに関心を寄せるようになるものです。 私はテストスイートのパフォーマンスの分析に多くの時間を費やし、テストを高速化するテクニックを編み出すとともにツールを開
なぜMySQLのサブクエリは遅いのか。
よくMySQLはサブクエリが弱いと言われるが、これは本当だろうか？半分は本当で半分は嘘である。MySQLのサブクエリだってなんでもかんでも遅いわけではない。落とし穴をしっかり避け、使いどころを間違えなければサブクエリも高速に実行できるのである。今日はMySQLがどんな風にサブクエリを実行し、どのような場合に遅いのかということについて説明しよう。 EXPLAINで実行計画を調べた際に、select_typeにはクエリの種類が表示されるのだが、代表的なサブクエリには次の3つのパターンがある。 SUBQUERY DEPENDENT SUBQUERY DERIVED 結論から言おう。遅いのは2番目、DEPENDENT SUBQUERYである。DEPENDENT SUBQUERYとはいわゆる相関サブクエリに相当するもので、サブクエリにおいて外部クエリのカラムを参照しているサブクエリのことである。そし
SQLのインデックスとそのチューニングについてのオンラインブック
開発者向けのSQLインデックス解説サイト、管理についての間違いない知識を提供します。 インデックスは開発時には忘れられがちである一方で、非常に効果的なSQLのチューニング方法です。Use The Index, Lukeでは、HibernateなどのORMツールの解説にとどまらず、SQLのインデックスについて基礎から説明します。 Use The Index, LukeはSQLパフォーマンス詳解のWeb上の無料版です。サイトを気に入って頂けたら、ぜひ書籍も購入してみて下さい。また、このサイトの運営をサポートする様々なグッズも販売しています。 MySQL、Oracle、SQL ServerなどにおけるSQLのインデックスUse The Index, Lukeでは、ベンダにとらわれないインデックスの説明を心がけています。製品特有の事柄については、以下のような表示をしています。 DB2Use The
毎回関数を作ってpropsに設定する問題の修正 · Webフロントエンド パフォーマンス改善ハンドブック
毎回関数を作ってpropsに設定する問題の修正 Reactのよくある問題として、propsに関数を渡すパターンで毎回関数を作って渡してしまうが知られています。 毎回新しい関数を作ってしまうと、同じ異なる値（props）となるため無駄にコンポーネントが更新されてしまいます。 why-did-you-updateでもこの問題を検知できます。 この問題は、関数同士の比較は常にtrueとしてしまうshouldComponentUpdateを実装するか、一度作った関数をちゃんと使いまわす（constructorで作成やpublic fieldを使う）ことで解決できます。 また、ESLintやTSLintといったLintツールでも検知できます。 tslint: jsx-no-lambda eslint: jsx-no-bind 参考 React.jsのrenderの戻り値の中で.bindで新しい関数を
React.jsのrenderの戻り値の中で.bindで新しい関数を定義してはいけないわけ - Qiita
この例の他にも、onChange={(ev) => handleChange(ev)}などのようにアロー関数を使う例もよく見るかもしれません。こちらはアロー関数式で作られた新しい関数が、呼び出し元のスコープに束縛される特性を使って、thisを束縛しています。 この書き方自体に、シンタックス上の問題があるわけではなく、またReactもエラーを出さずに動作します。では何が問題なのでしょうか。 描画パフォーマンスへのペナルティ 実はこのようにrender関数内で関数を動的に作ってしまうと、reactがコンポーネントをアップデート（再描画）するたびに、新しい関数が作られてしまいます。最初のペナルティは、この実行時における関数の定義と破棄に伴うオーバヘッドです。大きなページで大量のエレメントを同時にアップデートする際などに、無視できない影響が出ます。 もう一つの大きな影響は、Reactが再描画の判断
ISUCON8予選突破しました - あおうさ＠日記
予選突破 ISUCONというWebアプリケーションのパフォーマンス改善コンテストに参加し、予選突破しました。去年は不参加だったので2年振り2度目。(blog書くのもISUCON6振りで2年振りという... output無さすぎ) いやー実に楽しかった。やっぱりISUCONでしか味わえないモノがある。いつも何か新しい学びがある。 予選は両日共に問題なく進んだようですし、予選問題もいい問題でした。ベンチマーカーが詰まることもなく快適な予選でした。運営のみなさんありがとうございます。 久しぶりの参加だったので事前にISUCON7予選を解いてみたりconoha vpsでサーバ立ててansibleやfabric(deployに使っている)の動作確認をしたりして挑みました。ISUCON7予選を動かし始めたらあーこの感じやっぱり楽しいなと思って気持ちを高めてISUCON8に臨めて良かった。何を事前準備し
死闘の果てに ISUCON 8 予選を全体７位で突破した記録
ISUCON ８ の予選に、チーム「死闘の果てに」(najeira, bluerabbit, songmu)で参加し、全体７位で通過しました。 運営のみなさま、ありがとうございました。本戦もよろしくお願いいたします。 やったこと najeira Fabricのファイル用意 dep化 nginxに切り替え、もろもろ設定 getEventのループ内SQLクエリを外に出す getEventsのreservationsもワンクエリで取得 2台構成化(1をDB, 2をアプリ) fail対策のロック bluerabbit (bluerabbitさんによる予選記) SSH設定、Ansibleで各ツール準備 コードをgit登録 計測用コード埋め込み SQLインデックス追加 有効予約のみのreserved_sheetsテーブル songmu sheetsオンメモリ化 SQLインデックス追加 reservat
Introduction · Webフロントエンド パフォーマンス改善ハンドブック
Webフロントエンド パフォーマンス改善ハンドブック このパフォーマンス改善ハンドブックでは、ウェブアプリケーションにおけるフロントエンドのパフォーマンス改善について扱っています。 ダウンロード版 埋め込み動画を再生できないなど一部制限がありますが、ダウンロード版を配布しています。 PDF版 EPUB版 MOBI版 目的 このハンドブックでは過去に行った改善の事例を中心に紹介しています。 そのため、現在の最適な解決方法を提案するものではありません。 また、アプリケーションによっても最適な解決方法は異なります。 今回の事例ではViewライブラリにReactを使い映像再生プレイヤーなどある程度複雑な機能を持ったウェブアプリケーションのフロントを扱います。 具体的にはニコニコ生放送（以下「生放送」）で行った事例を中心に書かれています。 開発と平行して行われていたため、React 15から16の間
Webpagetestから始める継続的パフォーマンス改善
autoscale: true Webpagetestから始める継続的 パフォーマンス改善 ページロードタイム編 :hourglass: 自己紹介 Name : azu Twitter : @azu_re Website: Web scratch, JSer.info Create: textlint, Almin アジェンダ パフォーマンス改善は指標を決めて行わないと迷子になる パフォーマンス改善を行うには継続的な計測を行う 今回はページロードについて、ランタイムは範囲外 パフォーマンス改善のアプローチ 継続的なパフォーマンス計測とリグレッションの検知 ^ 目的はパフォーマンス改善には計測が必要という事実を知ること ^ パフォーマンス計測は継続的に行う必要がある ^ パフォーマンス改善は何を目的、指標にして改善するかを決めないと迷子になる ^ 目的をもって継続的にパフォーマンス改善を行い
RDS for MySQLでもPerformance Insightsで性能確認が可能になりました | DevelopersIO
なお、上記パラメータはParameter Groupの内容を上書きしないので、明示的にParameter Groupでperformance_schemaに0を設定している場合には0のまま無効となります。performance_schemaが無効の状態の場合はPerformance Insightsが待機内容を判断できず待機内容を表示できません。 やってみる 通常の状態 以下の内容でRDSを起動します。 リージョン: 東京 DBエンジン: MySQL バージョン: 5.7.22 インスタンスクラス: db.m4.large Parameter Group: デフォルト状態の内容 [詳細設定] の設定の中でパフォーマンスインサイトという項目が増えています。ここでパフォーマンスインサイトの有効化を選択します。 あとは普通のRDSを起動します。 起動後にperformance_schemaのパラ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PageSpeed Insights
GitHub - matsuu/kataribe: Access log profiler based on response time
https://developers.google.com/web/tools/setup/workspace/setup-devtools