Azure Websites and stateful webApp

3
votes

I have a naïve version of a PokerApp running as an Azure Website.

The server stores in its memory the state of the tables, (whose turn it is, blinds value, cards…) etc.

The problem here is that I don't know how much I can rely on the WebServer's memory to be "permanent". A simple restart of the server would cause that memory to be lost and therefore all the games in progress before the restart would get lost / cause trouble.

I've read about using TableStorage to keep session data and share it between instances, but in my case it's not just string of text that I want to share but let's say for example, a Lobby objcet which contains all info associated with the games.

This is very roughly the structure of the object I have in memory

enter image description here

After some of your comments, you can see the object that needs to be stored is quite big and is being almost constantly. I don't know how well serializing and deserializing is going to work for me here...

Should I consider an azure VM which I'm hoping is going to have persistent memory instead of a Website? Or is there a better approach to achieve something like this?

Thanks all for the answers and comments, you've made it clear that one can't rely on local memory when working on the cloud. I'm going to do some refactoring and optimize the "state" object and then use a caching service.

Two question come to my mind though, and once you throw some light on these ones I promise I will shut up and accept @astaykov's great answer.

CONCURRENCY AT INSTANCE LEVEL - I have classic thread locks in my app to avoid concurrency problems, so I'm hoping there is something equivalent for those caching services you guys propose?

Also, I have a few timeouts per table (increase blinds, number of seconds the players have to act…). Let's say a user has just folded a hand, he's finished interacting with the state object so I update the cache. While that state object (to which the timers belong) is cached, my timers will stop ticking…
I know I'm not explaining myself very well here but I hope you guys see my point.

1
azureazure-web-app-servicestateful
I'm afraid the question is too broad. If you look on any of the tutorials, you'll quickly learn that Azure Tables does not only store strings, but can store objects. However, I don't think Azure Tables is the best persistence for your purposes. You may want to read about Redis (available in Azure) for short-term in-memory persistence. – trailmax
In your current design with everything in memory what happens if the AppPool resets or you do a new deployment? Everything is lost? – Craig
@Craig Yep it's all lost :/ – Ruben Serrate
It seems like the simplest solution is a) Make the object in memory serializable b) Store it in blob storage – Craig
@Craig Hmm but then every time a player does something I need to deserialize, update and then serialize and write again.. how efficient is that? – Ruben Serrate

1 Answers

3
votes

I'd suggest using the Azure Redis Cache.

Here is a nice sample how to build MVC App with Redis Cache in 15 minutes.

You can, of course use the Azure Managed Cache. Or end up with Azure Tables. And Azure Tables can hold much more then just a string. But I believe the caching solutions would have lower latency in communication.

In either way, your objects have to be serializable. And yes - the objects will get serialized/deserialized by every access. You can do it manually, or let the framework do it for you. From what I've read, NewtonSoft.JSON is quite good and optimized JSON serializerdeserializer.

UPDATE

When you ask for a VM running in the cloud - a VM will be restarted sooner or later! Application Pool will recycle, a planned maintenance will occur, an unplanned maintenance will occur, a hard disk will fail, a memory module will fail, unforeseen disaster will happen.

Only one thing is for sure - if you want your data to survive server crashes, change the way you think and design software, and take data out of (local) the memory. Or just live the fact that application may lose state sometime.

Second update - for the clocks

Well, you have to play with your imagination and experience. I would question that your clocks work anyway in the context of the ASP.NET app (unless all of them being static properties of a static type, which would be a little hell). My approach would be heavily extend my app to the client as well (JavaScript). There are a lot of great frameworks out there - SignalR, AngularJS, KnockoutJS, none of them to be underestimated! By extending your object model to the client, you can maintain players objects lifetime on the client (keeping the clock ticking) and sending updates from the client to the server for all those events. If you take a look at SignalR, you can keep real time communication between multiple clients (say players) and the server. And the server side of SignalR scales out nicely with Azure Service Bus and even Redis.