The basic idea of PJAX is that you update only the parts of the page that change when the user navigates through your app. However, unlike a normal AJAX app that returns only data (JSON) from the server, a PJAX request actually contains normal HTML that has been generated on the server. This HTML is only a fragment of the full page and using Javascript on the client this fragment is substituted in for the last page’s content.

Below you see a diagram of how this works.

The first request to the server is a normal request (1). The server then returns the page in the normal fashion (2). The difference with PJAX is with subsequent requests. For example, if a user clicks on a link that opens the /about page the client-side JavaScript makes a request for only the parts of the page that need to change (3). The server then generates the html of the only the changed content and returns it in the response (4). The client-side JavaScript then replaces the old content with the new content.

You can see in the next image how the network traffic of the requests look. The first page is loaded along with all the supporting static content. You can see at the bottom the requests for the ‘about’ and ‘contact’ pages. When the user navigates to these pages, only the new content is requested from the server; in these cases partial HTML pages. You can see this technique results in far fewer HTTP requests to the server and less content being sent over the wire. This reduces the load time of the page and will also reduce load on your server and bandwidth usage.

This technique has been implimented in a variety of ways. You may recall that ASP.NET actually ships with something like this called partials. The method I am using is a bit more do-it-yourself, but it is similar. So lets take a look at how this could be implimented using Node.js with Express.

On the client I am using a great jQuery library called jQuery-pjax. This library takes care of some of the lower-level code such as making the ajax request and replacing HTML content. By using this library you can impliment the pjax request with only a few lines of code.

The first thing we need to do is setup our links to be pjax links. We can do this by adding the data-pjax attribute to the link. This attribute is set to the container where the content will be loaded. In this case a div with the id set to ‘main’.

<a href='/explore' data-pjax='#main'>Explore</a>

Next, we simply need to call the pjax extension on every element that contains the data attribute ‘data-pjax’. You can see how we do this in a single line of code below.

$('a[data-pjax]').pjax()

That’s it for the client; now we need to modify the server. The trick with this library is that when a PJAX request is made an HTTP header named ‘X-PJAX’ is added to the request. By looking for this request our server knows whether to return only the html fragment that applies to this specific content or to return the entire HTML document.

There is a node module called express-pjax that extends Express and actually takes care of handling these PJAX request for us. This module is very simple. All it does is look for the header and if the header is present it sets the request options to not use a layout page. This results in only the portion of our view that is page specific to be rendered and returned. If the PJAX header is not present then the page is rendered like normal with the full view. The code of this module is below.

module.exports = function() {
  return function(req, res, next) {
    if (req.header('X-PJAX')) {
      req.pjax = true;
    }

    res.renderPjax = function(view, options, fn) {
      if (req.pjax) {
        if (options) {
          options.layout = false;
        } else {
          options = {};
          options.layout = false;
        }
      }

      res.render(view, options, fn);
    };

    next();
  };
};

Since we are using the express-pjax module we only need to make a simple modification to our routes. Instead of calling render we need to call renderPjax.

module.exports = function(app) {

	app.get('/', function(req, res) {
		res.renderPjax('home/index', { title: 'SocialDrawing' });
	});

	app.get('/about', function(req, res) {
		res.renderPjax('home/about', { title: 'About' });
	});

	app.get('/contact', function(req, res) {
		res.renderPjax('home/contact', { title: 'Contact' });
	});

};

The beautify of this method is that it requires very little change to your application and you can share url routes with both the client and the server. Additionally, because jQuery-pjax uses the HTML5 history API you don’t have to use hashes in your urls. Lastly, any browser that is not compatible with this approach will just revert to normal requests which means you can support every browser back to IE6 (not that I recommend doing that).

Events

A common issue with this method is executing Javascript when a PJAX page is loaded or unloaded. To handle this the jQuery-pjax library has a number of events you can subscribe.

$('a.pjax').pjax('#main')
$('#main')
  .on('pjax:start', function() { $('#loading').show() })
  .on('pjax:end',   function() { $('#loading').hide() })

By subscribing to these events you can run code that you would normally run on $(document).ready(). In a future post I will show you how you can use these events to automatically handle loading and unloading views in a way that also works with normal page loads.

Caching

