これは Play framework 2.x Scala Advent Calendar 2013 の 16 日目です。

http://www.adventar.org/calendars/114

今年作ったplay2の社内プロジェクトのscalikejdbc-asyncを使ってパフォーマンスあがったーやったー という結果を書きたかったんだけど盛大になにもしてないので、 いままで作っててはまったところとかをつらつらとまとめることにしました。

前提

そもそもなんのためにこのAPIを作ったかというと各サーバー間で昔から暗黙の了解のように行われていたファイル渡しをやめさせるため。

• どこから送ってきているかわからない。(netstatで地道に確認)
• どこに送ってどこに送り洩れがあるか把握できない。同じようなファイルがたくさんある。
• そもそもどこに配信処理があるか探すのが一苦労。

という状態をやめるためだった。

でそれ以外のAPIもほしいよね、という要望があったのでこのプロジェクトに追加していくことにした。

だいたいroutesファイルを見てみたところ、だいたい30個くらい作ったようだ。

問題未満、xmlファイルのパースに失敗する

完全にplay関係ない問題。 元々のジョブで生成されたxmlファイルがたまにおかしなタグを吐く。 そのためよく読み込みに失敗している。10分更新で1日5回くらい失敗するのだけど、そんなに支障があるファイルではないので放置中。

akkaのチューニングがよくわからない

CPUに負荷がかかりきる前にスループットの上限がくる。 いまだにLAスカスカな状態でアプリケーションサーバーが4台稼働している。 ここはyuroyoroさんも仰っていたけど同期処理をうまくさばけばパフォーマンス改善できるかもしれない。 で、そのためにはscalikejdbc-asyncなどを使ってみようという話。 今回やろうとしたけどできなかった。来年やる。 前やった結果は以下のとおり。

http://wshino.github.io/2013/10/02/scalikejdbc-async/

slick-joda-mapperでbetweenができなかった

解決済み。

tototoshiさんが作ってくださった日付カラムをjodatimeで使えるナイスなプラグイン。 ただ、開発当初に使っていたslick-joda-mapperは0.1.0で、 between句に使うことができない、ということを実装の最後らへんで気がついてしまった。 粛々とカラム定義をorg.joda.DateTimeからjava.sql.Timestampに書き換えていった。 なお、現在の最新版では問題なくbetweenできるようになっているので当初の予定どおりの動きをしている。

slickが吐くクエリがいけてない

mapperは基本的にほとんどlifted embeddingで記述した。 しかし、サービスインしたあとデータ量が増えてきて、JOINしているクエリがえらい遅いことに気がついた。 selectStatementで発行されているクエリを見てみると一度のselectなのにselect句が3つくらいあって吹いた。 具体的にはこの方と同じ状況。

http://jumble-note.blogspot.jp/2013/07/scalaslick-slick.html

複雑なクエリを使いたい場合は最初からplain sqlでいったほうがいいと思う。 slick2でも改善してないぽい。

総評

なんか結局困ったのってDBまわりだった気がする。

それ以外は開発速度はあがるしバグも減るし、for内包も素敵だし

いいパフォーマンスで1.2億req/dayさばけてるから使ってよかった。