SQLの達人への道: MySQLでの高速・効率的クエリ作成術 - Qiita
データベースとテーブルの作成 テスト用のデータベースtestdbを作成し、パフォーマンスチューニングを検証するためのcompanyおよびpersonテーブルを定義します。 CREATE DATABASE testdb; USE testdb; CREATE TABLE company ( company_id INT AUTO_INCREMENT PRIMARY KEY, company_name VARCHAR(255) NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE person ( person_id INT AUTO_INCREMENT PRIMARY KEY, company_id INT, person_name VARCHAR(255) NOT NULL, email VARCH
ソフトウェア開発の指標でFour Keysも計測できるFindy Team+の開発チームは何から改善を始めたか - Agile Journey
ソフトウェア開発チームのパフォーマンスを測る指標、それがFour Keysです。「Four Keysはすぐに上がる数字ではなく、地道で本質的な取り組みをしながら、数値を見ることで自分たちはうまくやれていることを確認するもの」と語るのは、Findyのプロダクト開発部でエンジニアリングマネージャーを務める栁沢正二郎さん。 栁沢さんが開発に携わっているFindy Team+は、エンジニア組織がパフォーマンス改善に利用できるSaaSです。GitHubのリポジトリやJiraのイシュートラッキングなどを解析して、エンジニアやチームのパフォーマンスを数値化できます。2022年8月には、Four Keysについても可視化・分析できる「DevOps分析」機能をリリースしました。 注目したい点は、Findy Team+の開発組織自身がFindy Team+をドッグフーディングしていること。つまり、Four K
Cloudflare、NGINXに代えて自社開発のRust製HTTPプロキシ「Pingora」をグローバルCDNに採用。性能向上しつつCPUとメモリ消費を3分の1に
Cloudflare、NGINXに代えて自社開発のRust製HTTPプロキシ「Pingora」をグローバルCDNに採用。性能向上しつつCPUとメモリ消費を3分の1に CDNプロバイダのCloudflareは、同社のグローバルなCDNの基盤として長らく利用してきたNGINXに代えて、同社自身がRust製のHTTPプロキシである「Pingora」を開発し利用していることを明らかにしました。 Pingoraはすでに同社のCDNに採用され、毎日1兆回以上のリクエストを処理し、性能向上や数多くの新機能の提供を実現しつつ、従来と比較してCPUとメモリリソースの消費はいずれも3分の1程度に収まっているとのこと。 Pingoraは現時点でコードなどは公開されていませんが、いずれオープンソース化の計画についても明らかにするとCloudflareは説明しています。 Today we are excited t
「もうさばき切れない」アクセスが激増したECプラットフォームにおける負荷対策 - BASEプロダクトチームブログ
はじめに CTOの川口 (id:dmnlk) です。 5月にオンラインmeetupをさせて頂きその中で「具体的な負荷対策に関しては開発ブログで！」と言っていた件ですが気づいたらもう9月になりかけていました。 コロナ禍においてネットショップ作成サービス「BASE」の利用者様が急増しました。 www.nikkei.com 5 月には 100 万ショップを超えるショップオーナー様にご利用していただいております。 今まで EC 事業を行っていなかった飲食店様や様々な業種の方が利用をはじめていただき、ショップオーナー様も購入者様共に短期の見通しでは想定をしていないアクセスが発生しました。 その途中でシステムとして対応しきれない面もあり、アクセス負荷によるサービスの不安定を招き皆様にはご不便や販売時間を変更していただくお願いなどをしてしまい大変申し訳ありませんでした。 現在では安定しておりますが、その
CPU律速なRuby/Pythonコードはデフォルト設定のdocker上で遅くなる - まめめも
English version 要約 dockerはデフォルトでセキュリティ機構（Spectre脆弱性の対策）を有効にします。この影響で、RubyやPythonのようなインタプリタは速度が劣化します。特にCPU律速なプログラムで顕著に遅くなります（実行時間が倍くらいになることがあります）。 現象 Rubyで1億回ループするコードを、直接ホスト上で実行する場合と、docker上で実行する場合で実行時間を比較してみます。 直接ホスト上で実行した場合： $ ruby -ve 't = Time.now; i=0;while i<100_000_000;i+=1;end; puts "#{ Time.now - t } sec"' ruby 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x86_64-linux] 1.321703922 sec docker
継続的にベンチマークを取るための GitHub Action をつくった - はやくプログラムになりたい
今年9月に GitHub Action v2 がリリースされました．GitHub Action は GitHub が提供する CI/CD サービスです． 既存のサービスと大きく違う点は，処理を汎用的に Action として切り出して再利用できることです． 例えば，GitHub からのリポジトリのクローン actions/fetch や Node.js のセットアップ actions/setup-node などの基本的な実行ステップも Action として実装されています． 今回はこの GitHub Action を利用して，前々からあると良いなと思っていたベンチマークを継続的に取るための Action をつくりました． github.com github-action-benchmark はベンチマークの実行の出力からベンチマーク結果を抽出し，GitHub pages のブランチに JSO
稼働中のサービスで安全にdrop tableする方法 - Qiita
DBサーバーのディスク容量の空きが少なくなり、不要なテーブルを削除することになりました。 対象のテーブルのデータ量が多く、平常時でもそこそこ負荷のあるサーバーなのですが、 テーブル削除だけのためにメンテナンスをするのもアレなので、 深夜帯にしれっとdropしたい気持ちを抑えつつ、負荷のかからないdrop tableの手順を試してみました。 サービス稼働中にテーブルdropする時の問題点 metadata lock drop対象のテーブルに書き込みやトランザクションが貼ってあるとmeta data lockがかかってしまいます 今回は参照等がないテーブルなので、問題なし 巨大なファイルを削除するとI/O待ちが発生する 巨大なテーブルのデータファイルを削除すると他のプロセスがI/O待ちになる可能性があります 安全にテーブルdropするには 完全にこちらを参考をさせて頂きました。 負荷の高いMy
巨大企業のサーバー構成や内部ツールを覗く - 発明のための再発明
はじめに この記事は設計・アーキテクチャ Advent Calendar 2018の１日目の記事です。 大きなサービスを支えるのは一筋縄では行かず、考えることは多くあります。しかし、ありがたいことに巨大な企業の中にも自社のサーバー構成やそれを支えるツールを公開している企業があります。 この記事では、彼らの叡智に触れるため、有名企業の事例を取り上げ要約をします。 各事例には元記事へのリンクを書いているので、興味があればリンク先も覗いてみてください。 ※新しいものばかりではないので、古くなっていたり既に別の方法に移行している可能性があることに注意してください。 LINE: 25k/secのスパイクをさばくアーキテクチャ 元記事: 25K request/secをさばいた「LINEのお年玉」のアーキテクチャの裏側 最初に紹介するのは、LINEが2018年に実施した、「LINEのお年玉」というイベ
MySQLのクエリの良し悪しはrows_examinedで判断する - かみぽわーる
仕事やらなんやらでMySQLのクエリの良し悪しを判断する必要があるとき、EXPLAINの内容だけだとどのぐらい良くなったり悪くなったのか分からないので SET long_query_time = 0; してrows_examined (そのクエリでrows_sent行の結果を返すために何行に触ったのか)も一緒に提示するようにしている(少なくともMySQL 5.7時点ではrows_examinedはslow_query_logでしか確認できないはずperformance_schemaが有効ならevents_statements_historyやその仲間たちで確認できるとのこと*1 MySQL :: MySQL 5.6 リファレンスマニュアル :: 22.9.6 パフォーマンススキーマステートメントイベントテーブル)。 例: 上の例のBeforeは、もともとDBAが書いた温かみのあるSQLでO
日経電子版を速くする / nikkei-inside-frontend - Speaker Deck
Inside Frontend #2 の発表資料です https://inside-frontend.com
はてなブログを自分で出来る範疇で高速化してみる - Webパフォーマンスについて
はてなブログの高速化について、はてなスターを外すと速くなるとか、色々話題になっています。 ユーザが手を入れられる範囲でどこまで高速化できるか、いつも私がやっている統計的品質管理のアプローチで、計測・分析・改善してみました。 デスクトップサイト計測 まずは、現状把握、Synthetic Monitoringです。 Synthetic Monitoringとは、実験計画法のフィッシャー三原則に則った、対象ページに介在して計測する手法です。 一ユーザとして、こちら側から、一定間隔で、対象ページにアクセスをして、表示速度に関するデータを取得します。 計測対象サイト takehora.hatenadiary.jp トップに乗っていた記事は、5.3MBあって、かなり重いです。 グラフ関係の画像を多用しているからですね。 計測条件 日本の帯域保証型(100Mbps)光回線 … NTTとKDDI 計測ブラ
MySQLパフォーマンスチューニング -my.cnfの見直し- - Qiita
※RDSは使っていません。 負荷を見てみる DBサーバーの負荷状況を見てみます。 当時の監視ツールの画像がないのですが、以下の状況でした。 LA(Load Average)が突き抜けている リクエスト数は「常識的に考えて」それほどでもない メモリの使用量にあまり変化がない swapはしていない ストレージ容量を結構食っている WEBサーバーから見れば、処理待ちのままプロセスが処理されていない典型的なパターンだったと思います。 DBサーバーとしては、LAに対し、メモリの使用量があっていないように思われました。 仮説 上記の状態から、仮説を立てます。 スロークエリ が頻発しているのではないか メモリ が正しく割り当てられていないのではないか 各種ログ の設定が適切ではないのではないか 仮説を検証することで、対策をしていきます。 設定を見直す 上記の仮説の設定は、MySQLの設定ファイルである「
Ruby on Railsで作ったWebサービスを5倍速くしてメモリを半分以下にした話 - Qiita
改善前に比べ約5倍表示速度が速くなりました。また、1秒間にさばけるリクエスト数も約3倍ほどになっています。Unicornの1プロセスあたりが使用しているメモリもだいぶ低くなりました。 なお、ページ読み込み速度は、ブラウザでページを表示したときにインジケータのクルクルが止まったときです。Chromeの開発ツールのネットワークタブで赤い文字で Load 1.2sec とか表示されているやつです。GoogleAnalyticsのページ速度でいうと plt というキーでレポートされているものです（参考ページ）。 グラフとか GoogleAnalyticsのグラフです。読み込み時間が下がっています。 メモリ使用量です。Zabbixからmackerelに乗り換えたのでグラフが違いますが、使用量が下がって安定しているのがわかります。 AWS ELBのレイテンシです。不安定なレスポンスが安定してるのがわか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Goで実装された高速な
仮想待合室サーバの実装と詳解
Webパフォーマンス高速化とこれからのアーキテクチャ
なぜエンジニアはパフォーマンスを計測しないのか
Webpackのビルド時間を1/3にした話 #gotandajs
mysql_first_performance_ tuning_y8
GitHub - phpbench/phpbench: PHP Benchmarking framework
Webアプリケーションのキャッシュ戦略とそのパターン / Pattern and Strategy of Web Application Caching
