|
Replies:
1
-
Last Post:
Jul 12, 2009 6:26 AM
by: pccontac168
|
|
|
|
|
|
|
Dose Glassfish each SOAP request use one HTTP Thread to handle the
process?
Posted:
Jul 12, 2009 5:36 AM
|
|
|
Dear all,
In my SOAP application, it looks like that each request from the client will
use one HTTP thread even
the NIO is the nature of the Glassfish.
If in my SOAP process wait for some period of time, the thread will not
relase for another incoming request even in NIO, right?
Can anyone explain about this for me?
Thanks!
--
View this message in context: http://www.nabble.com/Dose-Glassfish-each-SOAP-request-use-one-HTTP-Thread-to-handle-the-process--tp24448226p24448226.html
Sent from the java.net - glassfish users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
Re: Dose Glassfish each SOAP request use one HTTP Thread to handle the process?
Posted:
Jul 12, 2009 6:26 AM
in response to: pccontact
|
|
|
As I found this message
Tune the HTTP threads
As you know, there are two parameters here: the HTTP acceptor threads, and the request-processing threads. These value have unfortunately had different meanings in a few of our releases, and some confusion about them remains. The acceptor threads are used to both to accept new connections to the server and to schedule existing connections when a new request comes over them. In general, you'll need 1 of these for every 1-4 cores on your machine; no more than that (unlike, say SJSAS 8.1 where this had a completely different meaning). The request threads run HTTP requests. You want "just enough" of those: enough to keep the machine busy, but not so many that they compete for CPU resources -- if they compete for CPU resources, then your throughput will suffer greatly. Too many request processing threads is often a big performance problem I see on many machines.
How many is "just enough"? It depends, of course -- in a case where HTTP requests don't use any external resource and are hence CPU bound, you want only as many HTTP request processing threads as you have CPUs on the machine. But if the HTTP request makes a database call (even indirectly, like by using a JPA entity), the request will block while waiting for the database, and you could profitably run another thread. So this takes some trial and error, but start with the same number of threads as you have CPU and increase them until you no longer see an improvement in throughput.
**********
The later part said each HTTP request need a thread to handle it.
The above message from
http://weblogs.java.net/blog/sdo/archive/2007/12/a_glassfish_tun.html
Can anyone help me to clear this?
Thanks.
|
|
|
|
|
java.net RSS
