fileを開いて、指定行数の分だけ取得するというロジックを作成していたのですが、
そもそもinputが指定行数以上あるかどうかを知りたかったので、そこもうまく取得できるような実装にする必要がありました。
BufferedReaderで最後の値が、nullになるので、null判定を行うことで、実装。
lisp脳なのか、headとtailでばかり考えていたのですが、
initとlastを使えばうまく実装できたので、メモとして。
ちなみに、aの値は以下のようになるのですが、
val a = Stream(1,2,??)
aの値代入が終わったあとでも以下のようにreader.readLine()を呼ぶと、aの値が変わります。
val reader = new Buffered... val a = Iterator... println(reader.readLine()) print(a)
なぜかは完全には把握していないのですが、Iteratorが遅延して評価しており、aの値が確定する前にreader.readLine()を読んでしまうのだろうということが仮説です。
値クラスを使っていて不可解な挙動があったので、まとめたのとその対処法をメモしておきます。
値クラスとはIntやStringが継承しているAnyValを継承させたクラスです。
一つの値しか持ちませんが拡張メソッドを実装できるため、DDDなどを実現するためのドメインモデルの記述に役立つ記法です。
値クラスと汎用トレイト - Scala Documentation
コンパイル時の型は統一されていますが、実行時の型が不定という問題。
上のように、コンパイル時の内部で保持している型は共にAttributesクラス（値クラス）なのですが、
実際に実行してみると、
ということで、非常に不便な状況です。
serverlessconfに参加してきました。
serverlessに関しての知見があまりなかったので、すごい有意義な勉強会となりました。
パネルディスカッションでも盛り上がっていましたが、 Serverlessとは何を指すのか？
実際にCPUなどのリソース管理をしないServerlessと FaaS（Function as a Service）の機能をベースとして構成としてのServerless の２つが議論に上がっていました。
自分なりには、前者に関してはいわゆるマネージドサービスであると思っているので、 後者のものをServerlessの概念として考えています。
Serverless自体が注目されてたのは、AWS lambdaがきっかけです。 AWS lambdaとは、サーバを管理するのではなく、コード（ファンクション）を管理するのみで、デプロイもコードです。 lambdaが呼び出されるたびに毎回起動してファンクションが実行されます。
そのlambdaの登場によってリソース管理が必要なくなります。 今まではサーバにデプロイしていたため、そのサーバの要件に対してリソースが少ない場合、作り直す必要がありました。 しかし、lambdaを利用する場合、リソースに関しては気にしなくてもよいのです。 そう、圧倒的に運用負荷が下がるのです。
www.slideshare.net
上記のスライドを是非見てもらいたいのですが、serverless の思想が示されています
ItoNaoyaさんも言っていましたが、マイクロサービス的観点だと、１サーバに載せる機能は境界づけられたコンテキスト内の内容でした。 しかし上記の思想を取り入れると、lambdaで担保するものは１機能になっていきます。
現状のlambdaでは、以下のデメリットがあります。
薄いサービスならば作成できると思いますが、全てをserverlessで置き換えることはまだまだ難しそうです。 そもそも、その要件が満たせる状況になっても置き換えるかというのは疑問です。 というのも、複雑なビジネスロジックであればあるほど、コードとして再利用がし辛くなり抽象化ができなくなってしまうからです。
では、対応例として考えられるものは
serverlessという単語自体が曖昧な単語となってしまって、実際バズワードにもなりそうですが、 今後一つの潮流として、素早いサービスを作る上で絶対に避けて通れない考え方だと思います。
サービスを作る際に、serverlessも一つの手法の対象として考えれるようにキャッチアップしていく必要がありそうです。
sprayフレームワークを使っていると、HTTPリクエストの部分はspray-canを利用すると思います。
しばらく、spray-canを使っていたのですが、いくつか重い処理を走らせるとCPUを使い切っていないのに、sprayがリクエストを受け付けなくなってしまい、502 BadGateway を出すようになってしまいました。
そこで色々試したのですが、結果として設定のconfをいじるのではなく、responseを非同期にすればできました。
負荷をかけると以下のような connection reset by peerという502エラーが発生しました。
read: connection reset by peer
application.confを色々いじってみましたが、結局実装が間違っていたため、根本的なパフォーマンスは変わりませんでした。
spray/application.conf at master · spray/spray · GitHub
が、本家のベンチマークに使っているconf設定です。
sprayのconfは、
以下のようにいじりました。
spray-stress/application.conf at master · moc-yuto/spray-stress · GitHub
が計測してもパフォーマンスは変わらず。。。
FutureDirectiveを使うことでした。
使い方は、
spray | Documentation » 1.2.2 / 1.3.2 » spray-routing » Predefined Directives (by trait) » List of predefined directives by trait » FuturesDirectives » onComplete
です。
レスポンスにFutureを組み込むことで、502エラーが発生していたものが一切発生しなくなり、パフォーマンスを一気にあげることができました。
負荷にはvegetaを使用しました。
https://github.com/tsenart/vegeta
vegeta attack -rate=100 -duration=30s -targets=st.txt > st.bin #st.txt GET http://localhost:8080/st
Get http://localhost:8080/st に対する結果
Requests [total, rate] 3000, 100.03 Duration [total, attack, wait] 44.486880886s, 29.989999801s, 14.496881085s Latencies [mean, 50, 95, 99, max] 7.155629141s, 4.389581282s, 22.700462005s, 30.001109336s, 30.003361727s Bytes In [total, mean] 0, 0.00 Bytes Out [total, mean] 0, 0.00 Success [ratio] 0.00% Status Codes [code:count] 0:3000 Error Set: Get http://localhost:8080/st: dial tcp 0.0.0.0:0->[::1]:8080: getsockopt: connection refused Get http://localhost:8080/st: dial tcp 0.0.0.0:0->[::1]:8080: i/o timeout
Get http://localhost:8080/st2 に対する結果
Requests [total, rate] 3000, 100.03 Duration [total, attack, wait] 43.215084995s, 29.989999893s, 13.22508510 2s Latencies [mean, 50, 95, 99, max] 6.767752449s, 2.182035276s, 30.002461808s , 30.005316637s, 30.074779909s Bytes In [total, mean] 30691, 10.23 Bytes Out [total, mean] 0, 0.00 Success [ratio] 31.10% Status Codes [code:count] 200:933 0:2067 Error Set: Get http://localhost:8080/st2: dial tcp 0.0.0.0:0->[::1]:8080: getsockopt: connection refused Get http://localhost:8080/st2: EOF Get http://localhost:8080/st2: read tcp 127.0.0.1:54219->127.0.0.1:8080: read: c onnection reset by peer Get http://localhost:8080/st2: read tcp 127.0.0.1:54217->127.0.0.1:8080: read: c onnection reset by peer
以上のような結果になりました。
さらにパラメータをチューニングした値は、また別途検証したいと思います。
負荷を受けさせたソースはこちら
github.com
