2013-07-08 5 views
5

私はPlayフレームワーク2.1を使用してアプリケーションを開発しています。それは非常に使いやすいフレームワークです。私はすぐに私のアプリを開発することができます。しかし、いくつかのスケーラビリティの問題もありました。 Play 2.1は主張されているほど速く動作しないようです。多分私はパフォーマンスを調整することを知らなかったからです。プレイフレームワークアプリケーションのスケーラビリティをチューニングする方法は?

私の問題は次のとおりです。自分のメールでユーザーにログインするAPIがあります。

パフォーマンスを使用するためにApache Benchmark(ab)を使用しました。 1回のリクエストで約230msかかります。 5つの同時要求がある場合、応答時間はまだ十分に速く、約280msです。

Concurrency Level:  5 
Time taken for tests: 0.306 seconds 
Complete requests:  5 
Failed requests:  0 
Write errors:   0 
Total transferred:  3495 bytes 
Total POSTed:   1065 
HTML transferred:  3135 bytes 
Requests per second: 16.34 [#/sec] (mean) 
Time per request:  306.009 [ms] (mean) 
Time per request:  61.202 [ms] (mean, across all concurrent requests) 
Transfer rate:   11.15 [Kbytes/sec] received 
         3.40 kb/s sent 
         14.55 kb/s total 

Connection Times (ms) 
       min mean[+/-sd] median max 
Connect:  1 1 0.1  1  1 
Processing: 280 290 13.8 292  305 
Waiting:  278 288 13.7 291  304 
Total:  280 291 13.9 293  306 

ただし、100件の同時リクエストを使用した場合、非常に悪い結果を得ました。

Concurrency Level:  100 
Time taken for tests: 4.243 seconds 
Complete requests:  100 
Failed requests:  0 
Write errors:   0 
Total transferred:  69900 bytes 
Total POSTed:   21300 
HTML transferred:  62700 bytes 
Requests per second: 23.57 [#/sec] (mean) 
Time per request:  4243.058 [ms] (mean) 
Time per request:  42.431 [ms] (mean, across all concurrent requests) 
Transfer rate:   16.09 [Kbytes/sec] received 
         4.90 kb/s sent 
         20.99 kb/s total 

Connection Times (ms) 
       min mean[+/-sd] median max 
Connect:  1 62 31.5  83  89 
Processing: 996 3744 544.7 3902 4146 
Waiting:  995 3727 542.0 3894 4146 
Total:  1084 3806 542.6 3968 4204 

私のサーバーマシン:Intel i7,8コア、2.8GHz、8GBのメモリ。私は、プレイフレームワークのデフォルト設定を使用しました。誰でもプレイフレームワークのパフォーマンスを調整する方法を知っていますか?

私はそれがスレッドプールサイズに関係すると思います。このドキュメントでは、プレーのデフォルトのスレッドプールサイズが#コアであるとしています。その場合には、すべての100の要求を処理するための予想時間は次のとおりです。

ので
230ms * (100/8) = 2875ms 

、私はデフォルトのスレッドプールのサイズを増やす必要がありますか?しかし、この文書では、プールのサイズが#コアに等しいときに最高のパフォーマンスを得るべきだと述べています。

また、Netty(プレイのWebサーバー)スレッドプールサイズはパフォーマンスに影響しますか?私はそのデフォルト値に関する情報を見つけられませんでした。誰がどのように構成されているのか知っていますか?

ありがとうございました!

+0

パフォーマンスの代わりにスケーラビリティをターゲットにしているようです。パフォーマンスに関しては、IMHO 230ms/reqもそれほど速くないので、私はこれが何の理由であるかを調べるでしょう。あなたはほとんどの時間を取っている何か手掛かりがありますか?バックエンド呼び出し、アプリ固有の計算、またはテンプレートレンダリング? – MartinGrotzke

+1

'play start'を実行して、PRODモードでの再生に対してベンチマークを行っていることを確認してください。 DEVモードには自動リロードのオーバーヘッドがあります。 –

答えて

6

Playのデフォルトのスレッド構成は、非同期APIを使用するアプリケーション用に設計されています。

多くのブロッキングコール(通常は "標準" JDBCデータベース呼び出し)を行う場合は、デフォルトのThreadPoolを調整するか、別の構成のThreadPoolでDB呼び出しを実行する必要があります。

これらのメカニズムをすべて理解するには、Play FrameworkのドキュメントのThread Poolsセクションをお読みください。それはこの主題に関して非常に有益な情報を含んでいます。

0

-Xmx32000mたとえば、32GBのヒープメモリでJVMを実行します。

-Xmx256mはデバッグモードのデフォルトです。サーバーのRAMメモリ空間内でどれだけ拡張するかに合わせて変更することができます。マシンのI/Oレートに応じて、ガーベジコレクションのサイクルは、クリーニングが必要な場合は一時停止のように見えるかもしれませんが、通常は〜20msで、アプリケーションの目的によっては目立たない場合があります。

関連する問題