> Since your CPU is at 100%, there is little that you
> can do in the
> appserver to tune things. I assume you've done the
> recommended things
> for basic glassfish production tuning (using the
> server compiler,
> setting the request-processing threads to a suitable
> value for your
> platform, using proper GC settings) -- if not, look
> for Jeanfrancois
> Arcand or Scott Oaks blogs on that subject.
>
what i meant is that my CPU is 100% when using glassfish and it seems to not scale the memory usage (stays at 50%).
with another server and the same test the cpu is starting at 20% and scaling up til 80% with increase of calls. also the memory gets used up there til 100%.
so i hoped to find a solution to get this behaviour on glassfish too.. but i will check out the blogs that you mentioned.. nevermind.
> But I suspect your bigger issue is with openwebload.
> There are a couple
> of reasons why it may not be the best load generator
> for you. First,
> none of its requests use keepalive, so really what
> you're measuring is
> the speed of the TCP stack on your OS; the TCP stack
> handles the
> connections. You might check various OS groups on how
> to adjust OS
> parameters for a system that accepts lots of
> connections, which may
> improve your CPU usage somewhat.
>
> The second problem with openwebload is that it is a
> single-threaded,
> no-think-time architecture (at least as far as I can
> tell -- though I
> could be wrong about that). If so, it's just like
> Apache's ab load
> generator, which is not really suitable for
> throughput measurements. For
> a full explanation of why not, see
> http://weblogs.java.net/blog/sdo/archive/2007/03/ab_co
> nsidered_h.html
>
> -Scott
ok so i suppose openwebload provides at least ONE interesting value: the average answer time of the server under test.
thanks, greetings,
mario.
[Message sent by forum member 'the666pack' (the666pack)]
http://forums.java.net/jive/thread.jspa?messageID=260916