Playframework线程池

Question

I'm profiling a playframework 2.2.3 application with YourKit to try and troubleshoot some performance issues. This is not my application and I am not familiar with play 2. The application is a multi-player social game that utilises web sockets. It runs on Amazon EC2 m3.large

What I can see in the profiler is that the game play logic (begun by web socket calls) is carried out in 1 of 2 threads in play-internal-execution-context. Some of the routines involve I/O and there is some blocking going on due to method synchronization in parts. There is a pool of threads named play-internal-execution-context but only two are ever in use at anytime. Activity is moved to new threads from time to time and I can see right now the thread names in use are play-internal-execution-context-600 and 601.

I can see in the play docs

Play Internal Thread Pool - This is used internally by Play. No application code should ever be executed by a thread in this thread pool, and no blocking should ever be done in this thread pool. Its size can be configured by setting internal-threadpool-size in application.conf, and it defaults to the number of available processors.

As I can see stack traces in the threads that involve application code is this likely that the developers have an incorrect design, or, is this just because of the async nature of the framework that the code is actually just executed by play in these internal threads?

All the best

Jon

Answer 1

Please make sure that you are not running blocking code inside onReady callback method of WebSocket. Any blocking or heavy computation should be offloaded to some other thread pool (use promise or actor).