Rust のパフォーマンスに何が影響を与えているのか - Qiita
動機 The Rust Performance Book という書きものを見つけました。いろいろなパフォーマンス改善テクニックが書かれているわけですが、実際に普段書いてる Rust コードの中で一体何がパフォーマンスに与える影響が大きいのか？という点が気になってベンチマークを取ってみました。 今回パフォーマンスを計測するプログラムはビットマップ画像（1600px x 1200px）をグレースケールに変換する処理です。I/O のパフォーマンスは無視します。&[u8]から RGB をそれぞれ 1byte ずつ（合計 3bytes）取ってきて、それをグレースケールの 1byte に変換してVec<u8>にする時間を計測します。イメージとしては下記のような関数です。 // source が カラーのビットマップ画像のデータ fn sample(source: &[u8]) -> Result<Ve
How We Saved 70K Cores Across 30 Mission-Critical Services (Large-Scale, Semi-Automated Go GC Tuning @Uber)
How We Saved 70K Cores Across 30 Mission-Critical Services (Large-Scale, Semi-Automated Go GC Tuning @Uber) Introduction As part of Uber engineering’s wide efforts to reach profitability, recently our team was focused on reducing cost of compute capacity by improving efficiency. Some of the most impactful work was around GOGC optimization. In this blog we want to share our experience with a highly
結局useMemoはいつ使えばいいの？ 僕の決定版 - Qiita
皆さんこんにちは。筆者の以前の記事では、ReactのuseMemoを無駄に使うことによるレンダリング速度のオーバーヘッドがどれくらいかをベンチマークによって示しました。 それによれば、スマートフォンを想定したとしても、useMemoだけで描画に目に見える影響を与える（16msくらいの遅延を発生させる）には万のオーダーのuseMemoが必要なことが分かります。 速度ではなくuseMemoを使うことによるメモリ消費量の増加を気にする声も聞かれましたが、すみませんが筆者はそこまでメモリクリティカルなアプリをReactで書いたことがなく知見に乏しいため、今回はこの記事の対象外となります。 この結果が出たことでuseMemoをいつ使うのかなどという議論には終止符が打たれたかと思いきや、上記の記事の感想などを見ているとまだ喧々囂々です。 そこで、この記事では筆者の考えを皆さんに共有し、いよいよもってこ
Chrome Devtools による フロントエンドパフォーマンスの計測
こんにちは。株式会社スタメンでFANTSのフロントエンドを担当している@0906kokiです。 今回の記事では、皆さんおなじみの Chrome Devtools にある Performance タブで、フロントエンドのパフォーマンスを計測する方法について書きたいと思います。 はじめに フロントエンドのパフォーマンス・チューニングと言うとバックエンドと比べて後回しになりがちですが、フロントエンドにアプリケーションの複雑性が寄ってきている現在、フロントエンドがボトルネックでレスポンスのレイテンシーが発生することは往々にしてあると思います。 バックエンドではユーザー数の増加や大量の同時接続に耐えられる負荷対策やパフォーマンス・チューニングが中心となりますが、フロントエンドではプロジェクトサイズの増加による JavaScript ファイルのダウンロードやスクリプティング、レンダリング速度の低下等が
Comparing NGINX Performance in Bare Metal and Virtual Environments – NGINX Community Blog
Comparing NGINX Performance in Bare Metal and Virtual Environments While there has been an explosive growth in public cloud adoption due to the COVID‑19 pandemic, enterprises are also embracing hybrid cloud, where they run workloads in both public clouds and on premises (in a private data center, say). This hybrid approach enables enterprises to deploy their workloads in environments that best sui
データベースを自動でチューニングしてくれるサービス「OtterTune」
現代のデータベースには設定可能な項目が数百単位で存在しており、その全てを適切に設定して最高のパフォーマンスを導き出すのは並大抵のことではありません。そうした人間には難しいチューニングをデータベースの使用状況を把握して自動で行ってくれるサービスが「OtterTune」です。 OtterTune - Database optimization. On autopilot. | OtterTune.com https://ottertune.com/ OtterTuneを使う時に特殊なソフトウェアのインストールやコードの変更は不要で、OtterTuneをデータベースに接続して何を目標にするかを選べばOK。目標には例えばクエリパフォーマンスやコストなどを設定可能です。接続が完了すると自動で接続時点での設定や統計情報を読み取り始めます。このとき、テーブル情報やクエリなどデータベースの中身に関する情報
How M1 Macs feel faster than Intel models: it’s about QoS
Last week I showed fascinating screenshots of how M1 Macs can run background processes exclusively on their four ‘efficiency’ cores. I’ve now been digging deeper, and this article is a summary of how Intel and M1 Macs deal with multiple tasks, priorities and resources under macOS, and how that influences our assessment of their speed. Operations and QoS Whether Intel or ARM cores, macOS has to man
フロントエンドのパフォーマンスチューニングを俯瞰する - 30歳からのプログラミング
去年からフロントエンドのパフォーマンスについて断続的に学んでいるが、自分の頭のなかにある知識はどれも断片的で、まとまりを欠いているような感覚があった。 知識と知識がつながっておらず、各施策が何のために行われるのかも、必ずしも自明ではなかった。何となく「パフォーマンスに効果がある」と言ってしまうが、それが何を指しているのかは実は曖昧だった。 このような状態では新しい知識を得ていくのが難しいというか、効率的に行えないように思えた。議論の背景が分からないし、文脈や問題意識を上手く掴めないから。何の話をしているのかよく分からない、という状態になりがち。書かれてあることの意味は分かっても論旨を掴めているわけではないから、自分のなかに定着しない。 そこで、現時点で自分が知っていることを整理して、自分なりに分類しておくことにした。 当たり前だが、どのテクニックがどの程度有効なのかは、状況によって違う。
nextjsのISRを使うときのfallback指定について理解するまでの話
next.jsのISRを使おうとして「なんか全然うまく行かない」ってなってたのがやっと理解出来たのでメモ 問題編 とりあえず見様見真似でISRはrevalidateとfallbackつければ良いんだな？とやってみたところ、どうもpropsが空Objectになってしまうようで悩んでいた。 例えば下記のような場合、エラーが起きる // pages/greeting/[name].js const Page = (props) => { // ↓ここでエラー return <div>Hello {props.name.toUpperCase()}</div> } export const getStaticProps = async (req) => { return { props: { name: req.params.name }, revalidate: 100 } } export c
JavaScript performance beyond bundle size
23 Feb JavaScript performance beyond bundle size Posted February 23, 2021 by Nolan Lawson in performance, Web. 8 Comments There’s an old story about a drunk trying to find his keys in the streetlight. Why? Well, because that’s where it’s the brightest. It’s a funny story, but also relatable, because as humans we all tend to take the path of least resistance. I think we have the same problem in the
Redis Clusterとgo-redisの深刻な性能劣化を解決した話 - ゆううきブログ
さくらインターネット Advent Calendar 2020の23日目です。 現時点では最新版のRedis 6.0のRedis Clusterに対して、Go言語の代表的なRedisクライアントライブラリであるgo-redisからアクセスしたときに、性能が深刻なレベルで劣化しました。 この記事では、ミドルウェアを利用したGo言語アプリケーションの性能劣化に関する問題調査の事例として、この性能劣化を修正するまでの話をまとめました。 go-redisへのPull Requestはhttps://github.com/go-redis/redis/pull/1355です。 はじめに 半年ほど前の論文の締め切りに追われていたある日、評価実験のためにRedisを使った時系列データベースのプロトタイプを開発していました。 ベンチマークツールでプロトタイプの性能を測定したところ、単一インスタンスのRed
JavaScript で遅延評価を導入して起動を高速化した話
この記事は、JavaScript で Flash Player の実現を頑張った（もしくは現在進行系で頑張っている）人たちの集う Flash Advent Calendar 2020 に参加しております。 Flash Player を JavaScript で実装していた際に、現場から「起動の高速化」という難しい要求をもらった際、「遅延評価」を導入したところ大変効果がありました。今回、その遅延評価について簡単なご紹介をしたいと思います。 Flash Player 起動までのステップ 当時 Flash Player を JavaScript で提供していた際、当時のスマートフォン端末においてロード完了から最初の画面が出るまで大体 150ms くらいかかっていました。普通の Web ページであれば 150ms はロード時間の中に吸収され許容範囲になる可能性が高いのですが、当時 Flash Pl
メタ・パフォーマンスチューニング
2020/12/15 @ FE Study #2 パフォーマンスチューニングの話です。
パフォーマンス分析に関するアンチパターン - 勘と経験と読経
いくつかの書籍に書かれたパフォーマンス分析に関するアンチパターンを整理してみた。ここに無いものでご存知のパターンがあればご教授いただきたい。アーキテクチャや組織のパターンはよく見るけど、対応手法に関するパターンってあんまり多くないのかも（もしくは単にアンテナ感度が悪いだけ？） 詳解 システム・パフォーマンス (Systems Performance: Enterprise and the Cloud)より 詳解 システム・パフォーマンス 作者: Brendan Gregg,西脇靖紘,長尾高弘出版社/メーカー: オライリージャパン発売日: 2017/02/22メディア: 単行本（ソフトカバー）この商品を含むブログ (1件) を見る 第2章 メソドロジでいくつかアンチパターンが紹介されている(アンチではないほうのパターンも)。 書籍の内容の一部は、以下の翻訳記事および元ネタ記事と同様と思われる
ZOZOTOWNにおける検索速度改善までの道のり - ZOZO TECH BLOG
こんにちは。ZOZOテクノロジーズZOZOTOWN部 検索チーム 兼 ECプラットフォーム部 検索基盤チームの有村です。 ZOZOTOWNでは先日公開した記事の通り、すべての検索をElasticsearchへ置き換えました。置き換え直後は順調に見えたのですが、実際に数%ずつリリースしていく中で一部時間帯、一部リクエストでレスポンス速度の低下がみられました。 本記事ではその解決のために行ったパフォーマンス調査、チューニング方法についてご紹介します。なお、一般的に行われるであろうElasticsearch本体のパラメータチューニングの話ではなく、クエリやmapping、setting面の話がメインとなります。 改善前後の速度について 詳細な内容の前に、本改善によるレスポンス速度の最終的な改善結果を示します。 今回の計測では、一定パターンのリクエストを10秒間繰り返し、95%tileのレスポンス
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
NginxのRatelimit発動時に、安定したアクセスを提供するngx-smart-ratelimitを開発しました | ten-snapon.com
Amazon RDS移行のための 性能検証でわかった2つのこと
ISUCON 11 Prior
GitHub - privatenumber/minification-benchmarks: 🏃♂️🏃♀️🏃 JS minification benchmarks: babel-minify, esbuild, terser, uglify-js, swc, google closure compiler, tdewolff/minify
GitHub - jlfwong/speedscope: 🔬 A fast, interactive web-based viewer for performance profiles.
