DataSnap analysis based on Speed & Stability tests(Compared to mORMot)

roberto.schneiders · 2012-11-23 11:31:04

Hello guys

I'm writing a blog and the first post is about performance and stability datasnap XE3. Compared with mORMot and some other frameworks.

If interested, read on http://robertocschneiders.wordpress.com

mORMot is incredibly fast.

ab · 2012-11-23 13:15:58

Very nice article.

I suspect that in fact the main bottleneck of DataSnap is Indy communication layer, as you stated.
Was the Indy thread-pool enabled? If not, you may try with this option: re-using threads may increase speed and stability.
I'm not surprised that DataSnap has some performance and stability issues, since it was not designed to be fast, but integrated into existing code. I still can't understand why they use classes and RTTI and not interfaces, just like WCF (or mORMot).

WCF and mORMot uses the same kernel-mode server of Windows, i.e. http.sys.
See http://blog.synopse.info/post/2011/03/1 … ode-server

It is fair to state, as you do, that mORMot server is only using 50% of CPU in your tests, so that you may have even better results with a more powerful client library, in a more aggressive concurrent testing. Server side is more optimized than client side, on purpose.

It may be interesting to re-do your tests with a more complex kind of query.
"Hello world" is OK, but what about parameter marshaling? We may do some computation server-side, a provide a set of methods.
You did use the method-based kind of services, but implementing a whole interface could make sense.
I wonder how the results may look like. Method-based services are as fast as possible, but interface-based services are what should be used in real applications.
Of course, client-side may be dedicated to each client, since JSON RPC is not as standard as SOAP.

In comparison with WCF, we can be proud that our little mORMot has a very good responsiveness, in regard to all the resources put by Microsoft for optimizing their platform.
"Native" compilation like Delphi can do wonders, when used properly, as we try to do with our framework.
But you can still have "managed" applications (like Java or .Net) be more responsive than "native", when performance was not part of the roadmap, just like with DataSnap.

This is nice seeing that you liked our Open Source work!
From the ground up, we wanted to have the best possible performance available, even for the database part.
I used to work for some companies where server-side performance was directly proportional to the financial ROI: the more clients on the hardware, the more money to get.
In fact, I'm quite alone at Synopse, but some users are proposing very nice contributions and feedback.
Sounds like the recommendations I made at http://blog.synopse.info/post/2011/05/2 … plications are accurate.
So it is an exciting project!

Thanks for sharing!
Any feedback is warmly welcome.
If you have any idea of improvement, feel free to ask.

Roberto Schneiders · 2013-01-18 10:25:37

I published a new post with the new tests (Using XE3 Update 1).

http://robertocschneiders.wordpress.com … ts-part-2/

mpv · 2013-01-18 12:58:53

Great work! Just some tips:
1) To increase mORMot performance it is better to set number of thread = CPUs core count *2 (or even = CPUs core count in your case because you do not do any calculation in server side)
2) As AB sad in prev. post most interesting things started then we use some kind of logic in server side (JSON serialisation, Database access) - in this case I think mORMot is MATCH better compared to others (except node, maybe, or very optimized WCF solution what not use .NET connection pull/serialization)
3) I agree with AB - if using Jmeter you need at last 2 client to utilize all server resources - this is the reason mOTMot, Java, Node and WCF performance is nearly the same.
4) To be honest is good to use nodeJS cluster http://nodejs.org/api/cluster.html with the same thread count as in mORMot
Thanks for your work!

ab · 2013-01-18 13:08:38

Thanks for the feedback.

Most of the comments about the first article are now included in the description, and new tests are still a bit disappointing, about performance and scalability.

I guess this would be very difficult to Embarcadero to improve the performance, without changing the design.
Architecture is what matters, here.
I suppose they do not have a lot of regression tests, so changing the architecture may cost them a lot.

ab · 2013-01-25 19:40:36

Some new speed tests of our http.sys server:

http://andremussche.blogspot.com/2013/0 … speed.html
http://robertocschneiders.wordpress.com … omment-313

Not bad.

Roberto Schneiders · 2013-01-25 21:21:19

Not bad

is good to see that other people have reached similar conclusions and results.

mORMot Open Source

#1 2012-11-23 11:31:04

DataSnap analysis based on Speed & Stability tests(Compared to mORMot)

#2 2012-11-23 13:15:58

Re: DataSnap analysis based on Speed & Stability tests(Compared to mORMot)

#3 2013-01-18 10:25:37

Re: DataSnap analysis based on Speed & Stability tests(Compared to mORMot)

#4 2013-01-18 12:58:53

Re: DataSnap analysis based on Speed & Stability tests(Compared to mORMot)

#5 2013-01-18 13:08:38

Re: DataSnap analysis based on Speed & Stability tests(Compared to mORMot)

#6 2013-01-25 19:40:36

Re: DataSnap analysis based on Speed & Stability tests(Compared to mORMot)

#7 2013-01-25 21:21:19

Re: DataSnap analysis based on Speed & Stability tests(Compared to mORMot)

Board footer