クラウド的なアレ

WebApiのパフォーマンスチューニングとして次の内容を実施しようと計画中。 処理そのもの - 既存処理の高速化 - 転送データ量の削減 - データ構造自体の変更 - gzip適用 JVM - 起動オプションの変更 DB周り - SQL呼び出し周りの処理の最適化) - オンメモリで持つデータ量の調整)

Angularのアプリをパフォーマンスチューニングするにあたって次の対応をした。 カッコがきは時間がかかるので後回しにした。 描画 モジュールの最新バージョンへの更新 既存処理の高速化 For文へのID指定 (DOM操作量を減らす) (Virtual DOM with CDK) (AOTコンパイル) (Angular Ver up) (Lazy load) (不要画面の削除) DLサイズ 不要モジュールの削除 モジュールの最新バージョンへの更新 コンパイルオプションの変更 ビルドハッシュ (AOTコンパイル) (Angular Ver up) (不要画面の削除) ただ、結局これではせいぜい20%前後の改善しか見られなかった。 (前後のパフォーマンスはGoogle ChromeのLighthouseを使った。ただ、あれの測定結果も安定しないからちょっと微妙) 使用しているライブラリの都合によりAOTは無効にしていた。 が、改めて検証してみると、やはりAOTを有効にすることの方がよっぽど影響が大きくて既存の40%程度の改善が見られた。 ただし、AOTを有効にすると一部の書き方を変更しないといけないのでその点だけが厄介だった。 具体的には例えば、 import chartjs-plugin-annotation; を import * as chartjsAnnotation from chartjs-plugin-annotation; のようにして、必ずchartjsAnnotationを使うようにするというもの。 この対応にコストを払うのが惜しく、先延ばしにしてきたが、ついにそのツケを払うときが来た模様。 これで高速化されると期待。(原理的にAOTが有効になれば当然高速になるけれど)

Jave Performance, 2nd Editionを読んでる。 performance testing: microbenchmarks, macrobenchmarks, and mesobenchmarks 3種類ある。 * Microでは測り方が大事。ウォームアップが必要。 * Macroではシステム全体のスループットが大事。RPSが高まらないと意味がない。 * Mesoは局所と全体の間。 Performance can be measured as throughput (RPS), elapsed time (batch time), or response time, and these three metrics are interrelated. ウォームアップは必要だが、エンドユーザーからすると結局それは関係ない話。 二回目のアクセスではキャッシュされていて速いとしても一回目のアクセスが大事。 その点で、elapsed timeでの測定が大事。 スループットを測るときはクライアントのスペックが大事になる。 クライアント側のスペックがパフォーマンス測定のボトルネックになったりする。 レスポンスタイムで見るなら、できればワンショットではなく、アベレージと1%%の結果も見る。 でないとパフォーマンス全体の中での見落としにつながる。 簡単なパフォーマンステストにはFabanがおすすめ テスト結果を見るときはt検定で有意な差があるかを確認する Microベンチマークにはjmhを使用すると良い