In order to further improve the performance of you PJAX page loads you should impliment server-side and client-side caching. By utilizing caching you can build an application that is extremely responsive and in most cases your uses will not be able to tell the difference between this style of application and a full client-side application. There is a great article written on the 37Signals‘ blog about how they used this approach in their new version of Basecamp. The post goes into detail about how they use PJAX and caching to build a super fast app.

Conclusion

The biggest advantage of this approach is simplicity. I find that writing an application in a full client-side framework can result in a great app, but sometimes it is overly complicated. With great server-side tooling available for rendering views in frameworks like ExpressJS or ASP.NET MVC sometimes it is just easier to handle the view rendering on the server. The PJAX approach allows you to use the tools you are familiar with while still getting great client-side performance. As with most design choices, there are trade-offs. This approach isn’t for every app, but it is a great tool to have available and use when appropriate.

For those who have been following the Facebook C# SDK recently, you may have noticed some other big changes as well. In addition to moving the project to Github, we have also completely rewritten our documentation. You can find the new documentation on our project’s website at http://csharpsdk.org. You can find the full source of the SDK at http://github.com/facebook-csharp-sdk.

Additionally, we also just released another big update to the SDK with version 6.0.10. Version 6 has been primarily about cleaning up and simplifying the API for the SDK. While there are a few breaking changes in V6, we think you will find this version of the SDK to be much easier to work with. You can get started with V6 of the Facebook C# SDK by installing the Facebook Nuget package.

The next change we have made is fairly minor, but important. We are now formally following SemVer.org versioning with the project. This should make it easier for developers to understand the impacts of new versions of the SDK. With this change any breaking changes will result it a major version number change, however with Facebook’s APIs becoming much more stable we hope to avoid breaking changes as much as possible.

The final bit of news regarding the Facebook C# SDK is that we also have released a few libraries that were build as part of the SDK as seperate projects. These libraries are HttpHelper, SimpleJson, and ReflectionUtils. These libraries simpilify the process of building cross-platform .Net/Windows libraries by abstracting some of the differences with HTTP requests and reflection in the platforms. SimpleJson is exactly what it sounds like and is a very simple JSON serializer. For more information on these libraries and how they fit into the Facebook C# SDK read Prabir’s post here.

Lots of great changes recently with the Facebook C# SDK. We are excited and honored to be a part of The Outercurve Foundation. We look forward to continually improving the Facbeook C# SDK and working with the community to give .Net and Windows developers the best tools for developing Facebook apps.

As always let me know if you have any questions or feedback.

You can find the full source for this plugin on Github at https://github.com/ntotten/jquery-fb.

To add the Facebook Javascript SDK to your site simply call the following Javascript somewhere in your document:

$(document).fb('youappid');

If you want to use the events simply add handles to either the fb:initializing or fb:initialized events.

$(document).on('fb:initializing', function() {
  // Do something before FB.Init is called
});

$(document).on('fb:initialized', function() {
  // Do something after FB.Init is called
});
$(document).fb('youappid');

The benefit of this library is that it you can add the initialization code in a single place in your app (such as a layout or master page) and then use the jQuery events to run the appropriate code on specific pages. For example, on your login page you may want to do something like this:

$(document).ready(function() {
  // Add the function to run after FB is initialized
    $(document).on('fb:initialized', function() {
      FB.getLoginStatus(fbAuthStatusChange);
    });
    $(document).fb('youappid');
});

function fbAuthStatusChange(request) {
    // Do something
}

It is a pretty simple plugin, but I think it is helpful. I have used something similar to this for a while and it has helped me out a lot. I have a few minor improvements I want to add to this, but it should be ready to use.

Update: This package is now on Nuget. It is called ‘jQuery.fb’. You can find it here: https://nuget.org/packages/jQuery.fb

Let me know if you have any questions or feedback.

The post is a summary of some of the most recent news and updates around Node.js and Windows Azure.

Windows Azure SDK for Node.js Version 0.5.2

The Windows Azure SDK for Node.js continues to be updated rapidly. The most recent update, version 0.5.2, adds support for Windows Azure Service Bus in addition to numerous bug fixes.

The addition of Windows Azure Service Bus support to the Node.js SDK enables a whole new set of scenarios for Node.js developers on Windows Azure. The Service Bus enables  developers to build large decoupled systems though relays and pub/sub queues. For more information on version 0.5.2 of the SDK as well as some examples of using Service Bus with Node.js I would recommend reading this post by Glenn Block.

