 |
Forums |
Admin  Start New Thread
By: Vivek Pandey
 RE: Concurrent Request Handling [ reply ]
2010-01-28 19:29
|
|
Wondering if you can provide profiler data that where the time is spent. Otherwise, can you attach your testcase? Better report an issue and attach a testcase there. I would need to profile to see where/why the time is deteriorating with incoming requests.
|
By: Vivek Pandey
RE: Concurrent Request Handling [ reply ]
2010-01-28 19:21
|
Can you increase grizzly thread pool size? Grizzly is the HTTP NIO layer and the default max is 5. Look in glassfish.yml.
#Maximum number of threads in the threadpool servicing
#requests in this queue. This is the upper bound on the no. of
#threads that exist in the threadpool.
max-thread-pool-size: 5
-vivek.
|
By: Ken D
Concurrent Request Handling [ reply ]
2010-01-28 19:14
|
We are running a Sinatra app under the latest Glassfish gem. I have these remote processes that send it requests ever 10 seconds. So in a given minute I see 6 requests per remote process. It takes < .5 second to handle these requests.
As the remote processes go up, the app starts crawling. I find that with 5 remote processes connecting, the log shows them being processed every 23 seconds, not 10!
If I up the jruby-runtime-pools to a min/max of 5 or so, everything works fine again with the requests being processed at their incoming rate of 10 seconds.
I don't understand why these very quick requests are process so slowly. Nothing else is accessing this app. Is there a way to fix this (beyond giant jruby-runtime-pool values)? I would hope we could handle hundreds of such devices.
|
|
|
