Ultimate Guide to Improving MySQL Query Performance
MySQL is certainly a powerful open source database management system, but even the most robust engine struggles when queries take an eternity to execute. For DBAs and developers, improving MySQL query performance is an ongoing goal. Efficient query performance is crucial for ensuring the smooth operation and optimal user experience of applications powered by MySQL databases. When businesses rely h
The Hidden Performance Cost of NodeJS and GraphQL
NodeJS and GraphQL are popular technologies for building web applications, but in my experience, they come with certain scaling and performance tradeoffs to be aware of. tl;dr: GraphQL's modular structure generally leads to code that instantiates excessive promises, which degrades request performance. Benchmarks show a 2-3x latency increase. Thanks for reading Software at Scale! Subscribe for free
Pagination with Relative Cursors
Omitted from the table are tests with the 1,000,000th offset and above since they consistently timed out. Not only do queries take a long time when a large offset is used, but there’s also a limited number of queries that can be run concurrently. If too many requests with large page numbers are made at the same time, they can pile up faster than they can be executed. This leads to unrelated, quick
AWS RDSで大量のデータを削除する時等に、性能劣化を避けるために確認すべき項目(クレジット残高)
RDS で、大量のIO を伴う処理を行うと、処理途中で性能が大きく劣化することがあります。 不要になった大量の過去データをバッチで削除する時によく発生します。 これは、ストレージへの IO を規定量より高い頻度で行った時に減少するクレジットがあり、それが 0 になった時、パフォーマンスに制限がかかってしまうためです。 制限のかかった状態では通常通りのサービス運用はできなくなってしまうため、過去データ削除などの高負荷のバッチは、RDSのモニタリングページを見ながら注意深く実施する必要があります。 今回は、パフォーマンス低下を避けるために確認すべき RDS クレジットのメトリクスについて書きます。 各メトリクスの詳細は、AWS の公式ドキュメントに詳細な解説があります。 高負荷な処理を行う際に確認すべきメトリクス EBS Byte Balance AWS のドキュメントによると、「RDS デー
準同期レプリケーションで、でかいテーブルをDROP TABLEした時の死にポイント on 5.7.34
準同期レプリケーションで、でかいテーブルをDROP TABLEした時の死にポイント on 5.7.34 TL;DR dict_sys のmutexを取るのでDDL系は死ぬし新しくテーブルキャッシュを作れないのでテーブルキャッシュが枯渇すると死ぬ ROLLBACK も dict_sys のmutexを取るので死ぬ。 COMMIT はできる。 実はGroup Replicationまたは準同期レプリケーションを使っていると、更新系DMLの中に dict_sys を使う処理が追加されるのでこっちはいきなりDMLが刺さる。 試したのは5.7.34だけ。他のバージョンの動作は知らない。この動作は単純にunlink中のmutexの話なので、バッファプールの大小にはよらない。【2022/08/01 11:21】この実験は単純にunlinkを遅延させて測っているだけなので、バッファプールの大小はまた別の問
Bulk insertでも20時間以上かかっていたMySQLへのインサート処理を1時間以内にする - エムスリーテックブログ
この記事はエムスリー Advent Calendar 2022の30日目の記事です。 前日は id:kijuky による チームメンバーのGoogleカレンダーの休暇予定一覧をスプレッドシート+GASで作った でした。 AI・機械学習チームの北川(@kitagry)です。 今回はMySQLへのインサートを20倍以上高速化した話について書きます。 仕事をちゃんとしてるか見張る猫 TL; DR はじめに 今回のテーブル バイナリログを無効化する 追試 LOAD DATA INFILE 追試 テーブルの正規化 インデックスを一時的に剥がす まとめ We are hiring!! TL; DR バイナリログをオフにする LOAD DATA INFILEを使う インデックスを一時的に消す はじめに AI・機械学習チームではサイトトップからアプリに至るまで多くの推薦システムがあります。 そこでは推薦ロ
第17回 Webアプリケーションのパフォーマンス改善（1） | gihyo.jp
大きな効果を上げるために チューニンガソン#1～#3の改善率を見ると、アプリケーションや全体のアーキテクチャに手を入れないで改善できるのは最大でも10倍以下です。もちろん数倍速度が違えばサーバ台数を大きく減らせるので有意義なのは間違いないのですが、ISUCONやチューニンガソン#4のような飛躍的な高速化は望めないことがわかります。 つまりチューニングでは、単にパラメータ設定を変更するのみではなく、ボトルネックになっているコードやクエリ、アーキテクチャに的確に手を入れていくことで大きな効果を上げることができるのです。 ボトルネックの発見と解消が大事 システム全体の処理時間についてパレートの法則（経験則）を適用すると、「全体の処理時間の80％は20％の部分で発生している」ということになります。実際にシステム全体で一番ボトルネックになっている部分を解消しないことには、ほかの部分に手を入れても大
1KBのWebフレームワークをつくる - ゆーすけべー日記
1KBのWebフレームワークをつくりました。 名前は「Pico」。 minifyしてビルドした模様。 コードはこれだけ。依存なし。ほんとにこれだけです。 Cloudflare WorkersとDenoで動きます。 今回はこのPicoというフレームワーク、 それに必要不可欠なURLPattern、実装について、 そして僕がつくっているもう一つのフレームワークHonoとの関係などを紹介します。 Hello World text/plainでレスポンスを返す、“Hello World"相当のコードは4行で書けます。 import { Pico } from "@picojs/pico"; const app = new Pico(); app.get("/", (c) => c.text("Hello Pico!")); export default app;
1ヶ月で負荷テストの基礎から学んで実際にやってみた知見 | BLOG - DeNA Engineering
はじめに こんにちは。DeSCヘルスケアシステム部でインターンをしている中島です。本記事では開発に関わった2つのサービス「ハレトケ」「カラダモ」の負荷テストで得た知見について紹介したいと思います。 負荷テストをこれからやる方や、システムのパフォーマンスチューニングに興味のある方などの参考になると嬉しいです。 負荷テストの目的 まず、負荷テストをどのような目的でやるのかについて抑えておきます。一般的にクラウド環境での負荷テストの目的は以下の5つが挙げられます。（出典：Amazon Web Services負荷試験入門 ――クラウドの性能の引き出し方がわかる Software Design plusシリーズ） 各種ユースケースの応答性能を推測する 高負荷時の性能改善を行う 目的の性能を提供することができるハードウェアをあらかじめ選定する システムがスケール性を持つことを確認する システムのスケ
We’re using TTVC to measure performance on the web—and now you can too
We’re using TTVC to measure performance on the web—and now you can too Nobody likes waiting for software. Snappy, responsive interfaces make us happy, and research shows there’s a relationship between responsiveness and attention1. But maintaining fast-feeling websites often requires tradeoffs. This might mean diverting resources from the development of new features, paying off technical debt, or
詳解: Amazon Elastic Container Service と AWS Fargate のタスク起動レートの向上 | Amazon Web Services
Amazon Web Services ブログ 詳解: Amazon Elastic Container Service と AWS Fargate のタスク起動レートの向上 この記事は Under the hood: Amazon Elastic Container Service and AWS Fargate increase task launch rates を翻訳したものです。 2015 年以降、数十万人の開発者がクラスター管理のオーケストレーションサービスとして Amazon Elastic Container Service (Amazon ECS) を選択しています。開発者はミッションクリティカルなアプリケーションのライフサイクルを、最初のデプロイから新バージョンのコードのロールアウト、トラフィックレベルの変化に対応した自動スケーリングまで Amazon ECS に託して
メルペイフロントエンドパフォーマンス改善報告 | メルカリエンジニアリング
はじめに こんにちは。メルペイフロントエンドチームのtoshickです。 この記事は、このチームで取り組んでいるパフォーマンス改善について紹介するシリーズ記事の第4弾の記事になります。 ref: https://engineering.mercari.com/blog/entry/20220118-e040ab3dd3/ 昨年末から改善調査を行ってきたパフォーマンス改善の活動報告をしていきます。 メルペイチームで開発・運営している社内ツール（以下社内ツール）に対して、WebVitalsの指標の一つであるTBTにフォーカスした改善を行ってきました。 スコア計測のエンジンとしてはlighthouse-ci（以下lhci）を利用しています。 実際のところ「このようにしたらこれだけ改善しました！」という報告とは多少違いますが新 たな学びがありました。 TBTとは トータルブロッキングタイム。Web
第2回 トランザクションを知ればデータベースがわかる―「データ復旧」「同時実行制御」を行う“不完全な”しくみ（3） | gihyo.jp
ロックのコスト：スラッシングとデッドロック スラッシング DBMSがロックを行うとき、具体的にはロックの取得と解放という2つの動作をしています。そして、ロックが取得されている資源にほかのトランザクションがアクセスをかけてきたら、共有ロック同士でない限り「ブロック」を行います。あとから来たトランザクションをロック解放まで待たせるわけです。よく駅や空港のトイレで行列ができるのを見かけますが、あれなどまさにブロックされたトランザクション群の典型です[5]。トイレの便座を共有ロックで、というわけにはいきませんね。 このしくみから必然的に導かれる結果は、並行トランザクション数が一定数を超えると、1つのトランザクションが待機させられる頻度と時間が増え、平均のパフォーマンスが悪くなるということです。システムの特性（更新が多いのか、検索が多いのか）やハードウェア性能にも左右されるため、一般的な閾値（いき
リトルの法則とキャパシティプランニング - ゆううきメモ
(引用: Systems Performance figure 2.18 Queueing Model) リトルの法則とは、安定した系において、平均待ち行列数は、平均到着率と平均待ち時間の積に等しい、という法則である。 (Systems Performanceの原文ではaverage service timeになっていたが、正確にはaverage wait time) 例えば、平均到着率はスループット、平均待ち時間はレイテンシ、平均待ち行列数は、同時処理リクエスト数と捉えることができる。 計算機システムの場合、安定してサービスするためには、同時処理リクエスト数がシステムの上限を超えないことが重要。 同時処理リクエスト数の限界は、例えば単一のprefork型ウェブサーバだと、計算機資源が十分あると仮定すると、ワーカープロセス数で決まることが多い。 しかし、マルチスレッド型やイベント駆動型の場
Google製GNU gold以上の速さを実現 超高速リンカ「mold」を支えるテクニック
Kernel/VM探検隊はカーネルや仮想マシンなどを代表とした、低レイヤーな話題でワイワイ盛り上がるマニアックな勉強会です。rui314氏は、制作中のリンカである「mold」について発表しました。全2回。後半は「mold」速さと、その高速化を実現するテクニックについて話しました。前半はこちら。 リンカが速いと何がうれしいのか 植山類氏（以下、植山）：リンカが速くなって何がうれしいのか。普通にうれしいです。プログラムを書いているとうれしいことがわかると思いますが、makeを実行すると、普通は自分が直前に変更したファイルしかビルドしないので、デバッグをしていると1つのファイルを編集してビルドすることになります。 コンパイラは1つだけのファイルをコンパイルするのはそこそこ速いですが、リンカは基本的には実行ファイルを丸ごと作ります。全体の入力を一気に受け取って出力するため、差分コンパイルであっても
毎秒1万リクエストの負荷試験をした話 - pixiv inside
はじめまして。ピクシブで広告関連のプロダクトを開発しているeastです。今回は、社内で運用している広告配信サーバーの負荷テストを実施したので、その話をしたいと思います。 経緯 ピクシブの広告配信サーバーは、pixiv本体を中心に複数のサービスに対して広告配信を行なっています。現在私はこの広告配信サーバーの大規模改修を行なっているのですが、先日ついに広告配信サーバーの改修がほぼ完了したので、試しに負荷試験を行なってみたいと思い立ちました。 目標は毎秒1万リクエスト ピクシブの広告配信サーバーへのリクエスト数はDailyで 4〜6億req もあり、これは毎秒平均に直すと約 5,000RPS(Request Per Second) になります。さらに、ピークタイムである休日の深夜帯には 12,000RPS にも達します。つまり新しい広告配信サーバーにも、毎秒12,000のリクエストを捌く性能が必
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Using Little’s Law to scale applications
バンドル最適化マニアクス at tfconf
Concurrent smart contracts in Hyperledger Fabric blockchain (part 1)
Performance Testing vs. Scalability Testing - LoadView