Reduced Pricing for Windows Azure Compute and Storage

This next bit of news isn’t explicitly for Node.js developers, but it is still big. Recently, we announced that the price for Windows Azure Compute and Storage would be reduced. The most notable reduction is that the Extra-Small Compute instance is now priced at $0.02 per hour. This means that you can run two servers with a 99.95% SLA for only about $30 per month.

Combining two extra-small instances with the power of Node.js makes for some serious computing for a great price. I am working on a few demos that will show what you can do with only 2 extra-small instances using Node.js that I will post shortly, but for now I challenge you to build something and see how much you can accomplish for $30 a month.  Remember – if you are a startup you can also use BizSpark to get even more Windows Azure for FREE.

Using Windows Azure Access Control Services with Node.js

The last bit of news is a great post that Matias Woloski did showing how you can use Windows Azure Access Control Services (ACS) with Node.js. The process is really straight forward so if you are building an application that requires multiple identity providers   I recommend giving that a read.

Coming Soon

Keep an eye out here for most posts like these. Additionally, I am starting a series of tutorials on Node.js and Windows Azure that you will see on my blog shortly.

Let me know if you have any questions or feedback.

First, you need to install Ruby. You download the Ruby installer for Windows here. Download the most recent version of Ruby and run the installer. When you install Ruby you will want to select a few options to make ruby easier to use.

After you have Ruby installed you will need to install the Ruby Development Kit. You can find this on the Ruby downloads page as well. Download and extract the development kit nto a directory of your choice. I recommend C:\DevKit, but anything will work. After the developer kit has been extracted you need run the installation. You can do that by executing the following commands.

cd C:\DevKit
ruby dk.rb init
ruby dk.rb install

Now you are ready to install Jekyll. You can do that by running the following command.

gem install jekyll

Finally, if you are using the RDiscount markdown engine, which is the one I prefer, you will need to install that as well.

gem install rdiscount

Now, you are ready to build your site using Jekyll. In order to do this simply navigate to your site’s directory and run the following command.

jekyll --server

As you can see, I ran Jekyll on the Facebook C# SDK documentation and the output is placed in the _site directory.

Since we used the -server option when running Jekyll a simple web server was started and is running at http://localhost:4000. You can now view your site in the browser. Generally, I like to just use Jekyll to build the site and then use IIS on my local machine to host the site. You can do this by simply creating a new site in IIS and pointing it to the _site folder. Either way you now have your Jekyll site up and running for local development. This should make it a little easier to build your site, then when you are ready you can do a push to Github to deploy your site publicly.

Let me know if you have any questions or feedback.

It has been a while since I have written a post on the Facebook C# SDK. For those that follow my blog and the sdk you probably know that since I have moved to Microsoft I have spent less time on the Facebook C# SDK and more time on Windows Azure. Fortunately, the Facebook C# SDK was left in the very capable hands of Prabir Shrestha and it has continued to thrive. While I haven’t been spending much time with the SDK, it is still a project I care about and as such I wanted to share our plans to keep the project moving forward.

Moving to Github

In the past few days we have been in the process of moving the Facebook C# SDK project to Github. Since the project was founded nearly two years ago we have hosted the SDK on Codeplex. Codeplex has been a great place for our project and on Codeplex we have recieved nearly 120,000 downloads. However, since the project was founded we have seen more and more projects and developers migrated to Github. Github offers a great set of collaboration tools that make managing a project like the Facebook C# SDK a breeze. We believe Github will enable the community to more easily contribute back code to the SDK through forks and pull requests. As such, the new home for the Facebook C# SDK will be at http://github.com/facebook-csharp-sdk.

Platforms and Frameworks

When the Facebook C# SDK was started we supported only .Net 4.0 Full Profile. This was primarily because the SDK relied heavily on dynamic objects and the reliance on objects found in ASP.NET libraries. Over time the SDK has evolved to support .Net 3.5, .Net 3.5 Client Profile, .Net 4.0 Client Profile, Silverlight 3, Silverlight 4, Silverlight 5, MVC 2, MVC 3, Windows Phone 7.0, Windows Phone 7.1, and most recently WinRT (Windows 8 Metro Style Apps). This is obviously a huge amount of code to write and maintain. If you have seen the code of the SDK you will notice there are lots of preprocessor directives that help us work around the differences in the various platforms. You can see an example of this in the code below.

    request.ContentType = contentType;
    if (!string.IsNullOrEmpty(etag))
        request.Headers[HttpRequestHeader.IfNoneMatch] =
             string.Concat('"', etag, '"');
