鏡音さんの節分祭
おはようございます。 2月の4日の日曜日です。
今日はちょっと ランニングでもしようかなと思って
家を ちょっと薄着で
飛び出してみて スタスタと走り始めてみたんですけど
なんか体が重くて 途中から歩いています。
昨日は節分で 夕方ぐらいに、そういえば節分だと思って
気づいたんですけど 結局
外には出かけずに 家でえほうまきを一応食べて
今年は東北東向きだったんですかね 東北東の方を向いて
パクッとえほうまきを食べたぐらいで 節分っぽいことは終わったんですけど
京都の 声日記をしている皆さんが
節分祭に行っていて まずは甲野夫妻ですね
甲野夫妻が 吉田神社の節分祭に
行かれていて まあ出かけるとしたら距離も近いし
吉田神社かなぁと思って 行こうかなぁとか言ってたんですけど
まあ結局行かなかったんですけど 行けたら開いたのかなぁなんて
パフォーマンスチューニングの始まり
思って 見てました
いいですねちゃんと出かけてて さらにもうちょっと上級編なのが
もりちんさんで なんと3つも節分の行事を
はしごされたということで
京都の神社系を 3つ回られていましたけど
そんなにいろいろあったんだっていう 全然知らないのばっかりで
なんかあのひょっとこの 顔が面白かったですね
3つ目の神社かな 神社の前はたまに通るんで
あの存在はしてたんですけど そんなところでもそんなのやってたんだっていう
写真をあげられていて なんか知らないお祭りがいろいろ
紹介されていて 森鎮さんの
ご縁起きも 面白かったです
でなんで 出かけなかったかというと
昨日は リッスンの
パフォーマンスチューニングを ずっとやっていて
なかなか夜になっても安定しなかったんで 結局もう終わりと思って
仕事を切り上げたつもりが ああそこがダメだとかここは動いてないとか
なんだかんだか言いながら 結局夜遅くまで12時ぐらいまでかな
なんかやってて 平日よりも長い時間作業したなっていう
日になりましたけど
パフォーマンスチューニングって
ある意味面白いんですよね あのハマる
なんか独特の快感がありまして まああのやったところで新機能が追加されたりとか
人を驚かしたりっていう まあ早くなれば驚いてくれるかもしれないけど
新しいものが生まれるとかじゃないんで ただちょっと早くなったりとか
動作が軽くなったりするだけなんで
なんか そんなこう
クリエイティブなことではないし まあいつかやらなきゃなぁみたいな感じで
後回しにしてた ことをそろそろ思い越し上げようかみたいな
始まりなんで最初は結構 ああそろそろしなきゃいけないかみたいな感じなんですけど
パフォーマンスの改善と工夫
やりだしたりやりだしたりね結構 あの面白くて
面白いというか何かやり続けちゃうんですよね それなんでかって言ったら
新機能の開発とかだと あのこういうの作ろうかなって考えて作っては壊し作っては壊ししながら
こんな感じだなっていうのが出来上がって でできたっていう瞬間があるんですよね
でできたってなって出したら一旦その作業は そこで終わりっていう感じで結構区切りがわかりやすくて
まあ作り始めから完成までの一連の まとまりみたいなのがあるんですけど
パフォーマンスのチューニングってなんていうかな やればやるほど早くなるんですよね
やれることは結構無限にあるというか なので
やればやっただけ早くなるんで なんかついついね
こうだんだん 勢いが出てくるとじゃあこれもやってみようあれもやってみようって言って
どんどんやってしまう しまうっていうところがあって
あんまりキリがないっていうか別にあの もっとやろうと思えば結構やることはあるっていうのがずっとあるんで
っていうのと まあ
ある程度細かいサイクルで 成果が見えやすいっていうのがあって
まあちょっとこれをやればここはちょっと早くなってみたいなことが細かくたくさんあるんで まあその分ねやったらやったで
皆さんに喜んでもらえるのかなとか思うとどんどんやっちゃうみたいなところがあって なんか金曜日ぐらいからやりだしたんですけど
金曜日もなんか夜中までなんかいつの間にか 9時すぎぐらいかなオフィスで
あのふと気づいたら遅くて なんかねあんのうにやたら人がいたんでまだ7時8時ぐらいかなと思ってたら
ふって時計見たら9時ぐらいになってておーって思って まあそれもちょっと遅かったんですけど
昨日もまあ結局1日中やってて 割と夜中まで
やってました なんかちゃんとリスンでパフォーマンスの改善みたいなの
やったのは 初めてではないけどあのちゃんとやろうとやろうと思ってやったのは初めてかもしれない
ですけど
そうですねまあかなりここから 技術的な話になりますけど
今回だからあんま興味ない方は 閉じていただいても大丈夫です
えっとまずねあの 何が遅いか測る必要があるんですよね
どこがそもそも時間かかってるのかっていうのを知らないと早くすることもできないんで まず何で測定をするかというところから始まり
まあ多分いろんなデータベースのクエリーが 時間かかってるやつとか無駄なものがあると思うんで
まあそれをまず知る方法があるということで まあ今何時間かかってるかっていうのを測らないと改善しようもないっていうところで
何で測るかっていうのがあって まずそれをいくつか試した上で
データベースのクエリーを全部見て それぞれの実行時間ですね
がどれぐらいかかっているかというのと あとは重複クエリーですよね同じ
同じデータベースの参照を何回もしてたりとか するのがわかるっていうツールをまず入れまして
でこれはまあ開発環境でだけ動かせるだけだとどうしても本番のボトルネックってのが わからなかったりするんで
まあちょっと本番にも入れて 計測をまずし始めるというところからやりまして
で最近本当あの トップページが重かったのと
あとはまあダッシュボードですよね ダッシュボードが重いっていうところで
まずそこから手をつけようと思ってやり始めました でまあコマゴマといろいろ重くなっているところを見つけては直していってやるんですけど
だいたい大きく言うと対策としては 昨日やってたのは3つ
まあなんですかねその重いというのが時に使える技というか こっちの持ち手技っていうのは3つぐらいで
1個目は データベースにインデックスを貼るですね
よく使われるクエリーとか あとは重い時間かかってるクエリーを見つけ出して
そのクエリーが 早くなるような
インデックスを貼ると まあそれが
例えばダッシュボード系だと ポッドキャストの再生数の統計とかところが結構重かったんで
まあそれが割とちゃんと速度が出るようにと思ってインデックスを貼って 改善はしたんですけど
まあちょっとねもうポッドキャストの再生数のデータが100万行ぐらいになってて そもそも1テーブルがでかすぎだろうっていうのがあるんで
ここはまあちょっとまだ重いままなので 多少改善されましたが
ちょっとパーティショニングとか考えないといけないのかなっていう感じですね なのでちょっとまあこれはまだ途中ですけど
そういうとにかくよく使われる部分とか遅い部分の インデックスを貼るっていうのが1つやってたことと
もう1個が これが一番多かったかな昨日いろいろやってた中では
無駄なクエリを減らすっていうことで
クエリっていうのはデータベースにデータをくださいっていう お願いをするっていうもので
こういう条件のデータをこういう順序で くださいみたいなことを
データベースに対して発行してその結果が戻ってくるみたいな感じなんですけど これがねまあ
あんまり何も考えずに
昨日思うままにというか開発を続けてきたので まあ結構1ページを表示するのに
かなりたくさんのクエリが走っていて その中には
イーガーロードによるパフォーマンスチューニング
同じようなものが重複してたりもしたし あとはもっと効率化できるみたいなところがあって
一番はですね イーガーロードって言うんですけど
n プラス1問題とかですかね イーガーロード
をやるっていうことで n プラス1って何かっていうと
例えば なんでしょうね
ポッドキャストのトップページで このポッドキャストのエピソード一覧をくださいっていう
命令をデータベースに対して発行すると 前そのポッドキャストの最新の20件ぐらいのエピソードが戻ってくるわけですけど
そのエピソードを一個一個に対して 例えば星が何個ついてますとか
文字起こしがありますかとか 出演者は誰でしょうみたいな
なんかその付随情報というかそういうのがありますけど これらは
まずエピソードのタイトルとか画像とかはエピソードのテーブルに入ってるんで バッと
戻ってくるわけですけど そのエピソードについた星の一覧とかっていうのはまたその星
星データベースっていうか星テーブルに入ってるわけなんですよね そういうものを例えばエピソード20件取った後で一個一個
20回 星の一覧くださいとか
出演者の一覧くださいとか言って問い合わせると かける20回やることになって
結構思いみたいなのがあるんですけど これはあのドバッとね最初の20件分をまとめて星の一覧を取って
出演者の一覧を取ってみたいなことをやるのがリーガーロードです それをやる仕組みが割としっかり
今使っているORマッパーっていうその データベースのモデルを管理するクラスですけど
には割と備わってるんでちゃんとそれを使って 1ページを表示するために使う作る発行されるクエリを最小限にするっていうことで
だいぶ初期の最初のところで まあそのページを描画するのに必要なデータをもう一式ごっそり
1回のクエリで取得してしまうみたいなことを 1個1個のページで組み込んでいくと
もうなんか酷かったページは 1ページを表示するのに最小
700クエリぐらいあったんかな 630とか700とか出てた気がしますけど
1000近いクエリが走りまくってたページを ちまちまとリーガーロードとか使ったりとかして
やっていって 最後は30クエリぐらいになったかな
にできたりとかしてかなり そこは回数を減らすことができて
もちろんねあの一気にごそっと取るんでその1個のクエリ自体は 一件一件取るよりも重かったりしますけど
全体的にはパフォーマンスが上がっていったり してます
っていうのが2つ目のリーガーロードで で最後はキャッシュですねキャッシュをしていくっていうので
キャッシュの使用と京都市長選
例えば トップページのよく聞かれていますポッドキャストとかを
今更それ今までそれだと思って感じですけど毎回あの 集計して取得してて
まあでもそんな変わらないだろうという話で そういうものをある程度結果をもうキャッシュしておいて
しばらくの間はそれをどんどん返していくっていうことで まあ
そこまで頻繁に更新しなくて良いものをアクセスするたびに集計したりとかをせずに
しばらく一時的に 集計した後の状態をキャッシュしておいてそれを使うっていう
動作をまああちこちちょっと時間がかかってそのところから順番に 適切な保存期間を決めて
埋め込んでいくみたいなことをやってました だいぶ
まあうまくキャッシュが効いていれば特にですけど 早くなってはいる気がするんですがどうでしょうね
でまぁいろいろちょっとそれをやる過程でやっぱりどうしても ここが
うまく動いてるつもりが動いてなかったみたいなのがあってご迷惑をおかけしたりとか あとはちょっとね
なぜかサーバーが止まってしまったりとかして
緊急対応したりとかして ご迷惑をおかけして申し訳なかったんですけど
だいたい昨日はそんな仕事っていうか作業を してました
えっと おはようございます
まあこれで終わりと言いたいところなんですけどちょっとまだ不安定で 特にですねそのキャッシュの作り直しの時になんか今までよりさらに時間がかかっているところがあって
多分そのキャッシュシステムの問題かなと思うんですけど まあそういう問題があったりとか
ちょっと若干まだ 不安定なところがあるので
そこはちょっと様子を見ないとなっていうか改善しないとなっていう 感じですし
まだまだ本当は やった方がいいことっていうのはどれだけでもある
本当ね別にあのもっと爆速で動かそうと思ったらサーバーを増やして あのやるとこまでカリカリにチューニングしてってやっていけばどんどんどんどん速くなっていくんで
別にあのやれることは無限にあると思うんですけど まあまあひとまずあの今のサーバーで
まあある程度 そうですね
現実的に あの使える範囲の速度にっていうの
安定してできるぐらいにちょっと まあできたらなっていうところでまぁ少しまた
気になるところがあれば 続けていきたいなと
思っています えっとちょっとまぁずっとこもってたんで今日はちょっとぐらいは
外に 出たいかなと思います
そうですねあの選挙も行かないといけないですよね 京都市長選の投票日なんでちょっとこの後
誰に市長になってもらいたいか考えて投票に行こうかなと 思います
それでは
