systemctl restart mysql.service
すると設定が無効になる僕らが高速化したのはRuby実装です。
まずは定石、SQLのslow_queryが何なのかの調査をはじめました。
しかし、何度mysqlのconfigファイルにその設定を有効化した記述をしても、systemctl restart mysql.service
すると無効状態に戻ってしまうので、
なんだかわからないままrestartは諦めました。(そもそもrestartするのも正しかったのか……?)
結果として、stars
テーブルのkeyword
、entry
テーブルのkeyword
、user
テーブルのname
にindexを張った他に、content_length(keyword)
としていた部分を
keyword_length
に値を格納してそこを見に行くようにアプリを変更したりするなどを行いました。
isuda
とisutar
の2つのsinatra appが相互に通信を行っており、この部分がボトルネックになるのではないかと考えました。
そこで2つのappとdbをまとめてしまいましたが、効果の程はわかりません。(この改善で一瞬だけスコアが0以上を返しました。たしか160から180くらいでした。)
public
以下の静的なファイル群はnginxが返すように変更しました。
存在するkeywordはそのkeywordのurlへと置き換える実装がありました。その中で、一度keywordをSHA-1で置き換える部分があったのですが、それをZlib.crc32
に置き換えて高速化を狙いました。
ただ、おそらくはアルゴリズムの改変もしくは結果のキャッシュ化を行えたほうが良かったのではないかと思います。
完全に気休めでした。
RACK_ENV
をdeploymentにunicornはRACK_ENV
をdeploymentかdevelopment以外は無視するので、アクセスログを見るためにproductionになっていたのをdeploymentにしました(thx kirikiriyamama!)
RACK_ENV
とsinatraの環境は分離させることができて、sinatraのenvironment
をproductionにすることで高速化できたようです。ただproductionのままだとunicornでログを見ることができないので、いずれにせよこの値はdeploymentにし、sinatraのenvironmentをproductionにすべきでした。
descriptionとkeywordそれぞれでスパム判定している部分を、それらを結合した文字列に対してスパム判定を行うようにしました。
/register
へはGETもPOSTもされていないので、エンドポイントごと削除しました。これやる意味あった?
unicornとnginxとの通信にunix domain socketを使用するようにしました。
またそれに限らずnginxまわりのチューニングは全部kirikiriyamamaさんに任せたので、これ以上のことをやってたかもしれません。
ユーザー名とパスワードは同一のものが使用されているので、パスワードの暗号化処理をやめて平文で保存するようにしました。
/login
の静的ページ化/login
のGETは完全に静的ページを返せるので、そのようにしました。
とにかく、スコアが0のまま放置していたのが一番の反省かと思います。どのような改善を試行しても、それによって性能が良化したのか悪化したのかが判断できないからです。
競技中間、確か14時頃からはずっと/login
、/star
、/keyword
へのPOSTがタイムアウトする原因を探っていました。アクセスログを見る限り、499が返っているのですが、手元ではmsec単位でresponseが返ってくるので本当に謎でした。それらのPOST requestは終了後に/
へリダイレクトするのですが、この/
へのアクセスが重いのでタイムアウトするのではないかと予測もしたのですが、それでは「POSTがタイムアウトする」というベンチマーカーのメッセージへの答えにはなっておらず、本当にうんうん唸ってそのまま終わってしまいました。
次回も参加したい!!!!!!!!