How a poor business decision can lead to inferior technology implementation

Last week we were working with a large healthcare solution provider in the US who initially approached us to help them with some scalability and memory problems in their current system.
The client had migrated their solution from a COBOL- Mainframe solution to .NET+SQL Server, this was important since it reduced the TCO for their customers and their sales team were under tremendous pressure in the past selling a costly mainframe solution. However the business had not allocated enough time and budget for the IT team to do this migration. Based on the time and budget the IT group took the following route
· Move classic COBOL to NetCOBOL from Fijitsu – this was a good move since most of the COBOL code (millions of lines of COBOL) could be ported to .NET without much rewrite
· Moved data from flat files to SQL Server – done with good intension but to cut corners they migrated it in such a way that they would just use SQL Server as a store and leverage its indexing capability the SELECT queries being sent did not have JOINs (!!!) – all joins were being performed in the application tier. Ie multiple SQL SELECT queries were fired from the app tier to different SQL Server tables – the resulting data was manually joined within the app server. Huge number of .NET objects where created here.
· The front end for the application was written in VB.NET, however since they had to leverage the migrated COBOL code(Without code change) the front end would mimic the old mainframe dumb terminal which would not maintain state on their own and would require the server to maintain state.
· The remoting layer was implemented using client activated objects to facilitate state, the state was stored in app servers memory. The solution could not be scaled out because they had 2 problems
o Since the state was managed in the app servers memory the solution could not be scaled out
o Since the remoting was implemented using client activated objects (and not single call objects) it could not be scaled out.
They were getting an out of memory exception when they had 10-15 concurrent users but they were trying to sell the solution to a healthcare provider that needed a solution that could take on 100s of concurrent users – they were searching for a magic bullet that could fix their problem. Though we were able to identify the reason why they were running out of memory and make recommendations that could help scale the application slightly better without major code changes they can never meet the scalability requirements needed to make the sale.
Just another example of why companies should not give the technology decision to the business folks (the converse is also true :) ) . Had the company spent good time investigating the new technology and planned a good migration plan either on their own or with assistance from a technology partner they would not have faced this problem.

Multicores, the developer dilemma and Microsoft PFX

Thanks to Moores law developers never had to worry about how their application would perform with newer processors, with every newer-faster processor in the market their application 'automagically' just ran faster. This is all set to change Moores law will no longer apply to processors - adding more transistors to a processor is not feasible anymore since doing so is heating up the processor hence most of the processor manufacturers like Intel, AMD and IBM are going for multi core processor architecture. ie now individual processors will not have radically improved performance, high performance can be acheived by leveraging the multicores of the processor. Leveraging different cores on the processor is a challenge developers never had to face in the past.

So how do we write code that take advantage of multicores? Fortunately application servers like Microsoft IIS and SQL Server already ship with support for multicore but how can our applications leverage it? Relying on the developers to write code optimized for multicore would be too much to ask, the good folks at Microsoft are working on a framework (for managed code) that can greatly enhance developer productivity when targeting multicore systems. The framework is called the .NET PFX , the December 2007 CTP can be downloaded from here.
What do you do when you have an 8 core server around at your disposal … run PFX of course :) … beats running it off my dual core laptop. Have created a simple project that simulates computation work via 2 for loops, later the outer for loop was changed to a Parallel.For (new set of features in the PFX available in the System.Threading namespace)

The results are as follows:

When running the basic nested loop the overall operation takes 11792 milliseconds and as can be seen in the figure below only one core is being leveraged (behind the scene only one thread is being used)

When the same code is run using the PFX the same set of operations take 1746 milliseconds ie almost 1/10th the time taken in the previous case and as can be seen in the figure multiple cores are being used to complete the task (behind the scene multiple threads are being used)

This post demonstrates a simple case where the PFX can be used, in the future post we will take a look at using PFX (and PLINQ) to build more complex applications.