Tuning Message.get*Property(String)?

View: New views
2 Messages — Rating Filter:   Alert me  

Tuning Message.get*Property(String)?

by Dirk Grosskopf :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

All

I'm coding a simple message consumer that is registered via onMessage() hook.

The basic message processing is to parse the incoming messages and extract certain message properties (17) and writes them into a file.

Currently I can consume 400.000 messages in 20 seconds with a single instance. Not too bad, but a timer (using System.nanoTime() to count the processing time for each message) has shown that the sequence of get*property(String) takes nearly 50% of the total processing time. Another problem is, that the consumer produces too much load (two out of 8 cores)

When writing the message directly via MessageImpl.writeContent(..) to the file, the message processing time is less that 2 seconds.

- We are using a 7.4.0 router. There is no real difference between 5.2.5 or 7.4.0 for the swiftmq.jar
- The test machine is a 2 x Intel quad core Linux machine with RAID disks and 32 GB ram
- There is no difference when simply invoking the get*Property() methods, without using the result

Is there any way to tune the get*Property calls?

Re: Tuning Message.get*Property(String)?

by IIT Software :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

The properties of a message as well as the message body and all strings of the message are in a byte stream format upon receive of a message. The property byte stream is converted into a Map with name/value of the properties. This is done on the first call to getXProperty(name). Subsequent calls will use the Map and will just do a lookup with a conversion to the resp. property type, e.g. from Integer to int. That' all. So if you measure, you should differ between the first and subsequent getXProperty calls.

The reason why MessageImpl.writeContent [our internal serialization] is faster is simple - it just writes the byte streams of the message (props, body, strings).

Concerning consumer produces too much load. There are 2 threads involved. One is reading from the TCP input stream, deserializes and dispatches it into the appropriate session queue which is served from another thread which then calls onMessage.