ミドルウェア性能検証の手引き | 外道父の匠

インフラエンジニアの多分、華形のお仕事の１つであるミドルウェアの性能検証を久々にガッツリやる機会がありましたので、検証作業の基本的な項目について初心から振り返っておきたいと思います。読みやすさ度外視の詰め込み記事注意警報です。 世の中、雑な検証結果もちょいちょい散乱していて、私自身もそうならないよう注意を払っているわけですが、ガチでやると気をつける項目が多くて、自分で忘れたりしないようにと、誰かにやってもらいたい時に基本を抑えてから取り掛かってもらうために、形にして残しておこうと思った次第であります。 目次 なぜ性能検証をするのか 環境の準備 インスタンスの用意 クライアントの用意 サーバーの用意 ボトルネックになりうる項目 CPU Utilization Memory Network Bandwidth Disk Bandwidth Disk IOPS Disk Latency Disk

[GedowFather]

気ままな長駄文を書きました

[kitaj]

実験計画法とかその手の話かと思ったら全然違った。

[huruyosi]

これと併せて勉強する。 https://www.amazon.co.jp/o/ASIN/4774192627/gihyojp-22

[tagomoris]

いい内容 / 分散ミドルウェアになると更にスケールアウト阻害要因とその上限みたいな要素が入ってきて悩ましい……

[aroma_black]

“効果的な考え方は、『最初のボトルネックは何か』『ボトルネックの延命手段は何か』”

[selmertsx]

やっぱすごい

[teckl]

見せかけの数値ではなく、意味のある検証を、と…。 > 効果的な考え方は、『最初のボトルネックは何か』『ボトルネックの延命手段は何か』です。

[otorobo]

“もっと細かいOSやサーバー設定値を変更しながら計測とチューニングマラソンを繰り返”

[castaneai]

性能検証をする際に注意すべきこと、何を記録するか、awsの具体例もあり

[kamatama_41]

ナイスな手引

[miyakawa_taku]

サーバプロセスは1台構成から、というので、へー、と思いました。1と>1ではたとえばクライアントライブラリの構成が変わってしまったり、ZKみたいに本番1台で構成することはあり得なかったりするので、難しい。

[field_combat]

『最初のボトルネックは何か』『ボトルネックの延命手段は何か』

[decobisu]

ありがたい手引き

[sakidatsumono]

こういう記事読んでいればなあ

[l__LINE__l]

自分はヌルかった

[catnapper_mar]

素晴らしい。読み応えある。

[tasukuchan]

ミドルウェアの性能検証は妥当なの難易度高い

[progrhyme]

主にAWSにおける基本がまとまってる。

[braitom]

ミドルウエアの性能検証について。なぜ性能検証をするのか、環境準備する上での考慮点、ボトルネックになりそうな項目とその見方、結果の考察方法などがまとめられている。これはありがたい

[kitadon]

メモ。

[Akaza]

めちゃ勉強になる…。/ "効果的な考え方は、『最初のボトルネックは何か』『ボトルネックの延命手段は何か』です。"

[bopperjp]

ベンチマークではなく“『最初のボトルネックは何か』『ボトルネックの延命手段は何か』”を検証した方がいい。

[Mint0A0yama]

"効果的な考え方は、『最初のボトルネックは何か』『ボトルネックの延命手段は何か』です。それを繰り返すことで見せかけの数字ではなく、石橋を叩いて渡るような検証値を得ることができます"

[katzchang]

「効果的な考え方は、『最初のボトルネックは何か』『ボトルネックの延命手段は何か』」

[gonta616]

素晴らしい内容。なかなか表に出ない検証よことをここまで事細かに。。。何者！？

[Konboi]

検証するときに見直したい

[taruhachi]

基本的な考え方が一致してて安心した。

[shiumachi]

素晴らしい内容。ワークロードの選定部分はもう少し詳しく知りたい。説明可能、公開可能、再利用可能がいいワークロードだと思ってるけど、ネット上のベンチ記事とかだとこのあたり軽視してるものが多い印象ある

[mori_morix]

ありがたい