Re: Unexpected low CPU usage

Johan Stuyts wrote:
> The amount of data going back and forth is small (approx. 250 KB per
> second when running the RMI client), so the whole thing should be
> CPU-bound: marshalling, unmarshalling, authorization, etc.
>
> I attached a graph showing the CPU utilization. I hope it gets through. If
> not, you can download it here:
> http://download.cl1p.net/johanstuyts/

I didn't find anything there.

>
> The first bump is from RMI, the second and third are from XML-RPC and the
> last two are from SOAP. They all do 11,000 roundtrips. The tests were run
> on a dual core processor. You can clearly see at least one core is busy
> all the time while the RMI and XML-RPC clients are running. In my opinion
> the correct behavior should be that the same SOAP CPU usage is spread over
> less time so one core is constantly busy too.

Since I can't see it, I can't clearly see it.

However - one core is fully loaded - okay, that really points to a big
point, doesn't it? Is the CLIENT multi-threaded?

Why don't you just fire up 100 clients, and see if the box goes to 100%
then? Why not load it both internally and externally (from another
physical box), preferably with _several_ external boxes? That's my idea
of fun, at least: load it till DIES, and try to pull some information
out of that.

>
>> When client and server are on distinct boxes, you must make sure there
>> aren't any hiccups on the line - see to that it is full duplex 1 Gbps
>> links, so that both throughput is super, and latency is nil.
>
> I understand that I need multiple clients and/or a very good network if I
> want the CPU to be used fully on the server when the clients and the
> server are on different hosts. But I can't get it to go to 100 % when
> running on the same host.

Again: if the client (or server) is "single threaded", or at least
single-access in some way (it waits until reply before posting a new
request), you will of course never get two CPUs loaded 100% - you'll
maybe even have a hard time filling one CPU, since there will inevitably
be _some_ IO bound (not-CPU-loading, e.g. lag) elements in there per
request/response round trip. (Or maybe not if this is done fully in the
OS, that is, nothing goes out on any wire, and hence there aren't
actually any CPU-waiting moments in a request/response roundtrip - but
that will just fill one CPU at any rate).

>
>> See how much you manage to pull through the thing (scale up the load).
>>
>> You should measure lag - are the responses coming steadily very fast?
>> When the response times starts to climb (exponentially), you've hit some
>> roof - if the CPU at that time still isn't 100%, you've got some other
>> bottleneck - maybe some very bad synching or something..?
>
> I thought about locking and synchronization but the whole thing is
> basically single-threaded as a single thread is running in one client.

You didn't answer the question (or do what I told you there)!

And btw, here you even state "single threaded" - is it really this obvious?

Endre.

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com