To whom it might concern.
On my old Intel Centrino laptop, issuing addItem to a aggregates list
over 1300 times this is the performance I get.
https://docs.google.com/spreadsheet/ccc?key=0AuJFFXVdZ_QpdG45dHozd3RPRjNKTjRlRUhVNU01X2c
I feel confortable with this result, since it is seldom that an
aggregate needs more than 700 events in my doman.
Enjoy!
Roland
Hi Roland,
could you elaborate on the type of test you did, and what the numbers exactly mean? Did you append events to an event store?
Cheers,
Allard
Allard,
I've updatet the document with an 'introduction' sheet. Happy to
answer your questions.
Hi Roland,
how is the test done? Are all commands fired using a single thread, or multiple?
Do I see correctly that you included the event handlers (updating a mongodb) in the test as well?
Did you use the FileSystemEventStore? If you were using the JpaEventStore, I could explain the downgrade at 1100 events: events are retrieved in batches of 1000.
Anyway, interesting data to see. Thanks for sharing!
Cheers,
Allard
Hi Roland,
you are currently using a StringBuffer in a non-multithreaded situation. Your test will be a bit more reliable if you use a StringBuilder or BufferedOutputStream instead.
Your explanation of the “lag” at 1100 events per aggregate in the FS event store makes sense. This is a good test to identify the number of events before requiring a snapshot, by the way.
Cheers,
Allard
Was not aware of StringBuffer issues, thanks.
I've added two series (columns O,P) with StringBuilder.
What we see after >1300 there is a huge penality for the first time
the aggregate gets build.
We can assume this is due to empty cache of the HD-controller.
cheers ro