株式会社ハウテレビジョン様で、 質問箱サービスMondのパフォーマンス分析と改善を行いました。 内容としてはLCPの内訳の計測、その解決方法の提案、そして一番大きな問題だった GraphQL リクエストの最適化という話になります。 現時点で全ての問題の修正には至っていませんが、開発的には全ての問題の内訳が認識可能になっていて、検証が終われば段階的にリリースできる、という状態です。 以下、敬称略 相談内容 mond.how のLighthouseスコアを改善してほしい 主要な技術構成 Next.js - Page Router Hasura CE - GraphQL Server Hasura のセルフホスティング版 計測と問題 最近は Chrome が出してくれる Lighthouse スコアの推移が見れるダッシュボードがある。 ここで Mond の直近のスコアをみる。 代表例として ht
株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。 bashパフォーマンスMySQLInnoDBDB設計インデックス こんにちは、羽山です。 今回は MySQL のプライマリキーに UUID を採用する場合に起きるパフォーマンスの問題を仕組みから解説します。 MySQL(InnoDB) & UUID のパフォーマンスについては各所でさんざん議論・検証されていますが、論理的に解説した記事が少なかったり一部には誤解を招くようなものもあるため、しっかりと理由から理解するための情報として役立つことができればと思っています。 UUID と比較される古き良き昇順/降順のプライマリキーはというと、 MySQL の InnoDB において良いパフォーマンスを出すために縁の下の力持ちのような働きをしてくれているケースが実は少な
![MySQLでプライマリキーをUUIDにする前に知っておいて欲しいこと | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/5e9d48c3c6f38c2d5f71897d98efcb251289d1f9/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Ftechblog.raccoon.ne.jp%2Fwp-content%2Fuploads%2F2021%2F07%2Fboard-755792_800.jpg)
I am switching to PostgreSQL from SQLite for a typical Rails application. The problem is that running specs became slow with PG. On SQLite it took ~34 seconds, on PG it's ~76 seconds which is more than 2x slower. So now I want to apply some techniques to bring the performance of the specs on par with SQLite with no code modifications (ideally just by setting the connection options, which is probab
この記事について Zenn では長らく通信処理に Axios を使っていました。 しかし、Fetch API が多くのモダンブラウザなどで普通に使えるようになった今、使う必要性があまり無くなったため、Axios を使っている処理を全て Fetch API に置き換えることになりました。 この記事では、その置き換え作業をどう進めていったのか、その結果どう良くなったのかを解説していこうと思います 🗽 解説より置き換えた結果を知りたいのよ私は！！！ って方が居るかと思いますので、最初に置き換えたことで良くなった部分を紹介しようと思います。 まず一番良くなったところといえば、ずばりサイト全体のビルドサイズが 10 KB も減りました。( ちなみに、10 KB は圧縮時のサイズで、圧縮しない場合 100 KB になります 😇 ﾜｰｵ ) グローバルのビルドサイズが 103.35KB gzip 時
Largest Contentful Paint (LCP) is an important, stable Core Web Vital metric for measuring perceived load speed because it marks the point in the page load timeline when the page's main content has likely loaded—a fast LCP helps reassure the user that the page is useful. Historically, it's been a challenge for web developers to measure how quickly the main content of a web page loads and is visibl
本書は、エンタープライズとクラウド環境を対象としたオペレーティングシステムとアプリケーションのパフォーマンス分析と向上について解説します。 主にLinuxベースのオペレーティングシステムに含まれるツールとその使用例を通じてシステムパフォーマンスを引き出す手法を説明します。システム評価のためのベンチマーク、キャパシティプランニング、ボトルネックの解消について解説しスケーラビリティを制限する要因を発見、分析し、解決する方法を学びます。 第2版では、perf、Ftrace、BPFの解説が加わり、Linuxとクラウドコンピューティングについての説明が充実しました。 システムのパフォーマンスを向上させ、コストを削減し、レイテンシの外れ値を減らすための方法を学ぶ本書はエンジニア必携の一冊です。 まえがき 1章 イントロダクション 1.1 システムパフォーマンス 1.2 職種 1.3 作業 1.4 分析
概要 Idle connectionをプールするkeep-aliveの仕組みですが、Goで適切に使用するためにはいくつか注意があります。 環境 golang/go 1.13.1 TCP Keep-Aliveの挙動をパケットキャプチャで確認する 例えば以下のようにDefaultTransportの一部の設定（①、②）をイジってリクエストを送ると client = &http.Client{ Transport: &http.Transport{ DialContext: (&net.Dialer{ Timeout: 30 * time.Second, KeepAlive: 10 * time.Second, // ① DualStack: true, }).DialContext, ForceAttemptHTTP2: true, MaxIdleConns: 100, IdleConnTim
Written by Oren Farhi, Front End Engineer Tech Lead, follow me on This article has been translated: Chinese 1 (by Qlly) Chinese 2 (by Qlly) Korean (by Ykss) I bet the need to tweak perfomance comes in a certain phase of development for every developer, in every app. There are very good resources and articles about how to tweak performance in react and this article is no exception. I thought I will
今回は graphql-codegen を使い説明します。今回の例は、graphql-codegen 以外でも発生する可能性がありますが自動生成系が一番顕著に影響がわかりやすいです。 graphql-codegen はよく、graphql のスキーマから typescript の型定義/react の hooks 等を自動生成するのに使われますが、これは next.js と組み合わせた場合、少しトリッキーな部分があります。 graphql-codegen はデフォルトでは 1 ファイルにすべて出力されますが、それに対し next.js は各ページを chunks として吐くため何も考えずに実装すると、バンドルされるファイル量が膨大になる可能性があります。next.config.js から webpack の設定を上書きできますが、optimization はかなり上書きしづらくそもそも上書
by Greg Smith, Robert Treat, and Christopher Browne PostgreSQL ships with a basic configuration tuned for wide compatibility rather than performance. Odds are good the default parameters are very undersized for your system. Rather than get dragged into the details of everything you should eventually know (which you can find if you want it at the GUC Three Hour Tour), here we're going to sprint thr
作者 Greg Smith、Robert Treat、およびChristopher Browne PostgreSQLは性能よりも幅広い互換性を目的に設定された、基本設定で配布されています。 デフォルトのパラメータでは、使用中のシステムを過小評価してしまう可能性が高いです。 最終的に把握しなければならない項目のすべて（必要ならばGUC Three Hour Tourを参照してください）に引きずり込まれないように、ここで基本を簡単に紹介することでお助けしようと思います。 これらはPostgreSQLの初心者は気にしない、もっとも一般的なもののようです。 ここで紹介した概要を読んだ後により詳しく知りたければ、各節にてパラメータの名前をクリックしてください。 最新のPostgreSQLのマニュアルの関連文書にリンクしています。 さらにServer Configuration Tuningには、こ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Google Chrome 60からデベロッパーツールのAuditsタブからLighthouseが簡単に実行できるようになっているので使い方を見ていく。 Chrome89で日本語化されるので、この記事の内容とはだいぶ差異が出てきそう。 パフォーマンス測定に必須のLighthouseがChrome 89で日本語化される Chrome79から各評価項目の参照URLがだいぶ変わってしまっている。web.dev内のページに置き換わっているようだ。 Chrome 103からTimeSpan、Snapshotレポートが追加になり、ユーザーが操作した
メルカリ Shops の開発 vcl, python, golang, containers, typescript, etc. が入っている monorepo で開発が行われている。 なので、あまり専門性はあってもどの領域でも開発を行う。 メルカリアプリ上で動いているため、 webview がベースとなりパフォーマンスは普段以上に求められている。 技術スタックはこちらを参照 ユーザーへの UX を下げないために。。 First Meaningful Paint を速くするSkeleton などでフィードバックを適切に行う => とりあえず速く結果を返却すればよい 結果を速く返すために考えること 共通な結果はすべてキャッシュし、CDN などを使い近くに置く極力、ユーザーからのアクセスを origin まで到達させない常に新鮮な結果を近くに保持することにより、上記を満たせるようにする =>
Macのdocker遅い問題 Macで開発している時、主にRailsなのですがdockerを使うと遅くなるのが嫌でずっと避けてましたが、とあるプロジェクトでBFF構成にし開発環境とデプロイ環境をECS化したりとでdocker化の流れに抗えない状況になりました。 ただ、やはり遅い。 dockerが不慣れなこともありますが、Macのdockerなかなか遅い。 そしてMacが遅い件を調べてみてもみなさん困られるのが伺えます。 そんな中で対策としてよく見かけるのが docker-sync vagrantで別立て の2つでした。 どちらが最適なのかな？と思い悩んでると、 ありました。dockerのドキュメントにまさにこの件に対しての内容が。 ボリュームマウントのチューニング 端的にまとめるとv17.04からcachedとdelegatedというオプションが追加され、書き込み読み込みの一貫性を担保しな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
