History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: AMQ-1689
Type: Improvement Improvement
Status: Closed Closed
Resolution: Fixed
Priority: Minor Minor
Assignee: Hiram Chirino
Reporter: Gary Tully
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
ActiveMQ

(NIO)DataFileAppender does to many sync or force calls when there is little or no concurrency

Created: 25/Apr/08 06:13 AM   Updated: 01/May/08 02:18 AM
Component/s: Message Store
Affects Version/s: 5.1.0
Fix Version/s: 5.1.0

Time Tracking:
Not Specified

File Attachments: 1. Text File Licensed for inclusion in ASF works fileAppenderBatch.patch (27 kb)

Environment: Windows, NIO force and File sync perform poorly

Patch Info: Patch Available


 Description  « Hide
Where NIO channel force and fileDescriptor.sync perform poorly and there is little concurrently, the kaha DataFileAppender performs poorly.
A test case where a single producer and consumer operate from either ends of a networked pair of brokers shows the problem. It takes ~3 minutes to send 1000 messages on windows!. The problem is that 70% of the time is spent in NIO channel.flush()

The flush is batched if there are concurrent writes, but otherwise, a single write is flushed immediately.
My proposal is to have the batch processor batch till a batch is full or till a sync flag is present in a write command or till some timeout expires or if the appender is closed.
This reduces the number of force calls and with this change, my test case can do 1000 messages in ~1minute.



 All   Comments   Work Log   Change History   Subversion Commits   FishEye   Crucible      Sort Order: Ascending order - Click to sort in descending order
Gary Tully - 25/Apr/08 06:17 AM
Note: the minimum delay would need to configurable I guess.
If the concept is reasonable, more performance analysis of the change is required. My analysis using some of the existing unit tests shows that it behaves a little better in the general case and a lot better in the perf test case included.

Hiram Chirino - 25/Apr/08 07:24 AM
BTW.. not 100% sure how much this will help.

So lets say that sync call is taking a long time to complete.. the client writes will start gettting batched up in the next batch.. then by the time the sync completes the next write batch it gets will be > 1 since several calls should have batched up.


Hiram Chirino - 25/Apr/08 08:21 AM
I take it back.. I see how this helps. In the case were you are doing lots of async writes you avoid doing the flushes to disk so you avoid stalling your writes due to a disk sync.

I'm going to see if we can do a version of this that does not depend on a write delay tho.


Hiram Chirino - 29/Apr/08 02:01 PM
slightly modified version of the patch committed. thx.