Event Broker Performance

I wondered about the performance of my event broker (CodeProject article) implementation in bbv.Common.

Event Broker: a notification component for synchronous and asynchronous, loosely coupled event handling.

Therefore, I implemented a quick performance test application that prints out the timings for

• Plain .NET events
• Event over Event Broker
• Event over Event Broker with logging extension enabled
• Event over Event Broker with a matching matcher on the subscriber
• Event over Event Broker with a non-matching matcher on the subscriber
• Event over Event Broker with exception throwing subscriber

As well as how the number of subscribers on a single event influences timings.

See explanation of results for details on these scenarios.

Each test scenario above  is executed once, giving the results for a “run”. Four runs are executed in total to get a picture of long time behaviour. The numbers show used milliseconds for 10’000 events. The timings for plain .NET are multiplied with a factor equal to 100 to make them visible in the graph.

milliseconds	.NET * 100	Event Broker	Log Extension	true Matcher	false Matcher	Exception
Run 1	8.6	57	176	150	44	138
Run 2	7.7	54	172	52	40	133
Run 3	8.3	54	196	149	42	132
Run 4	8.2	54	203	151	40	130

General

Initialization (event registration, publisher and subscriber instance creation) is not included in the timings. Only the time of firing the event and handling it with an empty handler is taken into account.

.NET Events

.NET events are very fast, you can execute over 16’000’000 events per second! To have a value in the graph I show the value scaled with a factor of 100.

Event Broker Events

The second column shows the time used to execute 10’000 events over the Event Broker. The event is always fired on the same publisher and received on the same subscriber.

On the test machine, I can execute over 180’000 event broker events per second.

Log Extension

The third column shows the time used when the log extension is added to the event broker. Please note that this includes preparing the log messages and calling log4net logger methods, but not actual logging because log4net is not configured.

As you can see, if you really need performance then do not add the log extension or use your own logging extension that only logs what you really need.

true Matcher

In this scenario, I added a matcher on the subscriber that always matches – meaning that the event is relayed to the subscriber and the handler method on the subscriber is executed.

As you can see, executing matcher – even if as simple as just returning true – is quite expensive. Therefore, you should only use matchers when really needed.

false Matcher

When using a matcher on the subscriber that never matches, the execution time shrinks because the event is not relayed to the subscriber and the handler method on the subscriber is not called.

Exception

In this scenario, the subscriber throws an exception. As you can see, exception handling is not that expensive in .NET.

Dependency On Number Of Subscribers

The following table and graph shows the execution time of 10’000 events over the event broker from a single publisher to n subscribers:

n =	4	8	16	32	64	128	256	512	1024	2048
Run 1	224	214	68	77	223	213	187	9994	9955	9795
Run 2	199	205	72	72	257	207	196	9901	9972	9820
Run 3	234	203	74	73	218	204	197	9895	9990	9833
Run 4	207	259	67	69	221	205	194	10023	9963	9797

You see the time used to execute 10’000 times the same event over the event broker (without logging, matchers, exceptions).

Up to 256 subscribers, the execution time is more or less the same – what surprised me a lot by the way. For more than 256 subscribers the timings change dramatically. Again, only a profiler could solve this mystery. However, my best guess is that something in memory management changes when 256 subscribers are present.

In real life however, the number of subscribers is normally small per event topic.

Test Machine

Dell XPS M1330, Intel® Core(TM)2 Duo CPU T7500 @ 2.20 GHz, 4.00 GB RAM, Windows Vista 32 bit

Conclusions

How you interpret this numbers is up to you. For me, they show that the event broker implementation is fast if you take the features you get into account. Therefore, whenever you do not want to miss the loose coupling power that event broker brings you then use it.

Finally, some numbers are very surprising – needing further investigation. But this has to wait for another post.