ヤフー全社横断「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"(訳注 : 以下ストールと言う)とは、プロセッサーが
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%の実行時間を占めている） ありとあらゆるところを最適化しても効果は得られな
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.
第1回 JVMはどのようにメモリ空間を利用するのか | gihyo.jp
あのWebサービスもJVMを利用している 「Javaは大規模なエンタープライズシステムにしか使われない」 それが常識だと思っていませんか？ たしかに、これまでJava Virtual Machine（JVM）は、他の言語を実行すると遅く、Javaのプログラムを実行する環境にすぎないものでした。ところが、Java 7から実装されたInvokeDynamicにより、JVM上で、RubyやPHPなどさまざまなコンピュータ言語で記述されたプログラムをより高速に実行できるようになりました。 これにより、今までエンタープライズでJava言語で記述されたプログラムを実行するだけの環境であったJVMが、汎用的な実行環境になったと言えます。また、これまでJavaの実行環境として使用されていたノウハウが、他の言語で記述されたプログラムを実行する際にも利用できます。 最近では、TwitterがJVMをアプリケー
「バックエンドの経験はなかった」Instagram創業者は、どうやってシステムをスケールさせてきたか
昨日のPinterestの記事「Pinterestの急成長を支えてきたアーキテクチャとは？ Pythonで開発しAmazonクラウドで運用」に続いて、やはり写真を中心としたサービスで急成長してきたInstagramのスケーラビリティについて、まとめてみました。 InstagramもPinterestと同様に、基本はAmazonクラウド上でPythonとフレームワークのDjangoを使ったシステムを構築しています。興味深いのは、創業者の二人ともバックエンドの経験がないなかで試行錯誤をしてシステムをスケールさせてきた点です。 Instagramは先月、Facebookに買収されると発表されています。この先、Instagramのシステムはどう変わっていくのでしょうか。 Instagramのシステム構成 約半年前、昨年12月にInstagramのブログに投稿された記事「What Powers In
ゲーム開発とSTL - とあるぼっちの生存報告
コンシューマ向けゲーム開発に携わって結構な年数が経過しました。 これまでは恵まれていたのか、STLを使える環境にいた*1ので特に気にしていなかったのですが、どうやら場所によってはSTLはゲーム開発向きではないらしく使用を禁止される事もあるようです。 おかしいですね。私、STL使ってコンシューマ向けのゲーム作ってきましたけど。 確かにSTLはその特性と使用方法を知らないと痛い目にあいます。特にコンシューマ機のメインメモリ容量はPCに比べて圧倒的に少ないです。その少ないメインメモリ上に実行バイナリやヒープ領域などを展開しなければなりません。メモリ管理に対してシビアになるのは当然で、templateは使用方法によってはバイナリサイズが増大するので使用をある程度制限する事は仕方ありません。 また、std::listや、std::map等は使えば使う程内部でメモリを平然と分断してくれるので、ヒープ領
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
SSE4.2の文字列処理命令の紹介に関する補足（アイランとページ境界）
x86/x64最適化勉強会1 なんとか無事終了. ustがうまくいったりいかなかったり, 運営が手間取ったりと申し訳ない. 主催するというのはたいへんだなあ. 名前だけはwebなりでよく見かけていたけど会ったことなかった方々に会えたので満足. でもこれまた初めてお会いした@takehiro_tさんとは殆どしゃべれなかった. 残念. 個人的にはw_oさんのベンチマークの結果から理由を探していく部分が興味深かった. 反省点 : 発表の間は5分マージンを入れておく. タイマーあるとよさげ. とりあえずいくつかの資料へのリンク(uploadされれば随時更新). herumi : 条件分岐とcmovとmaxps m_asama : IA32/Intel64におけるキャッシュ利用最適化 sinya8282 : 開発中のJIT版grepの苦労話 TAKESAKO : ビットを数える herumi
Objective-Cの『遅さ』を計測したら、JavaやC++の5倍も遅かった
なお、メモリ消費量はtopコマンドで測ったので、かなり大雑把な数字だ。また、Cで同様の処理のコードを書くと、ほぼC++と同じ速度になる。 追記(2011/02/17 8:50)：Rubyによるベンチマークを追加。 追記(2011/02/17 11:00)：Smalltalkによるベンチマークを追加。ソースコードは「Smalltalkのtは小文字です」のループ回数を修正した。 追記(2011/02/17 16:00)：Perlによるベンチマークを追加。 追記(2011/02/18 10:30)：Java 1.6.0_22で実行した、Scalaによるベンチマークを追加。また、clang/llvmでC++とObjective Cの値を取り直し、改善が見られないのを確認。 追記(2011/02/18 14:30)：Ruby 1.8.7によるベンチマークを追加。1.9.2との速度差については、@IT
メソッド呼び出しループベンチにSmalltalkで参戦してみる - Smalltalkのtは小文字です
Objective-Cの『遅さ』を計測したら、JavaやC++の5倍も遅かった: ニュースの社会科学的な裏側 ただし手元の環境（MacBook Air 11", 1.6GHz Core 2 Duo, Win 7）は非力なので、ループ回数は 268435455回に減らしました。Cygwin環境であるせいか、Objective-C は元記事でとりざたされている結果と違い、C++ の５倍までは遅くなっていませんでした。かたや Java は C++ の２倍程度に遅くなっていて、Objective-C とはほとんど差がありませんでした。 Smalltalk はまずまずの結果といった感じでしょうか。正直、爆速を誇る商用処理系であるところの VisualWorks には、C++ とまではいかずとも Objective-C には肉薄して欲しかったところですが、前述の通り Objective-C に逃げ切ら
開発メモ: Kyoto Cabinetのロック機構の改善
Kyoto CabinetはIO負荷が高い場合にCPU負荷も高くなりがちだという指摘を受けて、それを解決すべくロック機構を見直したという話。 スロットロック ハッシュテーブルの操作はハッシュバケット毎に完全に独立して実行できるのが強みだ。ハッシュテーブルは計算量が有利なだけでなく、並列性にも優れるということ。実際には下層のファイルIOで実装依存の排他制御が行われることになるが、ハッシュ層だけ見れば理想的な並列性を備えている。ただし、同じバケットに連なるレコード群の操作は互いに依存関係があるので、それらは一括して排他制御してやる必要がある。となると、バケット毎にロックを用意するのが理想だが、実際にはメモリを節約するために、予め決めた数のロックを用意して、ここのロックに複数のバケットを割り当てる構成をとる。リソース空間をスロットに分けるというイメージから、これをスロットロックと呼ぼう。 スロッ
卜部昌平のあまりreblogしないtumblr - 最速の memset64 を求めて 今回のお題は char 幅じゃなくて word 幅の...
今回のお題は char 幅じゃなくて word 幅の memset 、つまりプロトタイプだと void* memset64(void* destination, uint64_t image, int num_words); をどれだけ高速に行うかという話。なぜ高速化するかというと、塗りつぶす領域がけっこうでかいから。 候補 1: REP STOSvoid* memset64(void* d, uint64_t i, int n) { asm("cld; rep stosq;" :: "D"(d), "a"(i), "c"(n) : "memory"); return d; } 最近の CPU はクソ賢い。そのため、下手に手で loop unrolling するよりも、逆に CPU に「ここはループなんだぞおおお～」というのを明示的に指示してあげたほうが CPU 側が勝手かつ不気味に最適な
C言語: 実行時間測定の方法
C言語において実行時間を測定する為の方法はいくつかある。gettimeofday, clock, getrusage, timesを利用する方法である。ここではこれらの方法について検証してみる。これは2005/12/30時点での情報であり、古い亊が考えられるので注意して頂きたい。さらに、内容のほとんどはmanを移しただけなので、正確な情報を得るためにそれぞれの関数のmanを見ることを強く推奨する。 System: Linux 2.6.12 glibc: glibc 2.3.5-1ubuntu12 gettimeofdayを使用する方法 通常はこの関数を使用するのをお勧めする。 gettimeofdayはSVr4, BSD 4.3準拠である。返り値の型はsys/time.hに定義されるstruct timevalで有る。
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
プログラミング言語の速度とアプリケーションの速度がいかに関係ないかがわかるグラフ - kなんとかの日記
まずは次の表をご覧あれ。これはプログラミング言語のベンチマークとして有名な Computer Language Benchmarks Game のベンチマーク結果。上にいくほど高速で、下に行くほど遅い言語になる。 これを見れば、最速な言語は C/C++ であり、Java や Haskell や OCaml といった静的な言語は軒並み上位に登場する。これに対し、Ruby や Python や PHP といったスクリプトは全部下のほう (つまり遅い)。その速度差は非常に大きく、このベンチマークで見ると Python3 や Ruby1.9 は C/C++ の約50倍から60倍遅く、Perl は約90倍、PHP にいたっては約130倍遅いことになる。 (ちなみに JIT つきの Lua が驚異的に高速なのが目をひく。この結果が本当だとしたら、言語の速度に大きく関係するのは動的か静的かではなく、どれ
電源問題も、スクリプト言語の息の根を止める原因になるかも : akiyan.com
電源問題も、スクリプト言語の息の根を止める原因になるかも 2010-04-27 目次 HDDは本当に遅い スクリプト言語の息の根を止めるのは案外 SSD かもな - kwatchの日記 に大変共感した。 しかし SSD が主流になり、ディスクアクセスや DB がボトルネックにならない (あるいはなったとしてもペナルティが少ない) ような時代になったら、言語の速度差がそのままアプリケーションの動作速度になる可能性がある。そうなると、プログラミング言語の速度が今よりずっと重要になるだろうし、動作速度の遅いスクリプト言語は人気が暴落するかもしれないね。まあ暴落まではいかなくとも、人気が下がることは大いにありうる。 HDDは本当に遅くて、いつだってボトルネックに成り得る。ゆえに、スクリプト言語側の遅さは気にされにくかった、というのは盲点だった。 そこでもう一つ、「電源」についても、スクリプト言語の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
カスタムメモリマネージャと高速なメモリアロケータについて
