dev@glassfish.java.net

Re: Glassfish Tuning

From: Scott Oaks <Scott.Oaks_at_Sun.COM>
Date: Thu, 31 Jan 2008 10:13:48 -0500

Assuming that you have tuned the thread pools correctly (and it sounds
like you've looked at that), then something is causing a bottleneck. It
sounds almost like there's some sort of deadlock between your client(s)
and server.

One easy trick to find this is to make sure that you're using JDK 6
(6_04 is best), and then to use the JDK 6 jstack command to get the
stack of the appserver. [You can use various tools, including asadmin,
to get stack dumps, but jstack will be fastest.] If threads are all
blocking on a resource or something, you can usually tell from the
stack dump: all of the GrizzlyWorkerThreads will be doing something
other than calling waitForIoTask (or a similarly named method, depending
on which precise version you're running).

You can send me a stack dump if you have questions about it.

-Scott

On Wed, 2008-01-30 at 18:57, William Saxton wrote:
> Hi all,
>
> Since the EJB issues I was having earlier appear to be due to a known
> bug, I've switched over to using a Web Service to handle my application
> server needs. The usage is the same, I have about 700 clients accessing
> an application server, every 5 minutes, so around 3-4 clients will be
> accessing it every second.
>
> It takes less than 1 second for a client to send the web service the
> XMLified data, the application server to save the data to about 80
> different files, and for it to return an "ok". When I turn on all of
> the clients, though, it takes anywhere from 10 seconds to over 5 minutes
> (which I timeout) for the request to be completed.
>
> I've tried these JVM tweaks:
> http://weblogs.java.net/blog/sdo/archive/2007/12/a_glassfish_tun.html
> as well as setting the HTTP acceptor threads to 16 and
> request-processing threads to 16. These don't seem to have done
> anything. There is very little CPU usage (~90% idle) and little local
> disk I/O (where the data is saved) so I don't know where the bottleneck
> is. I'm wondering whether the application server is simply queuing up
> too many of the client requests when it could be handling more.
>
> Anyone have an ideas? Since I'm internal to Sun, I can always give
> someone access to the app server if they wanted to do a quick glance.
>
> Thanks.
>
> -Bill
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>