こんな感じで書いたら標準入力を受け取れる fn main () { let mut s = String ::new(); std::io::stdin().read_line(& mut s).unwrap(); // hello => assert_eq! (s, "hello\n" ); // 改行文字も含まれる } CLIツールを作るのに、Wantedlyの資料が分かりやすかった。 * Rust速習会2 - Speaker Deck  https://speakerdeck.com/qnighy/rustsu-xi-hui-2 * Rust速習会3 - Speaker Deck  https://speakerdeck.com/qnighy/rustsu-xi-hui-3 * Rust速習会4 - Speaker Deck  https://speakerdeck.com/qnighy/rustsu-xi-hui-4

JVMのチューニングのためにフラグについて理解する。 フラグには2種類ある。 -XX :+FlagName(Enable Flag ), -XX :-FlagName(Disable Flag ) -XX:FlagName=X( Set X to FlagName) 基礎的なことだけれど、ExperiencedなJava Developerにも意外と知られていない、らしい。

Red Hatが中心に作っているQuarkusという新しいフレームワークを触り出した。 WebサイトではSuper Sonic & Subatomicと謳っている。 Super Sonic：めちゃ早い Subatomic：小さい →早くて小さいJavaフレームワーク 調べてみるととりあえず、わかりやすい利点としては次のようなものがあるらしい。 1つのconfigファイル： 1つのconfigファイルを見て管理する(その中でdev, test, prodを分けて書ける) CI/CDの文脈でHuman Errorを減らしやすい 使用メモリ量： k8sでは1000ものマイクロサービスが動いたりする 同じようなコードのアプリをたくさん書いてマイクロサービスとして動かすが、そうなったときに1つ1つの大きさが全体への大きな影響になったりする QuarkusはJavaの制約だったJavaのメモリ使用量などを下げることができた 実戦に使えるレベルかは試してみないとわからないけれど、感触としてはSpringよりも触り心地が良く、今すぐに置き換えてみたいと思えるレベル。

仕事でOpenShiftを触ることになった。 コンテナを扱うので、自分の勝手のきくイメージを使った方が理解が進みやすいと思い、以前にRustで作ったHello, Worldを返すだけのイメージを使うことにした。 挙動としては問題なし。 ただ、使用しているライブラリ(Rocket - Simple, Fast, Type-Safe Web Framework for Rust  https://rocket.rs/  )の影響で、StableなRustではなくNightly Buildを有効にしなければならない。 内部的に開発を進める人が使うもの、というイメージもあり、直感的に突っかかるものがあり、別のフレームワークを探した。 少し簡単に探したところ、tideというライブラリを紹介している記事( Web Development with Rust — 03/x: Create a REST API - DEV Community 👩‍💻👨‍💻  https://dev.to/gruberb/web-development-with-rust-03-x-create-a-rest-api-3i82  )に出会った。 最近よく読むdev.toだし、内容も理解しやすいし、少しRocketよりは直感的ではないけど試してみよう。そう決意した。 が……このライブラリもNightly Buildを必要としていた。 tide 0.2.0 - Docs.rs  https://docs.rs/crate/tide/0.2.0 調査中に出会した別のライブラリ(Gotham web framework  https://gotham.rs/  )は、tideとほぼ同じだけのStarを獲得している一方、tideほどWatchの数が大きくなく、また、tideのときの記事のような分かりやすい記事がなかったので、一度離れたのだけれど、改めて確認し、そこに素晴らしい文言が書いてあるのに気がついた。 Stability focused. All releases target stable Rust. そう、そう、それを求めていた。Rustにどっぷり浸かれるような環境にないから、Edgeすぎるとついていけないのは目に見えていた。だから、Stableをターゲットにしていて欲しかったのだけど、この

Slow Warm Boot 最近ようやく、少しずつ、自分のライフステージについて受け入れられるようになってきた。 何かで見た四象限。自分、家族、友人、他人。元来、自分に対する比率が高く、家族に対する比率は低かった。子供が生まれた後でさえも。 正確には、徐々に家族からの人手不足を求められ、結果として家族に時間を割くことが増えていってはいたものの、目標値と実測値に差異があって、結果として自分のやりたいことをやれていない感覚がつきまとって離れなかった。 わかっていたことでも突き付けられると再理解できることはある。 付き合いの長い先輩に相談をしたときに得られた回答はマインドを変えるきっかけの一つになった。 結論いえば、自分のやりたいこと、時間を含めてどこまで自分の能力を捧げるかで決めたほうがいいです。 やらねばならぬで耐え方を考えてがんばって、自己満足に陥ると、やりたいこと、自分のためにやるべきことが思考から外れがちではないでしょうか。 仕事にやりたいことが大量に転がっていて、それはチャンスではありますが、以前の話したCovyの7つの習慣の仕事以外、「家庭」「健康」「財産」「教養」「趣味」とも比べて、どこまで捧げるかを決めればいいかと思います。 責務を持ちながら手を抜くはNGですが、できもしない量を引き取ってできないのであれば、結果的には手を抜いたのと同じです。 そして、続けてもらった次の言葉が多分、自分には刺さったのだと思う。 「押し込もう」とする方を支えてあげたいと思うであれば、受け取ってあげればいいし、押し込まれる仕事がやりたくなければ"砂をかけない"ような理由で断るものよいでしょう。 それ以外にも下地の準備はもちろんあって、例えばnoteで公開されていた次の記事もそうだった。 妻子持ちエンジニアとしての休日の過ごし方｜Keisuke69｜note https://note.com/keisuke69/n/n2b5c9e25cd09 自分自身でこのテーマについて考える時間を持っていたこともあって、結果として気持ちをようやく現状に追い付かせることができつつある。 Planned Happen Stanceとも少し違うけれど、変化を起こすと言うよりも、変化を受容