java rest services json communication high cpu load on tomcat

[Alessandro Rampazzo]

On a quad core CPU machine with 4 gb ram, tomcat 6 installed, Java 1.6. we have a software who handles as communication gateway. It handles incoming Json messages using jersey (1.19), deserialize and call a client who send the message to another server using jersey (1.19) rest libraries. It handles incoming request from the other server, serialize into json and send outside. With 20 users connected, sending 600 byte of message every 4 seconds. Global cpu consumption reaches 60%. Is it a normal expected behaviour? how we can handle more users?

private String executeToGameEngine(String text, String urlResource){
ClientResponse response = null;
try {
ClientConfig clientConfig = new DefaultClientConfig();
Client client = Client.create(clientConfig);
WebResource webResource = client.resource(urlResource);

response =
webResource
.accept(MediaType.TEXT_PLAIN)
.type(MediaType.TEXT_PLAIN)
.post(ClientResponse.class, text);

if (response == null) {
// error...
}
else if (response.getStatus() != 200) {
// error...
}
return response.getEntity(String.class);
}

We installed visualVM to analyze the problem, any suggestion?

[Tim Holloway]

Welcome to the JavaRanch, Alessandro!

One of the things I always like to do first is to make sure that the Java server isn't itself too big for the machine resources. If you're using Windows, use the Task Manager, if you're using Linux/Unix, use the "top" command. Check to see if the machine is doing a lot of Virtual Memory paging operations. If it is, you'd need the IBM (Install Bigger Memory) solution.

If you have enough memory, then check to see if any other processes are crowding out Tomcat for CPU resources,

If everything is happy at the OS level, then it's time to look at "executeToGameEngine" in detail and see how long it takes to process 1 request and how many requests it's actually being given in a given interval. It's possible that you may need to optiimize the code, but first you need to pin down where the actual trouble lies, and that's best done by detailed measurements, not by optimizing where you "know" it needs optimizing. My experience - and that of others - is that where you "know" is almost never where the real problem is.