Railsスケーリング（3）: GVL競合を計測してプロセスごとの理想的なスレッド数を決定する（翻訳）｜TechRacho by BPS株式会社
スレッド数を4よりも増やすと、改善率が5%を下回ることがわかります。 つまり、max_threadsに指定する値は4が適切であるということです。この値をRAILS_MAX_THREADS環境変数に設定するとよいでしょう。 この表を見ると、5つ目のスレッドを追加してもパフォーマンスは3%しか改善されません。ここから、これ以上スレッドを追加しても、それに伴ってメモリ使用量やGVL競合が増加する可能性に見合わないと考えられます。 なお、I/Oパーセンテージを入力すると、グラフ表示とともに最適なスレッド数を把握できる小さなアプリケーションも作成しました↓。 参考: Amdahl's Law Thread Calculator 🔗 スレッド数をストール時間で検証する アムダールの法則のおかげで4という値を理論的に導き出せました。 今度はこの法則を検証してみましょう。4という値が実際に適切かどうかを
Ruby × jemallocのすすめ - メドピア開発者ブログ
集合知プラットフォーム事業部・エンジニアの榎本です。コロナ禍の運動不足を解消すべく筋肉体操で筋トレを続けてますが、上腕三頭筋がいい感じに成長しており継続の大切さを身に沁みて実感しております。 目次 TL;DR（三行要約） Rubyアプリケーションのメモリ肥大化問題 jemalloc を使ってみる jemalloc とは？ jemalloc で改善するのか？ jemalloc の設定方法 jemalloc をプロダクション導入してみた結果 まとめ おまけ：jemalloc についてMatzに聞いてみた TL;DR（三行要約） jemalloc でRubyアプリのメモリ効率改善 jemalloc でRubyアプリのパフォーマンス改善 jemalloc の導入も簡単 Rubyアプリケーションのメモリ肥大化問題 Ruby on RailsなどのRubyアプリケーションを運用する上で、メモリ使用量の
Speedshop - the Ruby on Rails performance company
Speedshop is a Ruby on Rails performance consultancy that optimizes the full stack - frontend, backend and environment - to generate revenue and cut scaling costs for businesses on Rails through tools, information and training. Fast sites are profitable sites. Speed is a feature. New: 日本に支社があります. Products and Services The Rails Performance Workshop. A four-week program that makes your Rails app fa
Rails APIサーバーで Ruby 3.2 の YJIT を有効化してみた。 - メドピア開発者ブログ
サーバーサイドエンジニアの内藤(@naitoh) です。 Rails で構築された小規模な APIサーバー(Rails の API モードで構築したもの)で、Ruby 3.2 の YJITを有効化する事で性能アップすることができましたので、喜びを分かち合いたく共有させて頂きます。 shopify.engineering We’re able to measure real speedups ranging from 5% to 10% (depending on time of day) on our total end-to-end request completion time measurements. YJIT を開発した Shopify では 5%から10%の処理速度の改善があったという事で、以前から弊社でも本番で運用を開始したかったのですが、比較的検証のし易い APIサーバーで
負荷試験ツールのk6が良さそう - rochefort's blog
またもやisucon本から。 前回はこちら（アクセスログの集計ツールのalpが良い ）。 達人が教えるWebパフォーマンスチューニング 〜ISUCONから学ぶ高速化の実践 作者:藤原 俊一郎,馬場 俊彰,中西 建登,長野 雅広,金子 達哉,草野 翔技術評論社Amazon 本題 負荷テストツールとしては、Apache JMeter、Apache Bench（ab）辺りをよく使っていましたが、 isucon本で紹介されているk6の感触が良かったので、ご紹介です。 installationはmacだとbrewでサクッと入るので省略。 使い方 シナリオをjsで書いて、コマンドで実行するだけです。 本書で紹介されていたab的な使い方だと、以下のような感じです。 import http from "k6/http"; const BASE_URL = "http://localhost"; expor
500点出す！ - ゆーすけべー日記
「Web Speed Hackathon 2022」という「非常に重たいWebアプリをチューニングして、いかに高速にするかを競う競技」があります。 リモート参加で11月1日から27日まで開催されています。 ここで言う「高速」とはCore Web Vitalsのスコアが高いことを言い、Lighthouseのスコアをベースにした500点満点の争いです。 ISUCONのフロントエンド版ですね。 以前にも同じ課題で「学生向け」と「社内（サイバーエージェント）向け」が行われたらしく、まだ500点を出した人はいません。 そこで僕は「満点を出したい」と思い、初日から、いやむしろフライングしていたからその前から頑張ってきました。 そして、先日（17日）、ついに500点満点を出しました！ たぶん、レギュレーションはクリアしている、はずです（もし違反してたらすいません…）。 自動で行われる「Visual Re
Webフロントエンドパフォーマンスチューニング85選 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? こんにちは、ぬこすけです。 近年、Webフロントエンドではサイトのパフォーマンスの重要性が高まっています。 例えば、GoogleはCore Web Vitalというパフォーマンスに指標を検索結果のランキング要因に組み込みました。 また、近年の某企業が「パフォーマンスの改善に取り組んだ結果、セッション数〇％アップ、CVR〇％アップ...」などの事例は枚挙にいとまがないでしょう。 パフォーマンスチューニングするためには、定量的に計測してボトルネックを探すようなトップダウンなアプローチもあります。 しかしながら、時には千本ノック的にハウツーを
第9回 pt-query-digestを使って遅いクエリーを発見する | gihyo.jp
遅いクエリーの調査をしてみようとして、実運用環境でスロークエリーログを出力してみたところ、思っていたよりもたくさん出力されていしまい、もはや何が起こっているのかわからなくなってしまうことはありませんか？ スロークエリーログにいくら有益な情報が入っているとはいえ、数が多くなってしまうと一個一個確認していくのには気が遠くなるような時間と根気が必要となってしまいます。せっかくのIT技術を使っているのに人手による努力はなるべく避けたいものです。ということで大変なスロークエリーログの集計はPCやサーバにやってもらうことにしましょう。 そこで今回は、PERCONA社が公開しているPercona Toolkitのうちの、MySQLのクエリーから統計を取って教えてくれるpt-query-digestというコマンドツールについて説明をしていきます。 デモンストレーション環境 今回使用する環境は第7回 スロー
プロダクトのパフォーマンスを改善するためにVue.jsの関数型コンポーネントやpropsに関する施策を行った話 - SMARTCAMP Engineer Blog
こんにちは！フリーランスエンジニアとしてスマートキャンプに参画している芳岡です。 弊社のプロダクトであるBiscuet(https://biscuet.jp/)の開発に初期から参画していますが、サービスが世の中に展開されていく過程、チームが大きくなっていく過程を間近で見れとても興味深く思っています。 今回は、そのBiscuetで使用しているVue.jsのパフォーマンス改善を行ったのですが、そこで気づいたいくつかのポイントを整理してお届けします。 Vue.jsのパフォーマンス 関数型コンポーネント propsは、オブジェクト全体か各プロパティごとか？ プロパティごとに渡す方法 オブジェクトを渡す方法 注釈 最後に Vue.jsのパフォーマンス Vue.jsでは、状態変更によって、仮想DOMが繰り返し再計算（updateRender)されるため、それによりパフォーマンスが悪くなることがあります
Vue・React・Angularのパフォーマンス比較検証 - ICS MEDIA
ウェブのフロントエンド開発に役立つライブラリとして、VueとReact、Angularがよく取り上げられます。これらのライブラリは、SPA（シングルページアプリケーション）の開発に役立つ多くの機能を持っています。 フレームワークを選定するには、「人気だから使う」という短絡的な理由で選択をするのは望ましくありません。設計思想や機能の種類、学習コストなどの観点で、プロダクト・プロジェクトチームへの適性を検討するのがセオリーです。幸いにも、それぞれを比較した記事がウェブに数多くあり、選定のヒントを簡単に得ることができます。 一方、機能面の比較ばかりが取り上げられ、性能面で紹介されている記事が少ないように見受けられます。記事『サービスにおいて速さこそが神である｜深津 貴之』でも紹介されているように、昨今のウェブはスピードが求められる時代でもあり、ライブラリの性能評価の記事があってもよいのではないで
フロントエンドを100倍速くした（ ＾ω＾） - Qiita
おはようございます、なのくろです。年の瀬ですね。 この記事は ABEJA Advent Calendar 2020 の最終日です。 追記：おかげさまで Qiita LGTM賞 を受賞いたしました、ありがとうございます！ 私は2020年01月にABEJAへ入社しました。チームではフロントエンド開発全般を任されています。 参入してちょうど１年が経過しましたので、今年取り組んだことをまとめました。 「フロントエンドを100倍速く」というタイトルは誇張気味なのですが、難しいことはせず、基本的なパフォーマンス改善を素直に実践したという話を書きます。 本稿では事例とやったことを紹介するのみですが、何かしらの知見や改善のきっかけに役立てば幸いです。 サービスについて 話をする前に、どんなサービスを開発しているかについて少しだけ触れます。 ABEJA社では「Insight for Retail」という、小
1000万件オーバーのレコードのデータをカジュアルに扱うための心構え - joker1007’s diary
自分が所属している会社のメンバーの教育用資料として、それなりの規模のデータを扱う時に前提として意識しておかなければいけないことをざっくりまとめたので、弊社特有の話は除外して公開用に整理してみました。 大規模データ処理、分散処理に慣れている人にとっては今更改めて言うことじゃないだろ、みたいな話ばかりだと思いますが、急激にデータスケールが増大してしまったりすると環境に開発者の意識が追い付かないこともあるかと思います。 そういったケースで参考にできるかもしれません。 弊社は基本的にAWSによって運用されているので、AWSを前提にした様なキーワードやサービス名が出てきます。後、句読点があったり無かったりしますが、ご容赦ください。 追記: 社内用の資料の編集なのでかなりハイコンテキストな内容だから誤解するかもしれませんが、これらはそもそもRDBの話ではありません。(関係無くは無いけど) 1000万オ
急なレスポンスタイム悪化から、オープンソースプロジェクトにPull Requestを送るまで - 弥生開発者ブログ
こんにちは、Misoca開発チームの黒曜(@kokuyouwind)です。 最近はシャニマスのイベントシナリオ感想記事をnoteにまとめたりしています。 😨 急に本番のレスポンスタイムが悪化した話 Webエンジニアにとって、「本番障害」という4文字ほど見たくないものはないでしょう。 本番障害ほどではないにしても、「急なレスポンスタイム悪化」もあまり見たくない文字列ですね。まぁ、見たくなくても向こうからやってくるんですが… というわけで、今回は本番レスポンスが急に悪化したときの話です。いろいろ調べた結果、利用しているオープンソースプロジェクトが原因だったことがわかりPull Requestを送ったので、その流れをまとめてみたいと思います。 ❗️ レスポンスタイム悪化の検知 Misocaでは監視ツールとしてMackerelを、APMツールとしてSkylightを利用しています。 本番レスポン
長期休暇のときは要注意！pumaのメモリ管理をしよう ~計測こそ正義~ — みんなのウェディングエンジニアリングブログ
みんなのウェディングのインフラエンジニア横山です。 今回はpuma利用時のメモリ管理と、計測の大切さについてお話ししたいと思います。 何が起きたか 始まりは今年の1月1日、元旦でした。 インフラエンジニアの携帯に1通のアラートが届きました。それは、appサーバのAvailable Memory低下を表すものでした。 その当時のグラフを以下に貼ります。 原因がすぐにはわからなかったため、緊急対応としてappサーバの再起動を行ったところ、Available Memoryの値は回復しました。 原因究明 1月4日、新年初出社の初仕事はAvailable Memory低下の原因究明でした。 まず、ステージング環境のAvailable Memoryの値を確認すると、ステージング環境では起きていないことがわかりました。 そこで、アクセス数が関係しているのでは？と考えました。 また、コードフリーズ日である
pumaのthread数の伸縮がどのように行われているか - 名有りさんの日記
pumaが同時に建てるthread数はこちらで指定することが出来る 実際の定義を見るとこのように2つの値を入れることが出来る threads 5, 16 第一引数が最小値、第二引数が最大値を表しているらしく、処理の際に自動でスレッド数をスケールしてくれるらしい 実際どのように動くか空気感を調べる必要があったためメモ 最初にまとめ 語弊がある気もするけどこんな感じ 最初は最小値の数だけthreadを用意する (thread poolに格納される) 既存のthreadが全てビジーな状態になった際、現在のthread poolのスレッド数が最大値に達していない場合は Thread.new して新しいthreadを確保 thread数が +1 される 30秒おきにthread poolの状況を確認し、もし待ち状態のthreadが存在するのであればthreadを1つ削除するよう宣言 threadの処
Angular パフォーマンスアップ最短最速マニュアル - Qiita
動機 Angular(2 or 4)で開発中のプロダクト(SPA)が重い JS の肥大化 起動が遅い パフォーマンスチューンしたい で、みんないろいろ調べると思うけど… AOT コンパイルとか module の最適化とか手段はいろいろあるのはわかった が、ブログエントリを読んで今開発中のプロダクトに自分で解決策を注入するのが大変 サマリ 対工数効果が高い部分に絞ってパフォーマンスチューンできる、「これさえやればOK！」みたいな進研ゼミ的マニュアルを作った(半ば覚え書きだけど) 平均起動時間1は84%減 4000msec超 -> 640ms2 JS ファイルサイズ3は23%減 2770kb -> 2153kb (Parsed Size) 最適化後の Gziped Size は 393.47kb 前提 この記事は、AngularClass/angular-starter を使ったプロダクトで実
RAIL モデルでパフォーマンスを測定する | Articles | web.dev
目標とガイドライン RAIL においては、「目標」と「ガイドライン」という用語には次のような特定の意味があります。 目標。ユーザー エクスペリエンスに関連する主要なパフォーマンス指標。たとえば、タップして 100 ミリ秒未満でペイントします。人間の認識は比較的一定であるため、これらの目標が近いうちに変更される可能性は低くなります。 ガイドライン。目標の達成に役立つ推奨事項。現在のハードウェアやネットワーク接続の状態に固有のものであるため、今後変更される可能性があります。 レスポンス: 50 ミリ秒未満でイベントを処理 目標: ユーザー入力によって開始される遷移を 100 ミリ秒以内に完了し、ユーザーが操作が瞬時にあると感じられるようにします。 ガイドライン: レスポンスが 100 ミリ秒以内に表示されるようにするには、ユーザー入力イベントを 50 ミリ秒以内に処理します。これは、ボタンのク
サイボウズ版 MySQL パフォーマンスチューニングとその結果 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、アプリケーション基盤チームの青木(@a_o_k_i_n_g)です。先日親知らずを抜歯した時、つらすぎたので MySQL の JOIN のことを考えて心の平静を保っていました。 サイボウズの製品のひとつである kintone はニーズに応じて自由に業務アプリのようなものを手軽に作ることができ、データの検索条件やソート条件も細かくカスタマイズ可能で、様々なレベルでのアクセス権も設定可能という非常に便利なツールです。 しかしその機能を支える裏側では複雑なクエリが発行され、MySQL に多大な負荷をかけています。サイボウズのクラウドには数十テラバイトに登る MySQL データがあり、数千万件オーダーのテーブルを複数 JOIN するクエリが毎秒のように実行されるという、エンジニア魂が滾る環境です。 現在サイボウズでは性能改善に力を入れており、僕もその業務に従事しています。例えば2018年
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://developers.google.com/web/tools/setup/workspace/setup-devtools
Webパフォーマンス最適化のために「RAIL」というパフォーマンス基準を知っておく - Qiita