Thanks for the details, Radim - This is going in the right direction in
terms of specifics of your feedback. Much appreciate your taking time
out to write up these.
I have more comments below.
On 10/27/11 3:24 PM, Radim Kolar wrote:
>
>> Have you filed issues in the GlassFish community JIRA
>> (http://java.net/jira/browse/GLASSFISH) so issues you see with
>> GlassFish can be fixed ?
> no.
>
> i will give you simple example:
>
> slush# ab -c 200 -n 1000 http://www.filez.com/index.jsp\?q=karman
> This is ApacheBench, Version 2.3 <$Revision: 655654 $>
> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
> Licensed to The Apache Software Foundation, http://www.apache.org/
>
> Benchmarking www.filez.com (be patient)
> Completed 100 requests
> Completed 200 requests
> Completed 300 requests
> Completed 400 requests
> Completed 500 requests
> Completed 600 requests
> Completed 700 requests
> Completed 800 requests
> Completed 900 requests
> apr_poll: The timeout specified has expired (70007)
> Total of 910 requests completed
> slush#
> first about 900 requests are completed really quickly, then glassfish
> hangs for about 2 minutes. After it recovers, it never runs again on
> normal speed. it runs very slowly (about 100 timers slower).
Do you know for sure here that there is something in GlassFish that is
contributing to the issue? It could be application code written in a non
scalable fashion as we have seen in some customer deployments.
What would help here is a JIRA issue along with a set of jstack thread
dumps before and after the hang starts to happen.
>
>> This will make your feedback more actionable for us to work on.
>>
>> You've mentioned v2 and v3 - could you be specific about the versions
>> you have used?
> glassfish V2 UR1, 3.1.1
And the issues you have shared today are all on both of these releases
consistently? If not, it would help to isolate which one of these
releases has these issues. It would obviously be easier to put in fixes
on latest releases and for older releases, the sustaining support for
paid customers is the route to take.
>>>
>>> glassfish - server monitoring sucks,
>>
> 1.
> often if you set monitoring to LOW, you get no usable output which is
> kinda confusing. for example in JDBC pool, web container, connector
> service, http server and such. So it must be set to HIGH for doing
> something.
> 2. there is no ability to graph counters. Look at geronimo 2.2, you
> can select some counters and put them into graph. set monitor interval
> every 5 minutes and you will see graph for few days back. Its
> acceptable monitoring. You can download websphere 7 for developers and
> explore its monitoring, its really very nice stuff there.
>
> 3. no ability to reset monitoring counters (such as high watermarks).
>
> 4. better visual presentation of collected values in console. click to
> open section is difficult to navigate. Make toolbar on top or left
> side to choose section.
>
> 5. some counters are in some cases bad: (too high)
>
> MaxTime 1318697985767 millisecond Oct 15, 2011 6:59:45 PM Oct 15,
> 2011 7:18:17 PM -- Maximum response time
> ProcessingTime 4063784441 millisecond Oct 15, 2011 6:59:45 PM Oct
> 15, 2011 7:18:17 PM -- Average response time
> ServiceTime 5274792204777 millisecond Oct 15, 2011 6:59:45 PM Oct
> 15, 2011 7:18:17 PM -- Aggregate response time
> ErrorCount 0 count Oct 15, 2011 6:59:45 PM -- -- Number of error
> responses (that is, responses with a status code greater than or equal
> to 400)
> RequestCount 1298 count Oct 15, 2011 6:59:45 PM Oct 15, 2011
> 7:18:17 PM -- Number of requests processed
>
>
>
>> What would you like to see ? Could you share some insights into what
>> would constitute good monitoring capability in your view and file
>> enhancement requests in JIRA?
> take a look at Geronimo or Websphere to check how their monitoring
> output looks like.
Thanks for the feedback.
>>
>>
>>> but GUI for cluster management is great help, almost all WARs runs
>>> out of box. update tool is really nice stuff, performance is better
>>> then geronimo, stability is not very good, scheduled restarts are
>>> required for improving server health.
>>
>> It would greatly help to know specifics of the issues you are seeing
>> - are restarts required because of heap exhaustion, high CPU
>> utilization, perm gen issues, deadlocks ?
> perm gen issue after few app redeploys (all app servers are doing
> that), deadlock, sometimes it just runs slowly but not due to full
> heap or high cpu, it seems to wait for some timeout in connector. i am
> not aware of memory leaks in G 3.1.1
Many of such perm-gen issues on deploys were resolved in 3.1.1 - if you
still see these, you should file issues so we can fix it.
Slowness of an app on GF can have so many causes including db level
locking, or application thread contention, something in GF, et al so
each issue of slowness needs to be analyzed - without any logs,
diagnostic data such as jstacks and an issue to track its hard to pin
point and fix all issues. So I request you to take one step further and
help us by filing such issues as you see them.
>> so-so documentation,
>> What do you see lacking? I request you to please give us specifics.
> for example. how to import existing private key + certificate
> how to use JMS from apps running outside glassfish and how to
> authentificate users
Good feedback. Thanks a lot.
Shreedhar