黒曜の吹き溜まり

Kaigi on Railsに登壇しました

2020-10-04 イベント

2020/10/3 に行われたKaigi on Rails STAY HOME Editionで、パフォーマンスチューニングの話をしてきました。

Railsがテーマのカンファレンスということで実践的な内容が多く、どのセッションも非常に興味深く聞かせていただきました。

完全オンラインのイベントでしたが、YouTube LiveのコメントやSpatialChatでの懇親会などもあり、オフラインでの体験に近い感覚で参加できたのも面白かったです。

アーカイブは後日セッションごとに分けて投稿されるそうなので、そちらも楽しみに待ちたいと思います。

さて、今回は発表の補足として、Twitterでツッコまれていた部分について書いていこうかなと思います。

APMの使い方

確かに、アラート仕込んでおくと不意のパフォーマンス悪化を検知できるのでやっておくのがオススメですね。

ただ「アラートが来たら見る」という運用だと、「現状の維持」はできても「既存の問題の改善」にはなかなか繋がらないので、少なくとも導入後しばらくは「重いエンドポイントがどのくらい重いのか」「どういった処理が重いのか」を定期的に見るのが良いかなーと思っています。

重いクエリ三銃士

多くの人に拾ってもらいましたが、こちらはもちろんラーメン三銃士が元ネタです。

例の画像を使いたかったけど、流石に著作権的によろしくないなと思って自重しました……

MySQLの気持ち

ネタっぽく話しましたが、実際自分がパフォーマンスチューニングするときも「まずこういう絞り込みをしてからこう返すので、こういうインデックスを貼れば使えるはず」みたいなことを考えながら作業してます。

発表にも盛り込みましたが、複雑なクエリで効く複合インデックスを貼るためには、MySQLがどう動くのかを想像しないと難しいんじゃないかと思います。

Google Home誤爆

これは発表中にGoogle Homeが反応してしまって「すみません、よくわかりませんでした」と言い出した件ですね。

せっかくなので「いや、ここまではわかってよ」など気の利いたセリフを挟めると良かったんですが、さすがにそこまで頭が回りませんでした。

机の上にGoogle Homeを置いていたのをすっかり忘れていました… 今後リモート登壇される方は、予め電源を切っておくのがおすすめです。

インデックスの構造

正論なんですが、探索木のデータ構造を図示するのがめんどくさかったのと、初心者の方がパッと見でわかりやすい方を優先しました。

口頭では補足しましたが、「索引と書いてあるところは辞書のように爪になっていて一発で開ける」というほうが、多少不正確でもインデックスという名前と紐付いて動きがイメージしやすいのかなと思います。

N+1クエリ

こちらは説明を端折ってしまったところですね。

そのとおりで、クエリが複数回に分かれるとRailsとRDBの間で通信が何度も発生し、RDS内のテーブルアクセスもまとめられないため、オーバーヘッドが大きくなります。

クエリが流れる回数にもよりますが、N+1クエリ状態だと100msくらいの桁でかかっていたものが、includesを使って解決すると3msくらいになる程度にはパフォーマンスに差があります。

ケーススタディのアルゴリズム改善

これはPDF生成処理の改善についてのコメントですね。

該当Pull RequestのDescriptionには書いておいたのですが、O(N * M)からO(max(N, M))に改善しているため、ほぼ線形での改善になります。(N はUNICODE_RANGESの長さ、Mはcode_mapのキー長)

ただしいくつか穴があって、Nは定数配列のため大きさが固定されているため、計算量という点では無視したほうが良い値の可能性があります。

またアルゴリズムの変更を行うために前処理として両配列をソートしているため、実際にはそちらが律速になっているかもしれません。

動作確認した限りでは英語と日本語の各フォントでいずれも8倍程度の高速化になったため、定数倍改善のような気もします。

まとめ

今回は通しての発表練習を5回くらいやったので、かなりスムーズに話すことができたかなぁと思います。

Twitterを見ててもわかりやすかったと言っていただけたものが多く、大変うれしかったです。

来年もKaigi on Railsやるらしいので、ネタが提供できるよう頑張ります！

rails kaigi_on_ruby
© 2018 by Lednerb
Bilberry Hugo Theme