MySQLパフォーマンスチューニング -my.cnfの見直し- - Qiita
※RDSは使っていません。 負荷を見てみる DBサーバーの負荷状況を見てみます。 当時の監視ツールの画像がないのですが、以下の状況でした。 LA(Load Average)が突き抜けている リクエスト数は「常識的に考えて」それほどでもない メモリの使用量にあまり変化がない swapはしていない ストレージ容量を結構食っている WEBサーバーから見れば、処理待ちのままプロセスが処理されていない典型的なパターンだったと思います。 DBサーバーとしては、LAに対し、メモリの使用量があっていないように思われました。 仮説 上記の状態から、仮説を立てます。 スロークエリ が頻発しているのではないか メモリ が正しく割り当てられていないのではないか 各種ログ の設定が適切ではないのではないか 仮説を検証することで、対策をしていきます。 設定を見直す 上記の仮説の設定は、MySQLの設定ファイルである「
なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策｜ハイクラス転職・求人情報サイト AMBI（アンビ）
なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 『SQLパフォーマンス詳解』の翻訳者の松浦隼人さんに、8つの「SQLが重たくなる原因とその対策」を聞きました。システムのボトルネックになるような「問題のあるSQL」を回避するノウハウを学びましょう。 データの操作や定義をする言語「SQL」は、どのような領域を担うエンジニアにとっても必修科目です。しかし、その仕様をきちんと理解し、パフォーマンスに優れたSQLを書ける方はそれほど多くありません。問題のあるSQLを書いてしまい、知らぬ間にそれがシステムのボトルネックになってしまう事態はよく発生します。 では、どうすればそうした事態を回避できるのでしょうか？ そのノウハウを学ぶため、今回は『SQLパフォーマンス詳解』の翻訳者であり、自身もエンジニアでもある松浦隼人（まつうら・はやと／@dblmkt）さんに8つ
nginxパフォーマンスチューニング〜静的コンテンツ配信編〜 - Qiita
今回はHTMLやCSS、Javascriptといった比較的軽量な静的コンテンツの配信をnginxでやるケースに絞ってチューニングする際のポイントについて紹介しようかと思います。 (注：worker_rlimit_nofileやsysctl.confのネットワーク周りの設定のような定石的なチューニングについてはあえて解説しないのであらかじめご了承ください。) コンテンツをgzip圧縮する 何はともあれgzip圧縮です。ネットワーク帯域に比べればCPUリソースなんて安いものです。 しかし、多くの場合これだけでは十分ではありません。何故ならnginxはデフォルトではContent-Typeがtext/htmlのコンテンツしか圧縮しないためです。圧縮対象のContent-Typeを増やすにはgzip_typesを使います。 単純なWebサイトであれば上記の設定で十分ですが、場合によってはappli
本当にあったRailsの怖い話
meguro.rb#9で発表した資料です 「心霊現象」という文字が映らない心霊現象が発生しております。
レンダリング ツリーの構築、レイアウト、ペイント | Articles | web.dev
レンダリング ツリーの構築、レイアウト、ペイント コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 CSSOM ツリーと DOM ツリーを組み合わせてレンダリング ツリーを作成し、表示可能な各要素のレイアウトを計算し、画面にピクセルをレンダリングするペイント プロセスへの入力として使用します。これらの各ステップを最適化することは、最適なレンダリング パフォーマンスを実現するうえで重要です。 オブジェクト モデルの構築に関する前のセクションでは、HTML と CSS の入力に基づいて DOM ツリーと CSSOM ツリーを構築しました。ただし、どちらもドキュメントのさまざまな側面をキャプチャする独立したオブジェクトです。1 つはコンテンツを記述し、もう 1 つはドキュメントに適用する必要があるスタイルルールを記述します。この 2 つを統合して、ブラウザが画面上
Making dev.to insanely fast
It makes me smile when someone raves about how fast this website loads, because that's no accident. We put a lot of effort into making it so. It is the sort of thing that usually goes unnoticed, but when your readers are developers, there's a better chance they notice and appreciate it. I have written about this in the past, but it's worth re-examining because these ideas are always evolving. From
ISUCON 夏期講習 2017 を開催しました（当日の資料あり） : ISUCON公式Blog
学生限定イベント「ISUCON 夏期講習 2017」を開催いたしましたのでスライドなど共有します。 当日は、優勝・優勝・出題・３位・優勝・準優勝というISUCON戦歴をもつ最強講師、面白法人カヤックのfujiwaraさんお越しいただきました。 ISUCON夏期講習お待たせしました。最強講師 fujiwara組長にお越しいただけることとなりました！学生の皆さま、これはチャンスです！是非ご参加くださいませ(締め切りが早いのでご注意ください) #isucon https://t.co/xEcThfqoc5 — ISUCON公式 (@isucon_official) 2017年7月27日 ISUCON = Iikanjini Speed Up CONtest だと知って驚く方が毎年一定数いらっしゃいます。 当日は講義編と実践編の二部構成で「わかる！ISUCON！」と言い切りたいレベルで大変よくわか
RAIL モデルでパフォーマンスを測定する | Articles | web.dev
目標とガイドライン RAIL においては、「目標」と「ガイドライン」という用語には次のような特定の意味があります。 目標。ユーザー エクスペリエンスに関連する主要なパフォーマンス指標。たとえば、タップして 100 ミリ秒未満でペイントします。人間の認識は比較的一定であるため、これらの目標が近いうちに変更される可能性は低くなります。 ガイドライン。目標の達成に役立つ推奨事項。現在のハードウェアやネットワーク接続の状態に固有のものであるため、今後変更される可能性があります。 レスポンス: 50 ミリ秒未満でイベントを処理 目標: ユーザー入力によって開始される遷移を 100 ミリ秒以内に完了し、ユーザーが操作が瞬時にあると感じられるようにします。 ガイドライン: レスポンスが 100 ミリ秒以内に表示されるようにするには、ユーザー入力イベントを 50 ミリ秒以内に処理します。これは、ボタンのク
Webのパフォーマンスモデル「RAIL」とは何か？ - ふろしき Blog
ここ数年のうちに、人々が利用するメインコンピューターは、デスクトップからモバイルへと移りました。 少ないハードウェアリソース、不安定なネットワーク、逼迫するバッテリー消費、シンプルなユーザインタフェース、開発者はこうした制約の中で、Webサイトを制作することが求めらるようになりました。Webのパフォーマンスに関する考え方も大きく変化があったのですが、我々は具体的に何を基準にし、どの程度にチューンすれば良いのでしょう？その答えが、パフォーマンスモデル「RAIL」にあります。 RAILは、開発者向けカンファレンス「Google I/O 2015」にて発表されました。厳密にはI/Oが初というわけではありませんが、実に2桁近いセッションでこのキーワードが紹介されています。今後は一般的になっていくのでしょう。 モバイル時代のWebのパフォーマンスモデル 一見するとRubyと関係しそうですが、全くコン
GitHub - kainosnoema/rack-lineprof: Rack middleware for easy line-by-line profiling using rblineprof
ISUCON5予選を全体1位で通過しました - 酒日記 はてな支店
ISUCON5 の予選1日目にチーム「fujiwara組」(@fujiwara, @songmu, @sugyan) として参加して、全体通して1位のスコアで通過しました。 isucon.net 今回は ISUCON 1 の時の優勝チームを再結成という形になったわけですが、最初はISUCON 4の時と同じ社内のチームででようかと思ってたんですよね。ところが昨年優勝チームだった「LINE選抜 生ハム原木」が今回参戦できないということで、sugyanがチームどうしよう、と困っていたのでつい…*1 初代fujiwara組を再結成しよう— fujiwara (@fujiwara) 2015, 5月 27 準備 今回はOSは Ubuntu(バージョン非公開)なのが事前にレギュレーションで公開されていたので(前年まではCentOS, Amazon LinuxなどのRedHat系ディストリビューションで
G-WANはなぜ速いのか？をnginxと比べながら検証してみた - blog.nomadscafe.jp
ツチノコブログのWEBサーバベンチマークツール比較の記事で紹介されていた。WebサーバのG-WAN。この記事によると凄く速いようです。 Intel Xeon E5-2640 (6コア/12スレッド 2.50GHz) を2つというサーバで gwan 334944 req/s nginx 111842 req/s と、速いと言われているnginxの3倍の速度を出しています。 このベンチマーク結果がとても気になったので、なぜG-WANが速いのか、自分でも検証してみました。 結論から言うと以下の2つ。 1) G-WANはデフォルトで物理CPUに合わせた数のスレッドを起動する 2) HTMLファイルも一度読み込んでキャッシュする という事です。 今回はAWSのcc2.8xlarge(E5-2670 8コア/16スレッド 2.60GHz *2)を使ってベンチマークを行いました。OSはAmazon L
Railsアプリを66％スピードアップ ― Railsキャッシュの完全ガイド | POSTD
(訳注：2016/3/2、頂いた翻訳フィードバックをもとに記事を修正いたしました。) Railsアプリでのキャッシングは、「たまに夕食を一緒にするけれど、本当はもっと頻繁に一緒にいるべき友達」に少し似ています。パフォーマンスをまじめに考えるRailsアプリのほぼ全てで、もっとキャッシングを使えるはずですが、ほとんどのRailsアプリでは、完全にキャッシングを避けています。それでも普通は、Railsで高速なサーバ応答を達成するための唯一の道は、キャッシングの知的な利用なのです。約250msの応答時間を、簡単に50～100msに高速化できます。 定義についての注意 ― この記事は、アプリケーション層のキャッシングのみを対象としています。HTTPキャッシング（これは全く別の難物で、あなたのアプリケーションに実装する必要はありません）は、別の機会で扱いましょう。 するべきキャッシングをしない理由
Droidcon Italy 2015でアプリのパフォーマンスの話をしました - クックパッド開発者ブログ
海外向けのAndroidアプリを開発している @rejasupotaro です。 4/12、13にDroidcon ItalyというAndroidのカンファレンスがありました。 Droidcon Italy 2015 私はそのカンファレンスでパフォーマンスの話をしてきました。この記事の前半では、カンファレンスで発表したパフォーマンスの話を、後半に海外のカンファレンスに参加してみてどうだったかということを書きます。 パフォーマンスの話 以下のような3部構成で話をしました。 HTTPと通信を行う環境 画像の読み込みと最適化 UXを高めるAPI設計 以降の記事はスライドの補足が主になりますので、スライドを一読したあとに読み進めていただくとより実りがあると思います。 HTTP通信を見直す 通信の中身を見る まず、通信を見ることができるようにします。以前は mitmproxy や Charles な
Responsibly Use Peek to Inspect Rails
I love developing applications with the peek gem. It's designed for development or staging environments; there are a few tricks if you don't want it on production or test environments. This gem puts a little bar on your pages which gives you all sorts of helpful information about the request you just made. As you can see there is information about the branch you're on, performance metrics, databas
ISUCON4 予選でアプリケーションを変更せずに予選通過ラインを突破するの術 - Hateburo: kazeburo hatenablog
AMIが公開されたのでもう一度やってみた。 AMIについてはこちらのエントリに書かれています ISUCON4 予選問題の解説と講評 ＆ AMIの公開 : ISUCON公式Blog まず ami-e3577fe2 を m3.xlargeで起動します。 CPUは model name : Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz でした。 とりあえず、MySQLのindexを追加する。init.shに追加 $ cat init.sh cat <<'EOF' | mysql -h ${myhost} -P ${myport} -u ${myuser} ${mydb} alter table login_log add index ip (ip), add index user_id (user_id); EOF ベンチマークツールのhttp keepal
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ISUCON夏期講習2017 実践編 / isucon summer school 2
サービス終了のお知らせ
ウェブパフォーマンスの基礎とこれから
Ruby on Rails on MySQL チューニング入門