#if !(SILVERLIGHT || WINRT)
    request.AutomaticDecompression =
        DecompressionMethods.GZip | DecompressionMethods.Deflate;
#endif
#if WINRT
    request.Headers[HttpRequestHeader.AcceptEncoding] = "gzip,deflate";
#endif
    if (input != null)
        request.TrySetContentLength(input.Length);
#if (!(SILVERLIGHT || WINRT) || WINDOWS_PHONE)
    request.UserAgent = "Facebook C# SDK";
#endif
    return new HttpHelper(request);

As you can see this code can be difficult to maintain, test, and debug. The good news is that through Prabir’s excellent work of abstracting the most difficult portions of this code we have been able to keep these proprocessor directives to a minimum. I will go into more details about this later in the article. What this means though is that we will do our best to keep supporting all of the current and future .Net and Windows platforms.

However, the reason I wanted to discuss this is to note that with this support there is generally a trade-off. At times we must decided whether to implement the new features of a particular platforms or maintain compatibility. So as I said, we will try to maintain compatibility with the various platforms, but moving forward we will be focusing our efforts on a few areas.

We want to make sure developers have a great experience with the Facebook C# SDK when developing web apps, Windows Phone Apps, and Windows 8 Metro Style Apps. This means that we will focus our energies on ASP.NET, Windows Phone, and WinRT support. We will be building out high quality samples and writing better documentation primarily around these three platforms and frameworks. While we aren’t explicitly not supporting the other platforms, our efforts will be minimal. We definitely welcome community contributions so if you have a great Silverlight sample please form the repo and contribute it back.

License

We have also decided to redistribute the Facebook C# SDK under the Apache 2.0 license. This license is more popular than the Ms-Pl license and is consistent with the license for  Facebook’s official SDKs and samples. While I am no lawyer, my understanding is that the Apache 2.0 license is the same in nearly every respect to Ms-Pl so this shouldn’t require any change on your part. You are still free to redistribute the SDK, use it in commercial projects, etc.

Facebook C# SDK and Web Apps

For those that have used the Facebook C# SDK in the past to develop web apps you have probably used the Facebook.Web and Facebook.Web.Mvc libraries. These libraries provide helper methods that were designed to make it easier to perform tasks such as authentication with Facebook in ASP.NET WebForms and MVC apps. Unfortunately, with the many changes to the Facebook platform, the new versions of MVC, and the new features added to the core Facebook C# SDK these libraries evolved in a way that we believe made them no so easy to use.

Instead of trying to patch and fix these libraries once again, we decided that it was time to take a step back and reevaluate how we handle web apps with the Facebook C# SDK. As such, we have decided that going forward we will be removing the Facebook.Web and Facebook.Web.Mvc libraries from the SDK. This change will happen in the 6.0 release and will not effect developers still using the 5.0 release. I will discuss our version plans later in this post in more detail.

So with the removal of the Facebook.Web and Facebook.Web.Mvc libraries you are probably wondering how will you develop Facebook Apps using ASP.NET WebForms and MVC. First, we are moving some of the more critical parts of the Facebook.Web and Facebook.Web.Mvc libraries into the core Facebook.dll. Second, we are going to be providing much higher quality samples for ASP.NET WebForms and MVC developers. Last, we intend to ship various NuGet packages that contain smaller parts of the Facebook  web libraries.

We believe the approach of having only a single Facebook.dll library will greatly simplify the  process of getting started developing your app. It will reduce the API surface and thus reduce the complexity. Additionally, we have found that developers often tweak the code in the web libraries to fit their application. For this reason we believe that shipping the web code as samples, simple NuGet packages, and general guidance will better allow developers to integrate and understand Facebook development in ASP.NET.

