Long story short: This is probably the most senseless piece of code I have ever written and most likely will ever have written:

onComplete = function(e) {
  //...doing some other stuff

  // at this point everything is
  // loaded and ready to go
  // ...but ... you know ... the client ...
  setTimeout(
    function() {
      $('#loadingCover').hide();
    }, 3000
  );
}

In a web-app there is allways data sent between the client and the server – would you believe me if I told you that after otimizing all the server-calls, bundeling them together ect. you can still save up to 40% (and some cases even 60%) of your traffic caused by client-server communication with not more than one line of code?

Well, the magic word is “MsgPack” – it is a ‘binary-based efficient object serialization library‘. The difference to JSON is, that MsgPack is binary-based – this gives the possibility to make the exchanged data a) smaller and use less bytes, I guess we all know the advantages of that, however there is an even bigger advantage: b) It is faster to parse and encode, having a parser parse 40 bytes takes about twice as long as parsing 20 bytes. I know those advantages might seem marginal – however if you scale this up to a couple thousand (or even more) users you will see quite a bit of a difference there. And even if you don’t have a couple thousand users – why would you not want to take advantage of something like this?

To make this difference more visible i put together a small example:

As you can see, the MsgPack-encoded data is about 2/3 the size of JSON.

(edit: I previously had some unnecessary bytes in the JSON code, making the example to much in favour of MsgPack, I removed those. thx to charles leifer for noticing)

Additionally, the whole thing look less readable when you look at it – so as a small bonus this will probably repell some script-kiddies, who are trying to intercept your JSON- or XML-calls.

One line of code you said?

That is correct, assuming that you are currently using JSON: (JavaScript-example)

//just exchange the encoding and decoding lines
myJSONString = JSON.stringify(myObject);
myObject = JSON.parse(myJSONString);
//with
var myByteArray = msgpack.pack(myObject);
myObject = msgpack.unpack(myByteArray);

MsgPack returns Objects/Hashes or Arrays, Numbers and Strings just like JSON will do, so there is NO need to change anything further than the encoding- and decoding lines.

Why havn’t I heared from MsgPack before?

As with all good things: They need time, MsgPack has first been introduced about 2 1/2 years ago I believe (at least according to their github-repo) – it might be older, but without a github repository it is rather difficult to get noticed nowadays.

I can only encourage you to visit the MsgPack-Site and download the implementation for your programming-language(every major language has one), even if your desired language has no official implementation, there are usually unofficial projects to be found via google or github. If you can’t find it – contribute to the community and write your own implementation and share it.

Edit #1: Looking at JavaScript it is true, that parsing JSON is faster than any custom parser. However, the field of usage is more than just JavaScript, considered that the serverload is probably more to be taken into account than your clients, as it won’t really matter if your clients need 0.1ms or 2ms to decode/encode something, however on the serverside MsgPack-parsing is usually faster than JSON – in the case of Ruby, MsgPack is faster by a factor of ~5.

Edit #2: Since there was quite a bit of critisism here and on Hacker News, Sadayuki “Sada” Furuhashi, the creator of MessagePack posted some thoughts on MessagePack on gist: https://gist.github.com/2908191 clarifying a few things, thank you for that Sadayuki.

So here are a few basic points what I’ve learned while coding the server-side of my app that you might be able to apply to your app:

• do calculations only when a user logs on to your app, especially if the calculation only affects the user
• do NOT use bulk calculations/queries unless they’re absolutely neccessary

  e.g.: don’t run a cronjob, that involves a big amount of(or even all) users

• MOST bulk calculations can be solved in another way, it’s usually more tricky to accomplish but it is possible in pretty much any case

  e.g.: in the case of time-based events, lets say “User A started a contract, that will be finished in 1h” – the worst thing you can do is to run a cronjob that checks every couple seconds if the contract is finished yet – instead save the timestamp when that contract will finish and whenever the user logs back on you do the actions according to the state – e.g.: if the contract was finished 2h ago, then add the according resources ect…

Now to the specific example that I had to struggle with:

Weekly Tournament: At the end of every tournament the highscore is resetted and every player gets awarded a trophy: #1 = Gold, #2 = Silver, #3 = Bronce, >#4 = Wooden. (ranking is based on the scores of friends, that are playing)

Now there are several ways to calculate who gets which trophy, i’m going to list two of them:

1. Heavy server-side calculation(easy way)

The crowbar method of doing this is to run a cronjob and when the tournemt ends, the server goes through every user, will collect the score of each friend of this user und then compare their scores and assign a trophy to the selected player, then reset their highscores.

Some might say “Yea, works…and it’s only needed once a week, so where’s the problem, it doesn’t matter if the server needs a couple seconds to run this job.”

Okay – but if time is not the issue, then traffic and database-queries definitly are, based on my server-setup you are very likely to run into problems here if the database is and external service.

Heavy-Version number of queries:  min. 1 read + 1 (batch)write for every user (can be more, depending on the implementation)

Heavy-Version queries at logon: 0 for calculation purposes, however 1 read is done anyways, that is not beeing utilized in this version

2. Light server-side calculation(more tricky)

The light version is, to calculate the trophy the player earned the next time the player logs onto the game. However it’s not as easy as that – for example what happens if a player logs on and creates a new highscore after the tournament ended – how will players, that logon later know that this new highscore should not be held into account with the old tournament. I’m going to show how this is accomplished in ZeroPilot, it’s a little bit tricky but in terms of server-calculations totally worth it:

