Optimise PostgreSQL for fast testing
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
Axios 使うのやめたらビルドサイズが 10 KB 減って、なんか知らんがパフォーマンスも良くなった話
この記事について Zenn では長らく通信処理に Axios を使っていました。 しかし、Fetch API が多くのモダンブラウザなどで普通に使えるようになった今、使う必要性があまり無くなったため、Axios を使っている処理を全て Fetch API に置き換えることになりました。 この記事では、その置き換え作業をどう進めていったのか、その結果どう良くなったのかを解説していこうと思います 🗽 解説より置き換えた結果を知りたいのよ私は！！！ って方が居るかと思いますので、最初に置き換えたことで良くなった部分を紹介しようと思います。 まず一番良くなったところといえば、ずばりサイト全体のビルドサイズが 10 KB も減りました。( ちなみに、10 KB は圧縮時のサイズで、圧縮しない場合 100 KB になります 😇 ﾜｰｵ ) グローバルのビルドサイズが 103.35KB gzip 時
Largest Contentful Paint (LCP)
Largest Contentful Paint (最大視覚コンテンツの表示時間、LCP) は、知覚される読み込み速度を測定するための重要なユーザーを中心とした指標です。これは、LCP がページの読み込みタイムラインにおいてページのメイン コンテンツが読み込まれたと思われる時点を示すためです。LCP を高速にすることで、そのページが便利であることをユーザーに強く印象付けることができるようになります。 歴史的に見ても、Web ページのメイン コンテンツがどの程度早く読み込まれ、ユーザーに対して表示されるかを測定することは Web 開発者にとっての大きな課題でした。 load や DOMContentLoaded のような古い指標は、ユーザーが画面上で見ているものとは必ずしも一致しないため、 適切ではありません。また、First Contentful Paint (視覚コンテンツの初期表示時間
詳解 システム・パフォーマンス 第2版
本書は、エンタープライズとクラウド環境を対象としたオペレーティングシステムとアプリケーションのパフォーマンス分析と向上について解説します。 主にLinuxベースのオペレーティングシステムに含まれるツールとその使用例を通じてシステムパフォーマンスを引き出す手法を説明します。システム評価のためのベンチマーク、キャパシティプランニング、ボトルネックの解消について解説しスケーラビリティを制限する要因を発見、分析し、解決する方法を学びます。 第2版では、perf、Ftrace、BPFの解説が加わり、Linuxとクラウドコンピューティングについての説明が充実しました。 システムのパフォーマンスを向上させ、コストを削減し、レイテンシの外れ値を減らすための方法を学ぶ本書はエンジニア必携の一冊です。 まえがき 1章 イントロダクション 1.1 システムパフォーマンス 1.2 職種 1.3 作業 1.4 分析
Goのnet/httpのkeep-aliveで気をつけること - Carpe Diem
概要 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
500ms to 1.7ms In React: A Journey And A Checklist
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
next.jsでのファイルチャンク最適化の一例 - hiroppy's site
今回は graphql-codegen を使い説明します。今回の例は、graphql-codegen 以外でも発生する可能性がありますが自動生成系が一番顕著に影響がわかりやすいです。 graphql-codegen はよく、graphql のスキーマから typescript の型定義/react の hooks 等を自動生成するのに使われますが、これは next.js と組み合わせた場合、少しトリッキーな部分があります。 graphql-codegen はデフォルトでは 1 ファイルにすべて出力されますが、それに対し next.js は各ページを chunks として吐くため何も考えずに実装すると、バンドルされるファイル量が膨大になる可能性があります。next.config.js から webpack の設定を上書きできますが、optimization はかなり上書きしづらくそもそも上書
Tuning Your PostgreSQL Server - PostgreSQL wiki
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
Tuning Your PostgreSQL Server/ja - PostgreSQL wiki
作者 Greg Smith、Robert Treat、およびChristopher Browne PostgreSQLは性能よりも幅広い互換性を目的に設定された、基本設定で配布されています。 デフォルトのパラメータでは、使用中のシステムを過小評価してしまう可能性が高いです。 最終的に把握しなければならない項目のすべて（必要ならばGUC Three Hour Tourを参照してください）に引きずり込まれないように、ここで基本を簡単に紹介することでお助けしようと思います。 これらはPostgreSQLの初心者は気にしない、もっとも一般的なもののようです。 ここで紹介した概要を読んだ後により詳しく知りたければ、各節にてパラメータの名前をクリックしてください。 最新のPostgreSQLのマニュアルの関連文書にリンクしています。 さらにServer Configuration Tuningには、こ
Lighthouseの計測結果を見ていく - Qiita
Google Chrome 60からデベロッパーツールのAuditsタブからLighthouseが簡単に実行できるようになっているので使い方を見ていく。 Chrome89で日本語化されるので、この記事の内容とはだいぶ差異が出てきそう。 パフォーマンス測定に必須のLighthouseがChrome 89で日本語化される Chrome79から各評価項目の参照URLがだいぶ変わってしまっている。web.dev内のページに置き換わっているようだ。 Chrome 103からTimeSpan、Snapshotレポートが追加になり、ユーザーが操作した状態のページの分析も行うことが出来るようになりました。 DevTools の新機能 (Chrome 103) Lighthouseとは Lighthouseとはウェブページの品質改善の指針を「パフォーマンス」、「PWA」、「アクセシビリティ」、「ベストプラク
メルカリShopsのキャッシュ戦略
メルカリ Shops の開発 vcl, python, golang, containers, typescript, etc. が入っている monorepo で開発が行われている。 なので、あまり専門性はあってもどの領域でも開発を行う。 メルカリアプリ上で動いているため、 webview がベースとなりパフォーマンスは普段以上に求められている。 技術スタックはこちらを参照 ユーザーへの UX を下げないために。。 First Meaningful Paint を速くするSkeleton などでフィードバックを適切に行う => とりあえず速く結果を返却すればよい 結果を速く返すために考えること 共通な結果はすべてキャッシュし、CDN などを使い近くに置く極力、ユーザーからのアクセスを origin まで到達させない常に新鮮な結果を近くに保持することにより、上記を満たせるようにする =>
Macのdockerが遅いストレスから解放されよう - Qiita
Macのdocker遅い問題 Macで開発している時、主にRailsなのですがdockerを使うと遅くなるのが嫌でずっと避けてましたが、とあるプロジェクトでBFF構成にし開発環境とデプロイ環境をECS化したりとでdocker化の流れに抗えない状況になりました。 ただ、やはり遅い。 dockerが不慣れなこともありますが、Macのdockerなかなか遅い。 そしてMacが遅い件を調べてみてもみなさん困られるのが伺えます。 そんな中で対策としてよく見かけるのが docker-sync vagrantで別立て の2つでした。 どちらが最適なのかな？と思い悩んでると、 ありました。dockerのドキュメントにまさにこの件に対しての内容が。 ボリュームマウントのチューニング 端的にまとめるとv17.04からcachedとdelegatedというオプションが追加され、書き込み読み込みの一貫性を担保しな
Vue・React・Angularのパフォーマンス比較検証 - ICS MEDIA
ウェブのフロントエンド開発に役立つライブラリとして、VueとReact、Angularがよく取り上げられます。これらのライブラリは、SPA（シングルページアプリケーション）の開発に役立つ多くの機能を持っています。 フレームワークを選定するには、「人気だから使う」という短絡的な理由で選択をするのは望ましくありません。設計思想や機能の種類、学習コストなどの観点で、プロダクト・プロジェクトチームへの適性を検討するのがセオリーです。幸いにも、それぞれを比較した記事がウェブに数多くあり、選定のヒントを簡単に得ることができます。 一方、機能面の比較ばかりが取り上げられ、性能面で紹介されている記事が少ないように見受けられます。記事『サービスにおいて速さこそが神である｜深津 貴之』でも紹介されているように、昨今のウェブはスピードが求められる時代でもあり、ライブラリの性能評価の記事があってもよいのではないで
Real World Performance of gRPC - gRPC 利用による劇的なパフォーマンス改善 | Wantedly Engineer Blog
こんにちは、Wantedly の Infrastructure Team で Engineer をしている南（@south37）です。 先日は、「gRPC Internal」というタイトルで gRPC の設計と内部実装についてブログを書きました。 こんにちは、Wantedly の Infrastructure Team で Engineer をしている南（@south37 ）です。 今日は、WANTEDLY TECH BOOK 6 から「gRPC Internal」という章を抜粋して Blog にします。 「WANTEDLY TECH BOOK 1-7を一挙大公開」でも書いた通り、Wantedly では WANTEDLY TECH BOOK のうち最新版を除いた電子版を無料で配布する事にしました。Wantedly Engineer Blogでも過去 この gRPC ですが、Wantedly
Introduction · Webフロントエンド パフォーマンス改善ハンドブック
Webフロントエンド パフォーマンス改善ハンドブック このパフォーマンス改善ハンドブックでは、ウェブアプリケーションにおけるフロントエンドのパフォーマンス改善について扱っています。 ダウンロード版 埋め込み動画を再生できないなど一部制限がありますが、ダウンロード版を配布しています。 PDF版 EPUB版 MOBI版 目的 このハンドブックでは過去に行った改善の事例を中心に紹介しています。 そのため、現在の最適な解決方法を提案するものではありません。 また、アプリケーションによっても最適な解決方法は異なります。 今回の事例ではViewライブラリにReactを使い映像再生プレイヤーなどある程度複雑な機能を持ったウェブアプリケーションのフロントを扱います。 具体的にはニコニコ生放送（以下「生放送」）で行った事例を中心に書かれています。 開発と平行して行われていたため、React 15から16の間
お前らのReactは遅い - Qiita
煽りタイトルですみません。 最近、Reactのプロジェクトのページを動かしていて、 もっさりしてる（レンダリングの負荷が高いな）と思ったので どうやったら無駄なレンダリングを減らせるか思考錯誤したことをまとめました。 preactとか別ライブラリの話はしません。 よかったらこちらもどうぞ ReactJSで作る今時のSPA入門（基本編） 2019年07月06日追記： ブラウザのレンダリングの仕組みに関して良記事があったので先に一読しておくことをおすすめします。 良記事１：実際のところ「ブラウザを立ち上げてページが表示されるまで」には何が起きるのか 良記事２：ブラウザレンダリング入門〜知ることで見える世界〜 １ピクセルがブラウザに表示されるまで：Life of a Pixel 2018 この記事に関してはReactのDOMツリー（レイアウト）レンダリングに関する最適化戦略です。 2020年02
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Running PostgreSQL in memory only
Core Web Vitals
MPA化するSPAとSPA化するMPA
Use Query insights to improve query performance | Cloud SQL for PostgreSQL | Google Cloud