Now, we do understand this change may be difficult for some people. Many apps have already been built with the Facebook C# SDK and breaking changes can be tough. We have always tried to avoid breaking changes and generally have done so except in the case where Facebook introduced breaking changes. To this end we will keep updating Version 5.X of the Facebook C# SDK. We won’t be adding new feature to version 5, but we will ensure that it keeps working for you in the foreseeable future. You can find the code for version 5.x on github in a branch called ‘v5′. You can see that branch here: https://github.com/facebook-csharp-sdk/facebook-csharp-sdk/tree/v5.

Version 6.0

As mentioned earlier, we are starting work on version 6.0 of the Facebook C# SDK. Today, Prabir released Version 6.0 Alpha. This is a preview of where we are heading with the SDK. The overall goal of Version 6.0 is simplicity. We are reducing the API surface, improving the documentation, and building out better samples to make it even easier to build a Facebook app for .Net or any flavor of Windows.

Prabir has written an excellent post that goes into more detail about the technical changes to version 6.0, but below are a few highlights.

• You can now use anonymous objects as parameters. Before you had to either create a Dictionary or ExpandoObject.
• GZip/Deflate has been enabled for desktop client profiles.
• We have introduced FacebookMediaStream to replace FacebookMediaObject. You can now work with this object like a normal stream rather than converting back and forth to a byte array.
• You can now optimize your request to the graph with ETags.

Version 6.0 is an exciting step forward for Facebook developers on the Microsoft stack. We hope version 6.0 will greatly simplify your experience and help you create great Facebook apps. As I mentioned, the currently release is only an alpha release so we look forward to your feedback.

Documentation

Documentation has always been one of the biggest complaints for our developers. Admittedly, we have not always been able to keep our documents up to date to the SDK. We are hoping to correct this problem moving forward. With Prabir taking over in the last months as the lead developer on the Facebook C# SDK this has left me free to focus on other areas. Moving forward my contributions to the Facebook C# SDK will be primarily on writing documentation, tutorials, and building samples. My hope is that we can get even more developers using the Facebook C# SDK to build great Facebook apps.

When moving to Github we evaluated the various options for documentation. We thought about using the Github wiki, but in the end it felt a bit too constrained. Additionally, we are starting to split the code of the Facebook C# SDK into a variety of Github repositories. However, we didn’t want to also split up the documentation. We thought there should be a high quality, customizable, and centralized space for documentation. We decided that Github pages would work nicely for our needs. Many other projects use Github pages to build out rich and high quality documentation. You can see our early efforts at http://docs.csharpsdk.org. This is just an early start, but in the coming weeks expect to see this resource grow to provide lots of great content.

Issues and Discussions

One thing you will notice on Github is that there is no discussions area. The old Codeplex project had a discussions area where many people asked questions and provided feedback. While we know that many of you liked that model we always have tried to discourage using Codeplex for discussions because of the problems associated with threaded conversations. First, information was quickly outdated. Often times you could find a discussion in a search that would seem like it solved your problem, but the answer would be outdated. Additionally, there is no way of noting which answer is the correct answer. You had to read the entire conversation to figure out the solution (if there was even one). For these reasons we have all come to know and love StackOverflow.

Recently, Facebook showed some love for StackOverflow and moved their developer forums to http://facebook.stackoverflow.com. We have decided to do the same. Going forward we will not offer a discussion area outside of Stackoverflow. We believe this will help keep questions and answered organized, relevant, and make it easier for developers to find the answers they are looking for. We will continue to monitor and answer questions on StackOverflow.

The one issue StackOverflow does not solve is bugs. The old Codeplex discussions were often the first place a bug was reported. This made it really difficult for us to keep track of these bugs. Going forward, we are going to be using Github issues for all bugs. If you find a bug or even think you have a bug file an issue. Users can then comment on issues, track issues, and we can tag issues, and mark them as fixed as appropriate. This will make our jobs easier and help ensure that your bug/issue gets fixed as soon as possible.

Also, issues are not just for bugs. Please add feature requests, documentation request/issues, sample requests/issues to the project issues as well. Don’t worry that your issues maybe isn’t really a bug or that your request might seem too specific. We love the feedback and want your help to improve the SDK.

Utility Libraries

