Though it was NOT related to SOAP web services, I've done some pretty
extensive performance testing of Glassfish so I'll throw in my
subject-to-verification by Glassfish experts 1/2 cents here:
I believe you are correct in that 500 is the max for http request processing
threads.
But how those threads behave and how many you should use is dependent on
which connector you are using as well as your OS to some degree.
Assuming you are using the defaul (non-blocking Grizzly) connector, you will
probably never require anywhere near 500 threads and it may be counter
productive to specify that many. The magic of NIO from a server perspective
is it doesn't lock up a thread while a request is in a processing / wait
state. That's in contrast to a standard request-per-thread "blocking"
servlet container that allocates a thread to each request for the entire
lifetime of that request. So for Tomcat, you may very well see much better
performance with 500 threads. But with NIO (and this probably won't be a
great explanation but): request A comes in and is assigned to Thread 1.
While the servlet container is composing the response for request A, there
is nothing for thread 1 to really do. So NIO allows Thread 1 to be assigned
to process some other request B and then later Grizzly can come back with
that thread (or some other one) to send the response for request A when it
is ready to be sent.
That being said, at least on Windoze the general rule I've seen for Grizzly
/ NIO is you should start with between 2 and 4 request-processing threads
per core on your server and then tune from there in small thread increments.
So if you have a 4 core CPU, that with either 8 or 16 request processing
threads and slowly add more until CPU is as maxed out as you can get it.
I haven't personally tested on anything other than Windows but I believe
it's beneficial to use more threads to start on *Unix
If you want Glassfish to behave more like Tomcat by using a
thread-per-request connector, you can adjust your domain.xml such that
blocking=true for your HTTP listener. You can also swap out the Grizzly
connector for Coyote 1.1 as well but that's generally not going to give you
better performance. In both those scenarios, you would probably benefit from
using much higher request processing thread counts.
Hope this helps... If you Google glassfish performance and you should see
some good presos / white papers on performance tuning.
On 7/10/09 3:49 AM, "pccontact" <pccontact168_at_gmail.com> wrote:
>
> Dear all,
>
> I found that is the max. HTTP Thread-Count is 500?
>
> Can I increase that value to more than 500?
>
> I have a SOAP application. In Glassfish, each request from the client will
> need about 1-4 seconds to handle user request which mainly send another SOAP
> request to the server not in my domain. That means I have no control over
> the response time from the other server.
> As far as I know, each request from my client will use a HTTP worker thread
> to process the request then the thread is locked until it complete the
> process.
>
> Am I right?
>
> Then the max. throughput is depend on the Max. HTTP Thread Count, right.
>
> Interesting thing happened, I increased the HTTP Max. Thread-Count to 1000
> then the max. responsed thread looks like exactly 500.
>
> Can anyone tell me how to increase the value?
> Do I misunderstand this?
>
> Thanks!!
--
Sean Comerford, Software Engineer
ESPN.com Site Architecture Group
Office: 860.766.6454 Cell: 860.951.6973