Clipした日: 2024-11-24T13:36:37+09:00 Clipした記事: [Xユーザーのmizchiさん: 「mizchi「オブザーバビリティには(不勉強も可能性もあるが)LCP計測軸で必要な粒度のデータがない。フロントエンドも otel の累積で測るべきか、別軸で視標を定義してしまってもいいか」 t_wada「基本的に既存のサーバー監視文脈にはフロントエンドの語彙がない。フロントエンド軸で再定義していい」」 / X](https://x.com/mizchi/status/1860342291015360718) ---- ## ポストする ## 会話 mizchi「オブザーバビリティには(不勉強も可能性もあるが)LCP計測軸で必要な粒度のデータがない。フロントエンドも otel の累積で測るべきか、別軸で視標を定義してしまってもいいか」 t\_wada「基本的に既存のサーバー監視文脈にはフロントエンドの語彙がない。フロントエンド軸で再定義していい」 引用 t\_wadaさんにフロントエンドのテレメトリの計測軸に関する疑問をぶつけて、色々納得いく回答が得られて良かった。後でまとめる… [  ](https://x.com/shinofara) 自分の経験的にE2Eのパフォーマンス計測視点だと、サーバーサイド起因の問題は全体の6~7割に過ぎず、ビジネスロジック起因のRTTを調査することが多い。その軸の tracing-id でマイクロサービス単位のスパンを Server-Timing ヘッダに突っ込むと良いのでは、という話になった E2EのLCP確定のメジャーシナリオ 初期HTML メインCSSのブロッキング メインJS による API リクエスト メインJS による コンテンツ展開 展開後のレイアウト確定(img) ここのシナリオに同じ tracing-id を付けてLCP確定の内訳を調査できるとよい ほしいのは初期HTMLレスポンスとAPIリクエスト内部の(マイクロ)サービス内のグラフ経路コストで、DBやサービス間通信の粒度でデータが取りたい。既存テレメトリはその内部を取ってるので、やっぱりほしい粒度が違う。 そうなると高水準なので、扱う場所が datadog のようなAPMかBIかやや怪しくなる 一旦Next.js+Prismaみたいな環境で計測プロトを作ってみて、それで機能するか検証する。それは後日。今日は力尽きた テレメトリデータを欲しい粒度に畳む関数とか書くといい、みたいな話をしたんだったな PostgreSQLのカラムとしてSQLiteを入れ子で埋め込み。SQLITE型の爆誕である。SQLiteに対してもクエリーを実行できるが関数で呼び出す形になるのでJOINはやや難しくなるかもしれない。 / “GitHub - frectonz/pglite-fusion: Embed an SQLite database in your PostgreSQL ta…” Rust製エディタのZedが内部で文字列を保持しているデータ構造を工夫してカーソルの位置からの行、列の計算を高速化した話。 Rope Optimizations, Part 1 これは私だけかもしれんけど、「四六時中能力を発揮して働き続ける」のって結構疲れて、「能力ほぼゼロで労力だけ発揮して働いてる状態」をベースにしながら「ときどき能力も発揮する」てのが楽でいいなーと思うのだけど、だんだん前者を求められるようになってきつつ… 引用 労力は外注できるが、能力は外注できない x.com/t\_wada/status/… [  ](https://x.com/t_wada/status/1859756507115684348/photo/1) 「クソ、誰だよこの素人みたいなバグ仕込んだの…」 \`\`\` $ git blame ... 1234abcd (Satoru Takeuchi ... ... \`\`\` 「みんな、無益な犯人探しはやめて、この難局をどう乗り切るかを考えよう」