As we built out the Facebook C# SDK we also created several utility libraries as well. The first of these libraries is SimpleJson which is a very robust yet very simple JSON serializer. Next is HttpHelper which simplifies making HTTP requests from various .Net/Windows platforms. ReflectionUtils which is a simple set of tools for performing reflection. Finally, there is CombinationStream which allows you to represent multiple streams as a single stream. We have moved these projects to repositories under the facebook-csharp-sdk organization on Github. Feel free to use these in your libraries or applications as well.

Community Contributions

Please fork our repositories. If you aren’t familiar with Github there are some awesome documents on their website. Additionally, Tekpub has a great video on getting started with Git here. The video costs $15, but if you like learning through videos it is definitely worth it.

If you want to submit a patch, please send us a pull request. We would love help with bug fixes, documentation, samples, or anything else. With github these sort of contributions are really easy to manage so please feel free to jump in and help out.

Wrapping Up

This post ended up being a lot longer than I had planned, but I hope you are excited about where the Facebook C# SDK is heading. There were a lot of big announcements today and we have a few more exciting announcements in the next few weeks. As always, please feel free to leave feedback. We would love to hear from you.

For those who haven’t downloaded or used the social gaming toolkit yet I would encourage you to check it out. There are a lot of common patterns and tons of reusable code in the toolkit that applies for many scenarios besides the gaming space. With more and more applications relying on real-time communication, sharing, and feedback the mechanisms that are used in games can be applied to many kinds of software.

Github

Since we started this project Github has become an increasingly popular place to host the open source projects. Additionally, the Windows Azure SDKs are now open sourced and available on Github. We have seen a great deal of support from the community in this move and believe that Github is the right place to host this toolkit. Our hope is that with the amazing support Github offers for social coding such as forking, pull requests, etc. more users will be able to utilize and contribute to this project.

For those of you that have not used git or Github before I highly recommend watching the Mastering Git video on Tekpub. It costs $15, but it is worth it if you like learning though videos. If you like learning by doing and reading the instructions Github has a great set of help documentation on there site.

Cloning a Repository

Rather than simply downloading the zip or self-extracting package of the Social Gaming Toolkit, you may want to clone the repository. Doing this will make it easier to pull in changes when we release future updates. It also allows you to make local changes to the toolkit and still update code that changes in future versions without loosing all your work.

In order to clone a repository first you must have git installed on your computer. You can download git here. After you have git installed simply open the command prompt and clone the repository using the following command.

git clone git@github.com:WindowsAzure-Toolkits/wa-toolkit-games.git

Forking a Project

One of the best features of Github is that you can easily fork projects and make your own edits. If you use this toolkit and want to keep your own version simply create a fork and make your edits. Additionally, if you make a change that you think everyone would benefit from simply send a pull request and request that we add your change to our fork.

Forking a repository is easy. Simply click the fork button and select where you want the fork to live.

After you have forked the project, you can push changed to your own repository. If you have a change that you want to be added to the original repository all you have to do is send a pull request.

If your pull request is accepted, your changes will be added to the original repository for everybody to use. Feel free to add features or fix any bugs you find and send us a pull request.

As always, feel free to leave comments, feedback, or suggestions. I would love to hear how you are using the toolkit and what you think about using Github.

This is more of a note to myself, but I thought others may find it useful. You can use the Process Explorer tool that is part of SysInternals to figure out which program is holding the lock on your file and kill it. Very handy.

This release is a ‘beta’ release because it did not go through our full QA process, but all the tests pass and it should be stable. I will be releasing a stable version of the 1.2.x branch shortly that has undergone the full QA tests to ensure the quality is up to par.

The biggest changes in this release is that we are now using dependency injection throughout the solution. The toolkit uses the great Autofac library for injection, but you could easily swap out another library if you prefer.

Below you will see how we setup MVC3 and the WCF Web APIs to use Autofac for DI.

// Setup AutoFac
var builder = new ContainerBuilder();
DependancySetup(builder);
var container = builder.Build();

DependencyResolver.SetResolver(
new AutofacDependencyResolver(container));

// Setup WCF Web API Config
var config = new WebApiConfiguration();
config.EnableTestClient = true;
config.CreateInstance = ((t, i, h) =>
DependencyResolver.Current.GetService(t));
RouteTable.Routes.SetDefaultHttpConfiguration(config);

Additionally, we updated all the Nuget packages to their most recent versions. This includes the WCF Web APIs to Preview 6 and jQuery to version 1.7.1. Finally, we fixed a few bugs. There was a memory leak that some people were seeing in the worker role that should be fixed.

