FilesystemEventStore performance validation

[Roland Kofler]

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

[Allard Buijze]

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

[Roland Kofler]

Allard,
I've updatet the document with an 'introduction' sheet. Happy to
answer your questions.

On Feb 1, 9:06 pm, Allard Buijze <bui...@gmail.com> wrote:
> 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
>

> On Wed, Feb 1, 2012 at 7:43 PM, Roland Kofler <roland.kof...@gmail.com>wrote:
>
>
>
>
>
>
>
> > 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_QpdG45dHozd3RP...

[Allard Buijze]

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

[Allard Buijze]

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

On Thu, Feb 2, 2012 at 1:06 PM, Roland Kofler <roland...@gmail.com> wrote:

Hello,

On Feb 2, 8:45 am, Allard Buijze <bui...@gmail.com> wrote:
> Hi Roland,
>

> how is the test done? Are all commands fired using a single thread, or
> multiple?

all is single threaded, I certainly will look into asynchrounous
commands/ events later

> Do I see correctly that you included the event handlers (updating a
> mongodb) in the test as well?

Yes, the full cqrs roundtrip is tested: from issuing a command to
storing a DTO in the read-store
this is the test code:
@Test
       public void loadtest() {

               // Given a Recipe
               // CreateRecipe createRecipe = new CreateRecipe(expectedId,
               // "test-rezept", ownerId);
               // cmdBus.dispatch(createRecipe);

               AddIngredient addIngredient = new AddIngredient(expectedId, ownerId,
                               MÖHRCHEN, 30);

               StringBuffer periodreport = new StringBuffer();
               for (int i = 0; i < 100; i++) {
                       DateTime t0 = DateTime.now();
                       cmdBus.dispatch(addIngredient);
                       Period period = new Period(t0, DateTime.now());
                       periodreport.append(period).append("\n");
               }

               System.out.println(periodreport);

}
> 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

 No it is really the FS store. It seems to me that the read operations
are interfered, probably because the OS distributes access to the
harddisk resource between all the running processes and now the file
is big enough that the read operation is interrupted.

 Here is the configuration:

 <bean
class="org.axonframework.commandhandling.annotation.AnnotationCommandHandlerBeanPostProcessor">
       <property name="commandBus" ref="commandBus"/>
   </bean>
   <bean
class="it.bz.tis.nutrition.recipe.commands.RecipeCommandHandler"/>


   <bean
class="org.axonframework.eventhandling.annotation.AnnotationEventListenerBeanPostProcessor">
       <property name="eventBus" ref="eventBus"/>
   </bean>

   <bean class="it.bz.tis.nutrition.qry.recipe.RecipeDtoMapper"/>
   <axon:event-bus id="eventBus"/>
   <axon:command-bus id="commandBus"/>
   <axon:filesystem-event-store id="eventStore" base-dir="./data"/>
   <bean id="recipeRepository"
class="org.axonframework.eventsourcing.GenericEventSourcingRepository">
        <constructor-arg
value="it.bz.tis.nutrition.recipe.domain.Recipe"/>
       <property name="eventBus" ref="eventBus"/>
       <property name="eventStore" ref="eventStore"/>
  </bean>


Anyway, any suggestions for performance or other improvements are
welcome.
Cheers, ro

>
> Anyway, interesting data to see. Thanks for sharing!
>
> Cheers,
>
> Allard
>

[Roland Kofler]

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

On Feb 2, 2:23 pm, Allard Buijze <bui...@gmail.com> wrote:
> 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
>