A few comments...
As far as I can tell, the primary bottleneck for their application was the use of web services for some kind of data transfer between central servers and mobile devices. It appears that all their mobile devices were running some version of Windows CE / .NET Compact Framework. If this factor is constant, and there is no foreseeable need to support different client platforms, they should have used the much, much faster TCP Remoting instead of the slow Web Services.
TCP Remoting uses a compressed binary protocol over TCP, and would likely be just as fast as their old custom protocol, but would have saved them the trouble of having to rewrite the old protocol in ASP.NET. The only limitation of remoting is that, as of right now, it's only easily implementing on .NET-only solutions.
Web Services are great when you need a loosely coupled, platform independent solution. If, for instance, your clients were both Java and Windows based PDAs or cell phones, then Web Services are a good bet. Or, if you need to be able to expose the services from a variety of server platforms, then web services are a good bet.
It seems to me that it was a lack of knowledge, not a problem with the technology, which caused the poor performance in their application.
Their second problem had something to do with managing large numbers of objects. This is so vague, it could mean anything. As a general rule, managed frameworks like .NET are typically *better* at managing large numbers of objects because of the highly refined memory management routines. In addition, object creation in .NET is also typically faster than unmanaged runtimes.
At any rate, it's impossible to draw any conclusions from an article like this. You would figure a site like builder.com would include a few details.
|