ヤフー全社横断「Webパフォーマンス改善」の取り組み (Core Web Vitalsスコアの向上)
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、第11代黒帯（ヤフー内のスキル任命制度／Webフロントエンド領域）の浜田（@narirow）です。今回はヤフー全社で実施してきた、「Webパフォーマンス改善プロジェクト」についてお話ししたいと思います。 長期に渡る活動の結果、多くのサービスのWebパフォーマンスが徐々に向上しています。この記事では、取り組みの経緯や、多くのサービス分析を通してわかったコスパの良い施策（比較的簡単に実施できてスコアも上がりやすい施策）などをご紹介します。 全社横断でWebパフォーマンス改善を実施する経緯 さかのぼること2021年、Googleから以下のような案内がありました。 「Core Web VitalsがGoogle検索の検索順位に
CPU使用率は間違っている | Yakst
Netflixのパフォーマンスエンジニアである筆者からの、topコマンドなどで表示されるCPU使用率(%CPU)は、いまや本当の使用率を表しておらず、チューニングなどのための指標として使えないという指摘。なぜそうなってしまったのか、何を見れば本当のCPU使用率がわかるのかをわかりやすく解説した記事。 私たちみんながCPU使用率として使っている指標は非常に誤解を招くもので、この状況は毎年悪化しています。CPU使用率とは何でしょうか？プロセッサーがどのくらい忙しいか？違います。CPU使用率が表しているのはそれではありません。私が話しているのは、あちこちで、あらゆる人たちに、あらゆる監視製品で、あるいはtop(1)でも使われている、"%CPU"という指標のことです。 あなたの考えているであろうCPU使用率90% : 実際 : "stalled"(訳注 : 以下ストールと言う)とは、プロセッサーが
詳解 システム・パフォーマンス
TOPICS System/Network 発行年月日 2017年02月 PRINT LENGTH 784 ISBN 978-4-87311-790-4 原書 Systems Performance FORMAT PDF EPUB 本書はエンタープライズ環境とクラウド環境の両方を対象としたオペレーティングシステムおよびオペレーティングシステムのコンテキストにおけるアプリケーションのパフォーマンス分析と向上について解説します。主にLinuxとSolarisベースのオペレーティングシステムに含まれるツールとその使用例やチューニング可能パラメータの設定を通じてシステムパフォーマンスを引き出す手法を学びます。CPUやメモリ、ファイルシステムなど個別テーマごとに設けられた各章の前半では、用語、考え方、方法論について述べ、後半では実装の具体例を示しつつ、アーキテクチャ、分析ツール、チューニングなどを解
WebSocket大合戦：Clojure、C++、Elixir、Go、NodeJS、Ruby | POSTD
Webアプリにリアルタイムの双方向通信が必要な場合、WebSocketを選ぶのは自然なことだと思います。では、どのツールでWebSocketサーバを構築すべきでしょうか。パフォーマンスは重要ですが、開発のプロセスも見過ごしてはなりません。パフォーマンスを基準にするだけでなく、開発のしやすさも考慮に入れるべきでしょう。今回の大合戦では、Clojure、C++、Elixir、Go、NodeJS、Rubyのそれぞれの言語によって慣用的な手法で実装されたシンプルなWebSocketサーバを比較したいと思います。 テスト内容 サーバに実装するのは、 echo と broadcast の2つのメッセージのみを扱う非常に単純なプロトコルです。echoは送信クライアントに返され、ブロードキャストは全ての接続クライアントに送信されます。そしてブロードキャストが完了すると、結果メッセージが送信者に返されます。
さらなる高みへ〜iOSのMERYでなめらかなスクロールを実現するためにやった4つのこと - peroli Developer's Blog
2016 - 07 - 01 さらなる高みへ〜iOSのMERYでなめらかなスクロールを実現するためにやった4つのこと list Tweet こんにちは。 iOS を主に担当していますアプリエンジニアのkazutoyoです。 MERYのアプリチームでは、チューニングを「さらなる高みへシリーズ」と名づけて、日々アプリの改善をしています。 今回はその中で行ったUITableViewやUICollectionViewのスクロール周りを滑らかにする改善についてやったことをご紹介したいと思います。 1. CALayerで角を丸くしている部分のパフォーマンスが悪い このようなカード型のViewが並んでいるCollectionViewがあったのですが、画像の角を丸くするのにCALayerで cornerRadius をつけているところのパフォーマンスがあまり良くないようでした。 これを次のようにCor
#cmdevio2016 (レポート: B-3) Swiftで書かれたコードのパフォーマンス・チューニング | DevelopersIO
本記事ではDevelopers.IO 2016 セッションB-3でRealm 岸川克己氏に発表いただきましたSwiftで書かれたコードのパフォーマンス・チューニングのレポートをお届けします。 はじめに 今回しない最適化の話 アルゴリズム メモリ 言語機能をつかった最適化の話をします。 自己紹介 Realmで働いています。 是非この後もRealmについて聞きに来てください。 SQLiteより高速で使いやすいです。 最適化の前に 早すぎる最適化は諸悪の根源である（Knuth先生: Art of computer Programming の著者） 最適化の前に計測する 可読性とのトレードオフ UITableViewとかでキャッシュをクリアするとかもあるある ソフトウェア 80 / 20 ルール （20％の実行コードが80%の実行時間を占めている） ありとあらゆるところを最適化しても効果は得られな
次世代Webカンファレンス「サーバーサイドパフォーマンス」レポート #nextwebconf | DevelopersIO
こんにちは、虎塚です。 10月18日(日)、次世代 Web カンファレンスへ行ってきました。イベントの趣旨は「「次世代 Web カンファレンス」を開催します - Block Rockin’ Codes」で公開されています。 最初のセッション「server_perf (サーバーサイドパフォーマンス)」に参加してメモを取ったので、共有します。 オーナー: @mirakuiさん クックパッドでインフラ担当 @xcirさん ゲーム屋さんでインフラ担当 @cubicdaiyaさん メルカリでインフラ担当 登壇者の紹介 mirakuiさん：サーバサイドパフォーマンスというセッションは、次世代Webの文脈では話題選びがむずかしい。サーバサイドアーキテクチャもモニタリングも別にセッションがあるので、Webのパフォーマンスの話に絞る必要があった。そんな話ができる方ということで、xcirさんとcubicdai
foldmethod=expr が重い場合の対処法 - 永遠に未完成
この前vim_fold.vim 作ったんだけど、これが結構重い。 foldmethod=expr ではその性質上折り畳みレベルを計算するために該当関数が全行に対して呼ばれる。行数が多ければ当然重くなる。呼び出されるタイミングについては help に明記されていないのだけれど、どうやらテキストが変更されるたびに呼ばれているっぽい。つまり1文字入力する度にバッファの行数分関数が呼ばれる。まままじか!? こりゃたまらんぞ プラグイン側である程度は最適化できるかもしれないけれどたかが知れてるし、何よりこの程度で重いのでは他の同タイプのプラグインでも同じ問題が起きるだろう。 と言うわけで、対処法の一例を紹介することにする。 この設定で Insert mode に入った際に一時的に foldmethod=manual に変更し、Normal mode に戻った際に再び foldmethod=expr
遅いッ！遅すぎるッ！Java の正規表現のお話。 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、ミドルウェア開発チームの青木です。 先日、アプリケーションサーバーが応答を返さなくなるトラブルに遭遇しました。 今回はその時のトラブルの原因と対策の顛末についてお話しようと思います。 現象 アプリケーションサーバーが突如応答を返さなくなりました。 現象が発生したアプリケーションサーバーのスタックトレースを見ると、あるスレッドの先頭が上記のようになっていました。 "qtp258153142-514386" prio=10 tid=0x00007f40b8dbf000 nid=0x7b4e runnable [0x00007f415ccb0000] java.lang.Thread.State: RUNNABLE at java.util.regex.Pattern$Loop.match(Pattern.java:4692) at java.util.regex.Pattern$G
なぜHTTPSはHTTPより速いのか
先週、httpvshttps.com というウェブサイトが公開されました。このウェブサイトでは、HTTP と HTTPS を用いてアクセスした場合のウェブページのダウンロード完了までにかかる時間の比較ができるのですが、多くの環境で HTTPS の方が HTTP よりも高速なことに驚きの声が上がっていました。 HTTP が TCP 上で平文を送受信するのに対し、HTTPS は TCP 上で TLS (SSL) という暗号化技術を用いて通信を行います。ならば、TLS のオーバーヘッドのぶん HTTPS のほうが遅いはずだ、という予測に反する結果になったのですから、驚くのも無理はありません。 実は、この結果にはからくりがありました。 Google Chrome、Mozilla Firefox、最近のSafari注1は、Google が開発した通信プロトコル「SPDY」に対応しており、HTTPS
Macの動作が重い/遅い時に試すべき対処法すべて | ゴリミー
Macの動作が重い/遅い時に試すべき対処法すべて 動きがもたつく時に試したい基本的なメンテナンス方法から各種リセット方法まで紹介 かつてOS Xと呼ばれていた時代ではOSをアップデートしたことによってMacを投げ捨てたくなるほど動作が重くなってしまう問題が起きる場合もあったが、最近のmacOSでは比較的動作が安定している。 「OS X Yosemite」の頃は、Mission Controlが固まる。文字入力も固まる。ウィンドウをスムーズに切り替えることができない。複数のウィンドウやアプリケーションを開き、文字入力をする僕にとっては作業にならなくて非常に困っていた。 試行錯誤を重ねた結果、僕のMacBook Proは絶好調だ。相変わらずメインのブラウザはGoogle Chromeで、4Kディスプレイを複数台接続してモリモリ作業をしている。動作が重くなってしまったMacを安定させる方法、もと
Linux Performance
static, benchmarking, tuning: sar, perf-tools, bcc/BPF: bpftrace, BPF book: Images license: creative commons Attribution-ShareAlike 4.0. This page links to various Linux performance material I've created, including the tools maps on the right. These use a large font size to suit slide decks. You can also print them out for your office wall. They show: Linux observability tools, Linux static perfor
G1GCのつかいどころメモ - nekop's blog
以下の環境とテストでCMSとG1GCを比較してみた。かなり急ぎでやったので間違っている可能性が多少ある。 16 cores, 32GB mem -Xms24g -Xmx24g 8 instances Infinispan 6.0.3.Final DIST cache, put 4GB data (1KB entry * 2M, 2GB data with one backup copy, 2GB * 2 = 4GB) CMS: -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=30 G1GC: -XX:+UseG1GC -XX:G1HeapRegionSize=16m -XX:InitiatingHeapOccupancyPercent=30 $ java -XX:+UseG1GC -XX:+PrintFlagsFinal
運用に効く！JVMオプション三選
12月4日に開催された「Salesforce World Tour Tokyo」のDeveloper Zone内のセッションで利用された資料です。 ※こちらSpealkerDeckにあがっていたものをSlideShareへコピーしたものです。 オリジナルはこちらです。 https://speakerdeck.com/konyu/herokuterailsahuriyun-yong-falsehahuomansu-seodui-ce
clang+llvmでさりげなくすごいコードが生成されていた話。 - 組み込みの人。
先日llvm 3.3がリリースされました。aarch64(arm 64bit)のコードが生成できるようになったということなので、ソースからビルドして遊んでいたのですが、さりげなく凄く最適化されたコードが生成されているのに気がつきました。aarch64だと今は実行して確認できる環境が手元に無いので、普通のarmv7-aで同じことを試しました。 ここで使ったコードとその結果はgistに貼りました。 https://gist.github.com/tetsu-koba/5835724 ソースコード int sum(int x) { int sum = 0; int i; for (i = 1; i <= x; i++) { sum += i; } return sum; } 1からnまでの総和を求める関数です。1から100までの総和が5050なのはガウス少年の逸話で有名ですね。 gcc 4.8.
RDBMSでコネクションプールが必要な理由、わからない。
Takayuki Shimizukawa @shimizukawa @masa_edw コネクションプールが無い場合、使い終わったコネクションが即解放されない（解放まで多少遅延する）ので実際に使っているコネクションの数より多く存在する。その分メモリを圧迫して効率が悪い。っていう話は聞いたことがあるよ（要出典 2013-09-04 09:27:28 ハイパーむとう @masa_edw @voluntas 現状で必要な状況は理解していますが、なぜそうなるのか理解していないということです。他にもたとえば、bitlyの呼び出しはコネクションプールを使うべきか？なぜ(べき、べきでない)のか？どういう要請でそうなのか？と言う問いに僕は答えられません。 2013-09-04 09:31:22
G-WANはなぜ速いのか？をnginxと比べながら検証してみた - blog.nomadscafe.jp
ツチノコブログのWEBサーバベンチマークツール比較の記事で紹介されていた。WebサーバのG-WAN。この記事によると凄く速いようです。 Intel Xeon E5-2640 (6コア/12スレッド 2.50GHz) を2つというサーバで gwan 334944 req/s nginx 111842 req/s と、速いと言われているnginxの3倍の速度を出しています。 このベンチマーク結果がとても気になったので、なぜG-WANが速いのか、自分でも検証してみました。 結論から言うと以下の2つ。 1) G-WANはデフォルトで物理CPUに合わせた数のスレッドを起動する 2) HTMLファイルも一度読み込んでキャッシュする という事です。 今回はAWSのcc2.8xlarge(E5-2670 8コア/16スレッド 2.60GHz *2)を使ってベンチマークを行いました。OSはAmazon L
Javaでヒープ領域を余らせたままOutOfMemoryErrorを出す方法 - 西尾泰和のはてなダイアリー
先日、こんな問題を見かけたのだけども、JavaのGCにはあまり詳しくないので答えがわからなかった。 OutOfMemoryErrorが発生しました。(中略)ヒープメモリは足りているようです。原因として何が考えられますか？ http://d.hatena.ne.jp/iad_otomamay/20130318/1363596244 なんでだろうなぁと思っていたところid:moriyoshiが「Permanent領域があふれたんじゃないの」と一言。「Permanent領域」で検索してみると、なるほど、そういうことなのかー。 というわけで早速それを再現させるコードを書いてみた。ヒープの大部分ががら空きなのにPermanent領域だけ99%になっているのがわかるかと思う。 Exception in thread "main" [Full GC [Tenured: 515K->515K(56896K
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PHP 7のパフォーマンスが高い理由
Javaトラブルに備えよう #jjug_ccc #ccc_h2
