アプリを高速化する2022/01/23に公開・約6,100字ツイートRuby#performance#puma#SREtech新年あけましておめでとうございます。製アプリケーションをいじって高速化してみる。いう内容を実施しました。コンセプトとしては、『ちゃんと設定ファイルを書くだけでも高速化する』という感じです。作業としてはアプリケーションをいじらずに、設定だけいじって高速化する、ということなんですが、結局何がどれくらい効くのか、というのを事前に参考値レベルで弾いておかないとぶっつけ本番になっちゃうな、ということで何がどれくらい効くのかを試してからにしようということで、事前に調査したときのベンチテストと何を変えたかの記録になります。アプリケーションを作って、その性能差から測ります。返すだけのほぼ何もしないアプリケーションです。結果をキャッシュして毎回固定の文字列を返すとかすればいいんですが、そこまでやりすぎるとあまりにも『何もしない』すぎてベンチマークテストがおかしくなりそうだったので、今回は一旦そのままにしました。側4コア、アプリケーションに裂くのは4コア、みたいな感覚で調整しました。本当は負荷かける側は別マシンとかにしたほうがいいのですが、今回は何をいじるとどれくらい変わるかなーというテストがしたかったのであえてローカルでやっています。ベンチマークコマンド基本的にトップページに負荷をかけたいだけなので、トップページにどこどこ負荷がかかるようにします。使ったサーバーが立ち上がります。試してみることにします。環境変数をいじりつつベンチマークを回していきます。1,1)で最小値の状態でベンチマークを回した結果が以下のとおりです。2.00MB何もしないアプリケーションなので早いかと思いきや、最大90ms近く待たされたりしており、何もしてないアプリケーションにしてはおそすぎです。ワーカープロセスの起動数を指定するオプションです。単純にここの数が増えれば受け付けているプロセスが増えるわけですが、多ければ多いほどいい、というものでもありません。いいよ、と公式でもお達しが出ています。あって4以上から伸びが悪くなります。なくメモリにも影響します。今回の何もしないアプリケーションくらいだとあまり問題になりませんが、あまりにプロセス数を増やしても次はメモリが足りない......などになってしまえば大問題です。プロセスを強制終了される恐怖は現代でも現役です。コア数とメモリに応じて柔軟に変更したほうがよい』という点です。コンテナデプロイ環境だといくつ割り当てたっけ?みたいなことになりがち)。倍くらい〜みたいなことを書くのも簡単です。みたいな決まりにしてもいいでしょう。倍以上性能が違うわけですから、設定しておいて損のない項目です。ワーカースレッド数を指定するオプションです。基本的に受け付けられる同時リクエスト数、と解釈してよいでしょう。こちらも試しに2の倍数ずつ設定してみます。10279.41期待したほど効果が出ません......多少差異はあれど、ほぼ誤差のように見えます。今回の何もしないアプリケーションだとあまり恩恵がありません。操作のおおいようなアプリケーションではここに適切な数字を入れておくことで、性能向上が期待できます。同時接続数にもなってくる点に注意です。負荷になったりします。導入することでアプリケーションはあまり気にせず同時接続数を増やしても良い、なんて場合もありますが、それらの設定がちゃんと環境に導入されているかの確認は必要です。設定されており、この数字でほぼ問題ないことが多いです(アプリケーション次第では10くらいまではあげてもよい)。違ってアプリケーションの特性次第なところがあるので、あまり没頭したり自動化したりせず、アプリケーションにとっていい具合の数字を制御してあげるのがおすすめな項目です。他にも設定しておくとメモリ削減やパフォーマンス改善につながる設定項目は多々あります。注意しなくてはならないこととして、これらの設定項目は見落とされやすく、あるいはアプリケーションリリース時に当時のエンジニアが秘伝技的に設定したままメンテされておらず......みたいな状態になって、現在の設定が妥当かが検証されにくい類の項目でもあります。なったんだよね〜という場合だったりするとこれらの設定をきちんと環境にあったものに変更するだけでいきなり性能改善したりする場合もあり、案外冗談抜きで侮れない項目です。いうパタメータチューニングは程よい設定値を探すことが難しいのですが、いろいろ参考になるドキュメントが世の中に転がっています。公式のドキュメントも大事です。異常に情報がまとまっていて便利です。(前記2つ以外もこれ)です。例外を捕まえるためか、なくしてみると結構性能が変わります。そのものに与える環境変数でも速度が変わったりします。制御する環境変数などは難解複雑ですが、うまくハマれば性能改善も期待できます(書いておいてなんですが、僕は流石にこの辺はいじっていません。どれがどう作用してどうなるのか読み解けなかった......)。そこまでやっているケースはあまり見ません。使うことでメモリの使いすぎを防止する、みたいな話のほうがよく見ます。メモリの断片化を防ぐことで長時間起動した際に増加していくメモリを抑制してくれるのですが、メモリが断片化しないことでアプリケーションのパフォーマンスそのものにも影響するようです。アプリケーションを動かすだけでも設定項目は膨大です。パラメータチューニングなどしはじめるととてもじゃないけど追いつかない......んだけど、ちゃんとすればきちんと効果の出てくれるものでもあります。みんなでやろうぜ!という講座も開いたりしています。あたりでもわかる通り)手元の環境でちょっと実験しただけではわからない部分もおおく、実感を得るための『環境』そのものを作るのが難しい側面があるので、もしこういう話に興味があって実験する環境がほしければ、ぜひウチの講座もご検討いただけると幸いです。までご連絡いただければお答えできます。rosylillyやっていますバッジを贈って著者を応援しようバッジを受け取った著者にはZennから現金やAmazonギフト券が還元されます。アプリケーションの挙動を変える環境変数まとめZennエンジニアのための情報共有コミュニティAboutZennについて運営会社お知らせ・リリースGuides使い方Publicationよくある質問LinksTwitterGitHubメディアキットLegal利用規約プライバシーポリシ。