書くこと一杯。。取り合えずokuyama-0.8.0のことから

相当ここをサボってしまいました。
書くこと一杯あるんですが(gumiさん勉強会でしゃべりましたとか、OSC東京とか)、
取り合えずokuyamaの0.8.0のことを書きます。




前回0.7.0をリリースしてから2ヶ月半以上開発したのですが、それまでは
もっと短期間にリリースを繰り返していたのですが、今回はすこし時間をかけました。


一番時間を使ったのはネットワークI/O部分。
従来okuyamaは接続がある都度スレッドを生成して1対1の通信をクライアント、マスターノード、
データノード間で行っていました。
これは少ない同時接続数(100とか200程度)の間は特に問題なくレスポンスも出ていたのですが、
同時接続数が増えるに従って動作不良を招きます。
当然スレッド数に依存するので、同時接続1万とか無理です。
これは何とかせねばということで改造にとりかかりました。


でも実は自宅のAMDの2Coreのデスクトップではもっと顕著で、このマシンでokuyamaの
全ノードを動かしている状態で2クライアントでget、setを繰り返している状態で、
3クライアント目は接続できませんでした。2クライアントでCPUを100%使い果たしてしまい、
3クライアント目のスレッドが生成できなかったんです。


そして試したのが、Javaのnioです。
従来はただのioを使用していたので、ブロッキングI/Oです。
これだとクライアントが通信を始めてなくても、コネクトがあった瞬間に
スレッドが待ちになるので、よろしくないです。
nioはなにか通信イベントが発生するたびに、通知してくれます。
もうこれだなってことでテスト実装したんですが、最終的に思ったほど
性能がでませんでした。同時接続数1万且つ、接続完了クライアントから、
処理開始をテストしていたんですが、僕の実装がいけてなかったんだと思います。。


それで良くないとわかっていたのですが、ioを使用して多段式のI/O受付を
実装しました。クライアントからの通信状況を監視するスレッドと、実際に
処理を行うスレッドを分割し、さらにこれにQueueを使用して並列化しました。
これで一応1万クライアントで同時接続して処理を行うことができました。
ただ、やはり1万同時接続時は性能が低下するので、まだ改良の余地はあるかと。
その前にnioに再チャレンジするのも手かもしれませんが。


後は、ConsistentHashをサポートしたり、データノードのレプリケーション数を
3ノードに出来るようにしたり、取得時のデータ一貫性をサポートしたりと、
色々いじりました。




最低限入れたい機能は取り合えず入ったイメージです。
最近okuyamaを色々な場所で紹介させていただいていて
色々ご意見をいただけているので、その声を元に機能拡張して
いこうかと思っています。
次のバージョンで早速その1部を実装してリリースします。