Every tournament has an ID, and every high score is saved with a reference to the current tournament ID. So whenever the player logs on, the server compares the ID from the current tournament with the ID of the latest player’s high score – if they don’t match then it’s probably because this is a new week and it’s time to check what trophy that player should get. To be certain this is checked only once, I also set a flag in the userdata, that this player already got awarded for that tournament. To make it more visible here’s a code-snippet:

servCt = server[:currentTournament]
servLt = server[:lastTournament]
if user[:currentTournament] != servCt
user[:lastTournament] = user[:currentTournament]
user[:currentTournament] = servCt
calculateAndAssignTrophy(user, servLt)
user[:wasAwarded][servLt] = true
# Since I don't need any score that are older than 2 weeks
# I just delete the old ones to save datastorage, but this
# step is not neccessary if your db is big enough
deleteTournamentScoreBeforeLast(user)
end

And the following is all that is done within the cron-job when the tournament ends:

server[:lastTournament] = server[:currentTournament]
server[:currentTournament] += 1

Light-Version cron number of queries:  1 read, 2 writes

Light-Version queries on logon:  1 read, 1 write per user, however it is very likely that users will logon over a period of time, and those queries are done anyways at logon.

So as you can see it makes quite a difference, if you rely on easy-to-implement algorithms or if you use a less obviouse way of calculating things and do the calculations in single steps just in time when the data is needed. Another point for thisis, that the calculations and queries are spread out over a period of time as the user logon to the game, this will not cause any spikes like it is very likely the case with the heavy-version.

As an indie developer i guess you are pretty familiar with the issue of a limited budget, and as we all know servers for hosting an application can be very expensive and you need quite some knowledge if you want to manage and configure or even cluster a server yourself.

So here I’m going to cover my experiences on the hunt for a good solution for ZeroPilot and what I found is one of the best solutions for this issue in terms of a good cost/benefit ratio.

So, before explaining why, I’m just going to tell you the solution I’m working with right now:

Heroku + Redis To Go + Amazon DynamoDB + Facebook Score API

And here is how it works:

Heroku is used for the hosting of the app itself. All the persistent data is stored on Amazon DynamoDB, and Redis is being used for the data of all users, that are currently online playing the game.

Why I chose a setup like this:

As there is no single solution, that “has it all”, or at least non that I know of, that offers reasonable pricing, I tried to utilize all the good aspects of each service, starting with DynamoDB:

1. Amazon DynamoDB

Amazon DynamoDB is a scaleable database solution by Amazon Web Services, that is based on SSD-drives and is VERY easy to integrate. The free plan includes 10 reads/sec, 5 writes/sec and 100MB of storage capacity – now if you just look at the numbers it may not sound like a very good deal – however if you use it the right way, this becomes actually pretty usefull.

Looking at the capacity: 100MB, for ZeroPilot this about enough space to store the data of a little more than 200.000 users, doesn’t sound too much, but as soon as you start paying for the service, even if it is just 5$ a month, they remove the storage limit.

Read/Write thoughput: 10 reads and 5 writes / second doesn’t look to good either, however I only use this database for offline and persistent data. So whenever a user logs on, the data is read once and saved to Redis, when the user logs off, the data is written from Redis to DynamoDB. Whenever you would reach the limit of your throughput the SDK automatically waits a certain amount of time and does a retry for the query.

The pricing for DynamoDB is for each:

(details at: http://aws.amazon.com/dynamodb/#pricing )

50 read/sec: 1cent/h

10 write/sec: 1cent/h

So with the free plan, about 36.000 users could logon to the app per hour

and for about 14$/month about 180.000 users could logon each hour.

An alternative to this would have been MongoLab(MongoDB), as it has 240MB of db-storage in it’s free plan – it is also pretty easy to integrate and as far as i know there is no limited in throughput. However I decided to go with AWS as they really make it easy for you providing and SDK for pretty much any language and having a very good documentation. Even though I already found one thing, that was bugging me: All Number-Values of DynamoDB are stored as – that caused some problems as does not have all the implementations that i needed, so whenever I read from Dynamo I have to convert the .to_i to Integer in order to write it correctly to Redis. I have been thinking about switching to MongoDB quite a bit already.

2. Redis (Redis To Go)

Redis is a Key-Value-Storage, that sits in the RAM. It has an extremly low latency and can story all primary datastructures: Strings, Lists, Sets, Hashes

I use this in ZeroPilot for the data of users, that are currently online, as there is basically no limit in throughput in all the plans of Redis To Go this is the perfect solution, since online players are making requests all the time, when starting a game, when finishing a game ect. However, since Redis sits on the RAM, storage is expensive, and that’s why the free Plan only includes 5MB. For 5$ / month you can get 20MB of storage, which is enough for about 4200 players being online at the same time, unfortunately i’m FAR away from that

3. Heroku

Heroku is awesome! Why?

• there is a pretty extensive FREE plan
• you can run pretty much any language
• it has integration with A LOT of addons
• you scale up the capacity of your plan at any time
• automatically adds a template for your new app if you want

4. Facebook Score API

The facebook score api is the smallest part, it’s not really needed but takes a few queries of my back. So when a user gets a new highscore, it is sent to facebook, and stored there.  And when a player logs on, instead of querying the current scores from DynamoDB the scores are queried from facebook.

I hope this helps you finding YOUR “perfect” solution. Here are all the links again:

• Heroku: http://www.heroku.com/
• AWS DynamoDB: http://aws.amazon.com/dynamodb/
• Redis: http://redis.io/
• Redis To Go: https://addons.heroku.com/redistogo
• MongoDB http://www.mongodb.org/
• MongoLab: https://mongolab.com/home
• Facebook Score API: https://developers.facebook.com/docs/score/