Skip to main content

wanting to confirm appserver behavior...

1 reply [Last post]
Anonymous

I just want to confirm if what I'm seeing is the expected behavior....

While running load tests, I see each user locking a thread for
com.sun.enterprise.web.portunif,PortUnificationPipeline,
eg: 400 users logging in and out, I will see these 396 of these in
either BLOCKED or WAITING state:

"httpSSLWorkerThread-8080-67" daemon prio=3 tid=0x0000000004fba000
nid=0xd9e in Object.wait() [0xfffffd7e9823a000..0xfffffd7e9823aa10]
java.lang.Thread.State: *BLOCKED * (on object monitor) at
java.lang.Object.wait(Native Method) - waiting on
<0xfffffd7ebc020f60> (a
*com.sun.enterprise.web.portunif.PortUnificationPipeline*) at
java.lang.Object.wait(Object.java:502) at
com.sun.enterprise.web.connector.grizzly.LinkedListPipeline.getTask(LinkedListPipeline.java:291)
- locked <0xfffffd7ebc020f60> (a
com.sun.enterprise.web.portunif.PortUnificationPipeline) at
com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:107)
Locked ownable synchronizers: - None
[att1.html]

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Scott Oaks

Yes, that's the expected behavior -- those threads are waiting for work.

You probably don't need 400 of them :-) If you consistently see 396 of
them blocked as a result of calling getTask(), then it means you are
only getting 4 simultaneous requests into the appserver from your load
test. Note that "simultaneous" means just that -- it doesn't mean that
you have 400 users logged in and making a request every few seconds (or
even every few milliseconds); those requests are then not simultaneous.

Even if you have sufficient client hardware to drive 400 simultaneous
requests (which likely means 400 CPUs on your client hardware, given
that load generators usually make synchronous, blocking calls), you
probably don't want that many threads on the server, because they will
just compete for CPU resources on the server, and the thread context
switching will be quite inefficient. Try with about 1-2x the number of
CPUs of your server, depending on whether your app uses a backend
resource or not (with no backend resource, use closer to 1x threads).

-Scott

On Mon, 2008-12-08 at 17:14, Russ Petruzzelli wrote:
> I just want to confirm if what I'm seeing is the expected behavior....
>
> While running load tests, I see each user locking a thread for
> com.sun.enterprise.web.portunif,PortUnificationPipeline,
> eg: 400 users logging in and out, I will see these 396 of these in
> either BLOCKED or WAITING state:
>
> "httpSSLWorkerThread-8080-67" daemon prio=3 tid=0x0000000004fba000
> nid=0xd9e in Object.wait() [0xfffffd7e9823a000..0xfffffd7e9823aa10]
> java.lang.Thread.State: BLOCKED (on object monitor) at
> java.lang.Object.wait(Native Method) - waiting on
> <0xfffffd7ebc020f60> (a
> com.sun.enterprise.web.portunif.PortUnificationPipeline) at
> java.lang.Object.wait(Object.java:502) at
> com.sun.enterprise.web.connector.grizzly.LinkedListPipeline.getTask(LinkedListPipeline.java:291) - locked <0xfffffd7ebc020f60> (a com.sun.enterprise.web.portunif.PortUnificationPipeline) at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:107) Locked ownable synchronizers: - None

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net