Download and deploy the toolkit to Windows Azure today. Let me know if you have any feedback, questions, or if you find any bugs.

Benjamin Guinebertière discovered the performance issues and was kind enough to share the results. Benjamin noticed that the response time between when the server gets a request to the time when the response begins was about 4 seconds. You can see this below by measuring the difference between “ServerGotRequest” and “ServerBeginResponse”.

Request Count:  1
Bytes Sent:     3 011	(headers:2938; body:73)
Bytes Received: 228	(headers:225; body:3)

ACTUAL PERFORMANCE
--------------
ClientConnected:    	16:33:24.848
ClientBeginRequest: 	16:33:45.247
ClientDoneRequest:   	16:33:45.247
Determine Gateway:  	0ms
DNS Lookup:           	0ms
TCP/IP Connect:      	1ms
HTTPS Handshake: 	0ms
ServerConnected:   	16:33:45.249
FiddlerBeginRequest:  	16:33:45.249
ServerGotRequest: 	16:33:45.249
ServerBeginResponse: 	16:33:49.973
ServerDoneResponse: 	16:33:49.973
ClientBeginResponse: 	16:33:49.973
ClientDoneResponse:   	16:33:49.973

Overall Elapsed:     	00:00:04.7260980

RESPONSE CODES
--------------
HTTP/200:		1

RESPONSE BYTES (by Content-Type)
--------------
       ~headers~:	225
application/json:	3

Benjamin setup and ran some tests to investigate the bottleneck. You can see how he added the traces below.

The results of this trace are show below. Notice that the action takes less than half a second to run. This meant that there was something outside of the action that was causing the problem.

After some investigation we discovered that we were calling the EnsureExists() method on every request in the game service. This was a mistake on our part and definitely not a best practice. You can see how the EnsureExists() method is called every time the repository is instantiated.

public GameRepository(
    IAzureBlobContainer gameContainer,
    IAzureBlobContainer gameQueueContainer,
    IAzureQueue skirmishGameMessageQueue,
    IAzureQueue leaveGameMessageQueue,
    IAzureBlobContainer userContainer,
    IAzureQueue inviteQueue)
{
    this.skirmishGameQueue = skirmishGameMessageQueue;
    this.leaveGameQueue = leaveGameMessageQueue;

    this.gameContainer = gameContainer;
    this.gameContainer.EnsureExist(true);

    this.gameQueueContainer = gameQueueContainer;
    this.gameQueueContainer.EnsureExist(true);

    this.userContainer = userContainer;
    this.userContainer.EnsureExist(true);

    this.inviteQueue = inviteQueue;
    this.inviteQueue.EnsureExist();
}

To fix this issue we created an EnsureExists() method on the GameRepository and moved all the queue and storage initialization methods there.

public void EnsureExist()
{
    this.gameContainer.EnsureExist(true);
    this.gameQueueContainer.EnsureExist(true);
    this.userContainer.EnsureExist(true);
    this.inviteQueue.EnsureExist();
    this.skirmishGameQueue.EnsureExist();
    this.leaveGameQueue.EnsureExist();
}

Next, we call this new method only once in our Global.asax Application_Startup. You can see that below.

protected void Application_Start()
{
    CloudStorageAccount.SetConfigurationSettingPublisher(
       (configName, configSetter) =>
    {
        string configuration = RoleEnvironment.IsAvailable ?
            RoleEnvironment
                 .GetConfigurationSettingValue(configName) :
            ConfigurationManager.AppSettings[configName];

        configSetter(configuration);
    });

    AreaRegistration.RegisterAllAreas();

    RegisterGlobalFilters(GlobalFilters.Filters);
    RegisterRoutes(RouteTable.Routes);

    FederatedAuthentication.ServiceConfigurationCreated +=
        this.OnServiceConfigurationCreated;

    // initialize blob and queue resources
    new GameRepository().EnsureExist();
    new UserRepository().EnsureExist();
}

After these changes the time for a request went down to less than 2 seconds. You can see the request and response times below.

This is a good improvement, but there are still several more changes like this we can do. I hope to release a new version in the next week or so that improves performance even more. Until then, give the updated version a try and let me know if you have any feedback.