More often we are deploying WCF services to be used by applications hosted in the same environment.  Traditionally we have opted to choose a binding mechanism and use it for external and internal applications connecting to our service. But wait…..are we really allowing our internal applications to perform as efficiently as possible?

The answer to this question is no.

This excellent article on WCF performance, from Terrance A. Snyder, shows the performance of various binding options in WCF.

By far the best channel is netTcpBinding for performance. Great! But netTcpBinding is a bit of a pig to get configured, so let’s demystify the steps involved in getting it setup.

Before we start, let’s get one thing clear.....Microsoft got configuration in WCF just about right. There, we said it! If you’re reading articles that start discussing significant code changes to support different WCF bindings, close your browser and go make a coffee (and don't open that site again!)

Still with us? Great…..let’s look at IIS and WCF configuration to support netTcpBinding.

There are several elements to supporting netTcpBinding in an IIS7 hosted application.

1.Windows Configuration

2.IIS Configuration

3.Service Configuration

4.Client Configuration

This following examples use a Windows 2008 R2 server, running IIS 7.

WINDOWS CONFIGURATION

1. From the Start menu, choose Control Panel.
2. Select Programs and Features.
3. Click Turn Windows Components on or Off.
4. Expand the Microsoft .NET Framework 3.5.1 node and check the Windows Communication Foundation Non-HTTP Activation feature.

CORRECTING IIS CONFIGURATION

If you install WCF Activation after IIS is installed or after you install .NET Framework 4.0 and above, you will need to refresh your IIS install by running the following command from a command prompt: 

aspnet_regiis -iru

IIS CONFIGURATION

The next stage is to configure your websites in IIS. First configure the bindings for the website. A net.tcp binding should have been created for the default website. You can add the required bindings to other websites manually using the IIS Manager, as shown below.

Alternatively, you can use Appcmd.exe, which is installed with the Internet Information Services 7.0 (IIS) management toolset. From an administrator-level command prompt, run the following command:

%windir%\system32\inetsrv\appcmd.exe set site "Default Web Site" -+bindings.[protocol='net.tcp',bindingInformation='808:*']

The net.tcp protocol needs to be added to the list of enabled protocols for the website. Using IIS Manager, select the website and click 'Advanced Settings'. Enter net.tcp as an additional enabled protocol. Each protocol should be separated with a comma.

Alternatively, you can use Appcmd.exe, which is installed with the Internet Information Services 7.0 (IIS) management toolset. From an administrator-level command prompt, run the following command:

%windir%\system32\inetsrv\appcmd.exe set app "Default Web Site/servicemodelsamples" /enabledProtocols:http,net.tcp

This completes the configuration of Windows and IIS to support net.tcp binding. 

WCF Service Configuration

The following steps outline the process to enable net.tcp binding for a WCF service. In addition we will outline a proven method for optimising the WCF net.tcp binding configurations, as outlined by this excellent article on WCF performance, from Terrance A. Snyder.

Service Definition

<services>
      <service name="NetTcpBindingExample.HelloWorldService">
        <endpoint binding="netTcpBinding" bindingConfiguration="max" contract="NetTcpBindingExample.IHelloWorldService"/>
        <endpoint address="mex" binding="wsHttpBinding" contract="IMetadataExchange" />
      </service>
</services>

Behaviour Definition

<behaviors>
      <serviceBehaviors>
        <behavior>
          <serviceMetadata httpGetEnabled="true"/>
          <serviceDebug includeExceptionDetailInFaults="true"/>

        </behavior>
      </serviceBehaviors>
</behaviors>

Binding Definition

Option 1 - basicHttpBinding -- Fast!

<basicHttpBinding>

        <binding name="max" maxBufferPoolSize="2147483647" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647">
          <readerQuotas maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxDepth="2147483647" maxNameTableCharCount="2147483647" maxStringContentLength="2147483647"/>
          <security mode="None"/>
        </binding>
</basicHttpBinding>

Option 2 - customBinding - Faster!

<customBinding>
        <binding name="binaryHttpBinding">
          <binaryMessageEncoding maxReadPoolSize="2147483647" maxSessionSize="2147483647" maxWritePoolSize="2147483647" />
          <httpTransport maxBufferPoolSize="2147483647" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647" decompressionEnabled="true"/>
        </binding>
</customBinding>

Option 3 - netTcpBinding - Fastest!

<netTcpBinding>
        <binding name="max" maxBufferPoolSize="2147483647" maxBufferSize="2147483647" maxConnections="2147483647" maxReceivedMessageSize="2147483647" listenBacklog="2147483647" transactionFlow="false">
          <readerQuotas maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxDepth="2147483647" maxNameTableCharCount="2147483647" maxStringContentLength="2147483647"/>
          <reliableSession enabled="false"/>
          <security mode="None"/>

        </binding>
</netTcpBinding>

That completes the WCF Service configuration - simple eh? Well actually, yes. You can choose between the different binding options above, but to get real performance for locally hosted services choose netTcpBinding everytime!

Client Configuration

The client configuration for the client application is very clean. A netTcpBinding is specified and the service endpoint is configured to use net.tcp://

<configuration>
    <system.serviceModel>

        <bindings>
            <netTcpBinding>
                   <binding name="max" maxBufferPoolSize="2147483647"
                                                    maxBufferSize="2147483647"
                                                    maxReceivedMessageSize="2147483647">
          <reliableSession enabled="false"/>
          <security mode="None"/>
        </binding>

      </netTcpBinding>
        </bindings>
        <client>
            <endpoint address="net.tcp://demo1.contoso.com:8080/HelloWorld.svc"
                      binding="netTcpBinding"
                      bindingConfiguration="max"
                      contract="HelloWorld.IHelloWorldService"
                      name="NetTcpBinding_IHelloWorldService" />
        </client>
    </system.serviceModel>

</configuration>

That completes the performance optimised netTcp configuration for a WCF service. To transition between services configured to use basic or web http binding only requires simple configuration change in Windows, IIS and the app.config or web.config files for the target services and clients. 

Simple, but effective WCF performance!

<script type="text/javascript" src="//ajax.googleapis.com/ajax/libs/jquery/1.3.1/jquery.min.js">

</script>

• http://www.stevesouders.com/blog/2010/02/10/5a-missing-schema-double-download/
• http://stackoverflow.com/questions/4831741/can-i-change-all-my-http-links-to-just

Here at Adactus we’re quite into web performance, after all we’re official Site Confidence partners and members of the performance alliance group in the UK.

Most of our development team are aware of some of the tools to hand such as Yahoo’s YSlow and Google’s PageSpeed add-ons for FireBug but after a recent training session with web performance evangelist Stephen Thair we decided to share some of the lessons learnt with the rest of the team.

One tool Stephen introduced us to was dynaTrace AJAX Edition which records your user journey through out a website and gives full performance analysis helping you tune your pages.

The idea of this blog post is to introduce you to dynaTrace application and give a gentle introduction to the analysis available – what makes this tool so good is its ease of use and the external web links provided to help you investigate potential performance bottle necks in your web app.

User Journey

Recording a user journey is straight forward and simple but before jumping straight in you first need to plan your route. When analysing websites and their performance it’s important to know your end users and the key journey points in your website. For example a generic ecommerce site would have a home page, category page, product page, profile login/registration, basket and checkout process.

By analysing your existing website statistics you can work out your key pages.

Once you’ve planned your journey open dynaTrace and click the FireFox icon near the top right – if it’s the first time you’ve run dynaTrace it’ll prompt you to create a new Run Configuration.

For this demo I’ve set the Name to Adactus Ltd and the URL to our web address.

Once done FireFox will open with the specified URL and it’s at this point your pre-planned site journey comes into action – browse your site to your planned journey and when complete close FireFox.

You’ll notice the Cockpit panel in dynaTrace will now list your journey:

Performance Report

If your familiar with YSlow you’ll instantly understand the Performance Report section.

It’s a great overview of the performance recorded during your user journey ranked from A (best / green) to F (worst / red) for the following sections:

• Summary
• Caching 
• Network 
• Server-Side
• JavaScript / AJAX
• Timeline
• Key Performance Indicators

The first bit of data you’ll see is the summary tab which provides a great overview of your site’s performance. First up is the speed rank which rates your site from A (great) to F (poor) in a set of pre-defined groups. If you’re familiar with YSlow you’ll feel instantly at home!

As already mentioned there are sub sections within the Performance Report, I’m not going to go into a lot of detail for these as they’re relatively self-explanatory and each tab has a useful link out to help decipher and interpret the results.

Caching

This tab will help identify any missing caching settings in your site.

For example the Adactus site was found to have five resources with no past date cache settings which the tool estimates a saving of 64.72kb in transfer and 1942.73ms download time.

Network

I see this as an overview to the number of HTTP calls with the more calls made the slower the site performance. For example we did a full performance report for one client who ended up with no less than 13 different CSS files and 7 JavaScript files creating a massive performance hit. If you ever find yourself in this situation look into minification and combing files (or give Adactus a call!).

Server-Side

By server side we mean the time to generate dynamic content which is typically database driven. There is a good top 10 article by dynaTrace listing the most common foibles experienced by websites:

http://blog.dynatrace.com/2010/06/15/top-10-performance-problems-taken-from-zappos-monster-and-co/

JavaScript / AJAX

Get a break down of your JavaScript calls and handlers – it’ll give you a breakdown of the call, the number of invocations and the total time in milliseconds.

Timeline

This is one of my favourite sections as it shows the time taken (in ms) for the page to render along with your computer’s CPU count. When completing your user journey the dynaTace application records every single page event be it mouse click, move, key events and more – these are all displayed in the timeline as shown in the example below. You can also drill into a specific section by clicking and dragging a time zone to investigate.

So what can we determine from the timeline?

• First up is the CPU counter – note this is based on your own personal computer – which is rated from the usual to 0 to 100%
• JavaScript shows the load time for specific resources and states the start time and duration to load and process
• Rendering is the canvas draw events on the web page along with the first render event the end user sees
• Network shows the external HTTP calls, i.e. Google Analytics or tracking tags etc
• Events shows the load event time, first impression and fully loaded times by simply hovering over the icons shown on the timeline

Another good feature is the ability to double click on a block to drill down into the specific event – dynaTrace have called this PurePaths which we’ll go into later.

KPI’s

This covers key performance indicators such as time to first impression (when the end user sees something on the web page), onLoad and fully loaded.

Timeline

This is similar to the timeline section covered above except it shows it for each page in your user journey.

PurePaths

There are two ways of getting to the PurePaths – first off you can double click an object or event in the timelines already discussed. Alternatively you can get a list of resources and their associated times by double clicking the PurePaths option in the Cockpit panel within the dynaTrace application.

Network

This report lists all the resources, whether the item was in the local cache, status, times, size [bytes] and more. It provides a great way of identifying slow resources or large scaled images on your site.

Hot Spots

This view shows the JavaScript and rending events from the browser and again dynaTrace allows you to drill down into a specific event by double clicking it.

For example if we double clicked the second event _default(*) the report will show you both the forward and backward traces. The back trace shows which JavaScript or DOM caused the browser to draw or alter the page layout helping you identify expensive layout calls. Another good feature is the applications ability to show you the code in question – perfect for performance overviews and suggestions.

Next Steps

Like I said, this is a quick blog overview but it’s worth trying out and reading the help sections on the dynaTrace community section.

You may know of some other tips and tricks, why not share them with us by posting your tips below.

It’s also worth following industry experts such as Stephen Thair and Joshua Bixby or your local performance group.

The final set of optimisation tips for your website are below - the next set of web optimisation blogs will look further into the tools available to help analyse and enhance performance.

Optimise your JavaScript

• Merge JavaScript files into a single file
• Minify JavaScript
• Remove comments and any whitespace

Expect to see a load time reduction of up to 15%.

The challenges are preserving functionality and maintenance. There are tools you can use to do this, ranging from online compression tools or the excellent YUI Compressor.

Make StyleSheets and JavaScript External Files

This allows the files to be cached by the user’s browser making subsequent load times faster.

Avoid Redirects

Redirects are additional requests for the server to process and delay the delivery of HTML content. Incorrect links also cause wasteful redirections, e.g. missing the trailing ‘/’ from the end of a URL.

Configure E-Tags

Entity tags are used by browsers to check if a cached resource matches the version on the server.

Note E-Tags do not work within an IIS web farm but there is a nifty work around by simply setting them to an empty string.

Some more basic web performance tips for you today - we'll post some more tips and shortly we'll add some content on further web analysis.

StyleSheets

Put these at the top of your page – whilst it doesn’t affect the load time it does affect the render time of the page. This tip makes pages appear to load quicker, especially IE browsers which wait until all the StyleSheet are loaded before rendering a page.

This also avoids white screen phenomenon or un-styled content appearing.

And yes… StyleSheet should only be included in your page’s <head> tag.

Script Placement

The opposite of the previous StyleSheet tip – place all your scripts at the end of the page. Having scripts at the top of the page blocks other content downloading or being rendered beneath the script. Ideally you’d use asynchronous JavaScript loading.

Optimise your CSS

Optimising your CSS can give a good performance improvement for your website:

• Merge StyleSheets into single file
• Minify CSS in StyleSheet
• Place StyleSheet at beginning of HTML
• Page render starts after all StyleSheets are loaded
• Avoid CSS Expressions

Doing this could reduce start-up rendering by 75%.

Once a fortnight the developers at Adactus get together to discuss the latest design and development practises or new technologies, the most recent of which was run by team lead Rob Bird who gave an overview of web performance optimisation. The page load time of today’s web pages has a much larger impact than it did say 5 years ago – as end user’s internet connections get faster their expectations of your website’s performance increase.  All it takes is one slow user experience and the user is unlikely to come back or recommend your site.

So just how can you improve your website’s performance?

To be honest there are a lot of factors to consider, both front end in your website code, design and implementation all the way to your web and database servers. Over the next few weeks we will post a top tip on how to help improve your site performance starting with a top tip selection leading onto some good tools to help identify potential performance bottlenecks. You may know some of the tips already but it’s always good to remind yourself!

For now here are three top tips:

Make Fewer HTTP Requests

It is estimated that you can reduce your website load by up to 15% by simply making less HTTP requests. This could be achieved by merging common images into sprites or reducing the number of CSS and JavaScript files etc. By making fewer calls the web browser has fewer requests to send to the host server.

Future Expires Header

By setting a future expiry date on your pages you can reduce repeat-view load times by more than 50% and HTTP requests by 90%! It simply enables the browser to cache the resources which reduces in less HTTP requests being sent. There is one caveat though; plan design and image updates to coincide with the set expiry date.

GZip Compression

If you’re using IIS6.0 this option is a little hidden, however it’s easier to find in ISS7.5. Either way it’s a quick performance improvement as it reduces the size of the HTML, JavaScript and StyleSheets being served from your web servers.

Further Reading

We'll be adding more tips over the next couple of weeks. If you can't wait though we can recommend reading the Adactus white paper capacity planning for high transaction Microsoft based eCommerce systems.  Another good source of information are two books written by Steve Soulders: High Performance Web Sites and Even Faster Web Sites, both of which are published by O’Reilly books.