Dotmad.net

During a design meeting of a new project the issue of performance is raised.

This is the theoretical (worst-case scenario) performance requirement:

As existing frameworks and 3rd party tools don’t match these requirements, new frameworks will be developed.

After spending many men-months on developing new frameworks (even before the development of the application itself) this is the application’s performance:

Eventually the application is shipped, and customers are satisfied with the performance.

However, this is the average case performance requirement:

(NIH = “not invented here”, a common syndrome in the software industry leading to spending resources to create new tools instead of using existing ones)

Usually I use my desktop computer to surf the web, but recently I decided I want to be able to also use my mobile computer at home, and this require network access.

At first I inquired about using WIFI access, but there is a major downside to this for me: I don’t want the router to broadcast a signal while I don’t need it (both to save energy and to avoid an extra EM field around the house).

So I thought about using Bluetooth:

• Easy to turn on and off
• Cheap (50-100nis for a BT adapter for my desktop)

I usually use the mobile computer about 6-7 meters from my desktop, through a plaster wall, so that’s well within the specifications. I now manage to get 150kb per second download speed, and I’m writing this post from the laptop.

I had few problems establishing the internet sharing, but thanks to the good manager of the Israeli broadband forum at Tapuz I found an excellent guidance document for configuring ICS.

Highly recommended, even for non-Hebrew speakers (as there are screen-shots):

1. Setting the server for WinXP (desktop)
2. Setting the client for WinXP (laptop)

After creating a custom UDP mulitcast channel using WCF I ran some tests. I used this sample data contract class:

string Name
string Description
ushort Id
double X
double Y
double VX
double VY
uint Flags
DateTime CreatedTime
DateTime UpdateTime

Benchmark Results:

• Max amount of sent objects per second using 100mbit hub (using Intel 3Ghz HT CPU - not dual core): 46000
• CPU load during peak sending - 15-25%
• Effect of zip encoding - 50% less bandwidth with random values (probably 60-70% reduction in a real-world scenario)
• Sending 10000 objects per second - no significant CPU load (3-5% for both apps), GC load - less than 0.5%

I recently needed to build a WCF UDP application as a proof of concept.

Sadly UDP is not among the channels bundled with the WCF, so I needed to put up something myself:

• Downloaded the WCF technology samples, containing a UDP transport demo (there used to be a sample at the netfx3 site, but it’s long-gone)
• Copied the UDP transport sample project (from the folder \Extensibility\Transport\Udp\Cs\UdpTransport) into my solution
• Added the extensions section to the config file to add the UDP support (config file coming up soon)
• Added multicast=”true” switch to the binding section
• The address prefix is hardcoded in the UdpChannelHelpers.cs file, so if you like something other than “soap.udp” you need to edit the “Scheme” constant.
• Since UDP is limited by a 64kb packet size, you may also want to use the GZipEncoder (found in \Extensibility\MessageEncoder\Compression\CS\GZipEncoder)

You need to remember that since this is multicast, the client is the one doing the transmitting while the service is a only a passive listener.

Client configuration:

<configuration>    <system.serviceModel>

      <extensions>        <bindingElementExtensions>          <add name="udpTransport" type="Microsoft.ServiceModel.Samples.UdpTransportElement, UdpTransport" />        </bindingElementExtensions>        <bindingExtensions>          <add name="sampleProfileUdpBinding" type="Microsoft.ServiceModel.Samples.SampleProfileUdpBindingCollectionElement, UdpTransport" />        </bindingExtensions>      </extensions>

      <client>        <endpoint address="net.udp://225.225.0.1:2222/Observer/"          binding="customBinding"          bindingConfiguration="DatagramServer" contract="DataContracts.IObserver"          name="ClientService" />      </client>

      <bindings>        <customBinding>          <binding name="DatagramServer">            <binaryMessageEncoding></binaryMessageEncoding>            <udpTransport multicast="true" />          </binding>        </customBinding>      </bindings>

    </system.serviceModel></configuration>

Service configuration:

<configuration>    <system.serviceModel>

      <extensions>        <bindingElementExtensions>          <add name="udpTransport" type="Microsoft.ServiceModel.Samples.UdpTransportElement, UdpTransport" />        </bindingElementExtensions>        <bindingExtensions>          <add name="sampleProfileUdpBinding" type="Microsoft.ServiceModel.Samples.SampleProfileUdpBindingCollectionElement, UdpTransport" />        </bindingExtensions>      </extensions>

      <services>            <service name="ObserverService.Observer">              <endpoint address="net.udp://225.225.0.1:2222/Observer/"                   binding="customBinding"                  bindingConfiguration="DatagramServer"                  contract="DataContracts.IObserver" />            </service>       </services>      <bindings>        <customBinding>          <binding name="DatagramServer">            <binaryMessageEncoding></binaryMessageEncoding>            <udpTransport multicast="true" />          </binding>        </customBinding>      </bindings>    </system.serviceModel>

</configuration>

The application I’m working on is a C4I, GIS based application, originally written in framework 1.1.

Recently we did several tests to prove the improvements derived from upgrading to framework 2.0 (or 3.0) without doing major changes in the base code. The performance improvement focus was on switching to Generics for collections containing value types.

Possible pitfalls - mostly the usage of Hashtable and other 1.1 collections, which tend to return NULL when the key is not found. Unlike them, the Dictionary class and similar generic collections tend to throw exceptions if the key is not found. This requires adding calls to the ContainsKey method to prevent these exceptions. Nothing complicated, but a lot of manual labour.

Performance improvements (also with some minor refactoring):

• CPU usage in heavy-load-scenarios was reduced by 10-20%
• Time in GC (as measured by perfmon) was reduced to half of the previous value