Differences in programming idioms between Windows and UNIX overlooked by an ISV

A few months ago I worked on a project with a global ISV. The main purpose of this engagement was to review the integration of their product with MOSS (Microsoft Office SharPoint Server), including BDC (Business Data Catalog). This can be a subject of a separate post especially that it was also a good use case of interoperability and integration of SharePoint and BDC with GlassFish-hosted web services.

However, in this post I will focus on one finding that resulted from reviewing the product of this ISV from scalability perspective.

The reviewed server product works on Windows Server, but when I drilled into the architecture of one of the components, I learned that it originated in the previous generation of this product that was based on UNIX. This server component was responsible for handling requests from client applications and the ISV wanted to support hundreds of concurrent users. So I started asking questions suspecting that this component might have followed patterns characteristic for applications that originated many, many years ago in UNIX world. And I was right – this component was spinning a new OS process for each concurrent user. So when handling 200 concurrent users, there would be 200 processes created. So I explained to the ISV that this is not the best way to achieve top scalability on Windows platform. I pointed out that when components are migrated from UNIX to the Windows platform, there are some important differences in the OS process paradigm that need to be considered. Creating a new process in Windows is a relatively expensive operation while creating a new thread is not as expensive in terms of system resources like memory and time. And the concept of a thread pool allows reusing threads, thus reducing the existing overhead of thread creation. It doesn’t mean that every multiprocess-oriented application on UNIX that is being migrated to Windows should be re-architected to use threads instead. It depends on many factors, for instance the number of processes being created, frequency of process creation etc. But it is probably a safe bet that a UNIX application that creates dozens or hundreds of processes should be rearchitected to use threads from a thread pool on Windows. More information about process and thread management in context of migration of UNIX applications to Windows can be found in this article on TechNet. A functional comparison of UNIX and Windows is covered in this article on TechNet.

In case of this ISV I actually ended up recommending not just switching to using threads from a thread pool, but to use a thin layer of WCF-based services for cross-machine communications. These services would interop through P/Invoke with the existing unmanaged code, so it wouldn’t require any significant rewrite. My recommendation was based on several factors, such as the fact the implementation of the component being reviewed was vulnerable to buffer overrun attacks, didn’t support firewalls, run with admin privileges which created additional security risk and relied on security through obscurity. But this is a topic for another post.

Grzegorz Gogolowicz

Senior Solutions Architect

GISV Architecture Team

Comments

• Anonymous
  June 13, 2008
  Grzegorz shared one of his findings from an architecture review that he did some time ago for a global