|
Gary Tully made changes - 25/Apr/08 06:17 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. 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.
applying a modified version of that patch attached to https://issues.apache.org/activemq/browse/AMQ-1689
- This reduces the the number of disk syncs that the broker does on some workloads which increases performance - Fixed and issue where the last write to disk migh get lost on broker shutdown.
Rob Davies made changes - 29/Apr/08 03:43 AM
slightly modified version of the patch committed. thx.
Hiram Chirino made changes - 29/Apr/08 02:01 PM
Gary Tully made changes - 01/May/08 02:18 AM
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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.