Comment by vmarsy | Hacker News Reader

Comment by vmarsy | Hacker News Reader

Parent Full thread

This was an interesting read! The stack is out of the ordinary and intriguing. I'd love to see numbers, performance number: request per second and whatnot compared to a traditional architecture to back up the conclusion :

> This architecture is highly efficient, almost infinitely scalable, yet very light on infrastructure.

I'm curious on how scalable such fine-grain grains (pun intented) (i.e. one grain per user?) are. Wouldn't communication across all those grains yield to poor performance?

Another big question I'd be interested in is testing and debugging: Redux tree/reducers model let's you easily test things. How's the testing/debugging experience in orleans? The author mentions the "time travel", I'd be curious to know his experience so far.

> An Actor system makes sure that every data element / actor object lives in only one place (one machine in the cluster), so there is no duplication of data, which simplifies things dramatically.

What happens when that machine goes down? My understanding of Orleans is that it'll be fault tolerant and handle this, but what are the impact on performance? And is there any guarantees the data will be stored without corruption in the external storage (azure table in the author's case)

Hi, blog author here.

> I'd love to see numbers

This was an experiment, and I didn't do a performance test. The Orleans people will tell you that the current production version will process something on the order of a couple hundred thousand of messages per server per second. If your actors are modelled well, this scales to hundreds of servers, so it would be possible to have on the order of tens of millions of messages per second between actors, including persistence. I expect the upcoming Dotnet Core version to do even better.

> How's the testing/debugging experience

I normally test with xunit, standard dotnet stuff that works very well. Orleans provides a TestingHost that lets you spin up silos for testing grain code in a 'real' environment. This costs some time for startup.

The time travel idea needs some devtools ui, which I didn't build. I'm sure this would be possible though, with the limitation that the "edit and continue" feature of dotnet is not as capable as in javascript: often visual studio will tell you that your change requires a full application restart. You can change code and data while paused in the debugger.

> What happens when the machine goes down?

Orleans would respawn the Grain on another server (using the last-known state) and retry the operation up to two times by default. If you follow a safe implementation pattern (call WriteStateAsync after a state change), your state will be correct. In my blog code, I await successful completion of the message on the client. If something went wrong in Orleans and the state isn't persisted, that promise would be rejected, and it could be shown to the user.

> often visual studio will tell you that your change requires a full application restart

I suspect this is due a .NET runtime limitation.

When you edit your code, as long as you only make modifications inside a method which does not alter the method's declaration and method-signature, you should be fine. Basically, editing compiled code is fine, as long as you are just altering the methods internal IR-code.

If you however end up doing something which alters a method's name, or signature in any way, you end up effectively mutating a class-definition. And there's no part of the .NET runtime which allows that.

As a workaround, you could generate a new class on the fly, but then you would have to update all the existing references to this class in the code... And that probably means invalidating some type-signatures across the line, causing new class-level mutations.

And when all that is resolved, then you would have to port and preserve state for your mutated classes, fake a new stack, etc etc. And then you have turtles all the way down.

Basically at this point, a full recompile is probably the only sane option.

It's a by-product of the static nature of the languages and runtime. I suspect the same applies to JVM based edit-and-go features in Java IDEs.

Thank you for your reply :)

> I'm curious on how scalable such fine-grain grains (pun intented) (i.e. one grain per user?) are.

The Halo 4 team claims[1] that there is a grain-per-game as well as grain-per-user (presence etc.).

[1]: https://channel9.msdn.com/Events/Build/2014/3-641

Reply on news.ycombinator.com