What are the practical limitation for get event store?

[Geo Leu]

First of all let me say that get event store is a very nice and attractive solution for an event driven architecture.
It embodies alot of features in one tool. Features which you could have used only by assembling several tools and take care of consistencies on your own.

Now to my question, what are the limitations of get event store?

I see there on the website that it can handle 15k writes/sec. What was the configuration / setup for the server or cluster (if a cluster was used)?
What is the number of max nodes a cluster can handle (by handle I mean keep the input and output flow steady) ?
What are the limitation for the projections? Should they be used only for simple queries?

I am more interested for high input/writes volume applications (with steady 100k writes/sec with or without bursts of milions / sec) ? Is event store a practical
solution for these high volume of input streams?

Some benchmarks for free and commercial versions would nice to have on the website.

Thanks for any clarification

[Phil Bolduc]

From my experience and posts by Greg Young, Event Store performance is limited by the IO (disk) sub-system.  The simplest way to evaluate the performance is to use the include test client.  On my 2013 Lenovo Thinkpad with a Vertex 4 SSD, I can get around 50k or more events written/second. Reads are even faster in the 85k/sec.  Size of your events will also impact the overall performance.

[Greg Young]

"I am more interested for high input/writes volume applications (with
steady 100k writes/sec with or without bursts of milions / sec) ? Is
event store a practical
solution for these high volume of input streams?"

Normally you would give up consistency and/or safety in such
situations first before anything else. ES does not do that at this
time. EG things like ACK a message before fsyncing it to disk or using
asynchronous replication

> --
> You received this message because you are subscribed to the Google Groups
> "Event Store" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to event-store...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Studying for the Turing test

[Geo Leu]

Thanks for the replies. I did not actually understand the problem regarding consistency for a high volume writes scenario. I was more interested at a higher level. Probably I will have to read the event store source code to see what the process flow actually is.
Also when I was refering to taking care of consistency compared to other stacks for implementing event driven architectures (with DDD), I was thinking about the normal stack of some realtional db or nosql db + a messaging queue and maybe esb or transaction coordinator of some sort. With get event store you can forget about maintaining that whole stack. Ofcourse at a first glance :). When I have time probably I will check the code of GES.

Thanks again for the replies. Have a nice day!