Design software as a long running process

Relying on restarts is bad software craftsmanship

I had an interesting discussion today about the differences between writing a Windows service in .NET and an ASP.NET web application. Somebody made a comment that Windows services were harder to write because you need to make sure you deal with memory properly in order to avoid memory leaks, whereas you didn't need to do this with an ASP.NET web application. In short, the perception was that Windows services are long running processes and that ASP.NET applications running under IIS aren't. There are several things to pick up on here.

First of all, .NET (like Java) is a managed platform that does its own garbage collection so you don't need to worry about explicitly allocating and disposing memory. Unless you're integrating with unmanaged code (e.g. older DLLs, COM objects, other native code, etc) you don't generally need to worry about low-level memory allocation.

Memory leaks *are* something that you need to worry about though and they're really easy to cause in .NET or Java applications. All you need to do is cache lots of data in static references, not dispose of resources you are using, etc. You're not really "leaking" memory, you're just storing it away somewhere and never reusing it again. If you're interested in this topic, InfoQ published a good article today called Dealing with Memory Leaks in .NET that digs into this some more.

The thing that I found the most surprising is the difference in how Windows services and ASP.NET applications are often viewed. A Windows service is clearly a long running process because once it's up and running, that's it until it gets restarted manually or from a system reboot. With a Windows service, any memory leak will start to become very obvious as the system slowly grinds to a halt and it's this that caused the comment about Windows services being harder to write. For some reason, ASP.NET applications aren't necessarily perceived as long running processes. With my Java background, I find this odd and several times people have mentioned that they rely on AppDomain recycling in IIS to prevent their applications from consuming too much memory. AppDomain recycling is essentially the same as what happens when you hot-deploy a web application on a Java EE server - drop the classloader and plug-in a new one to reload everything from a fresh state. For a moment then, let's think about what happens when an AppDomain behind an ASP.NET application is recycled in IIS (there's a much more detailed explanation here).

  • Any shared state in your application (e.g. stored by static variables) disappears. If you're caching frequently used data or data that takes a long time to calculate, then this will all vanish.
  • Any sessions backed by the in-process session store (i.e. in the AppDomain) get blasted.
  • You'll normally see a performance hit the next you hit the site as pages are reloaded and recompiled, connections are re-established, etc.

AppDomain recycling can have a fairly large overhead then, which brings me nicely onto the point of this. You're likely to have fewer issues in the future if you design every piece of software as a long running process. It doesn't matter whether you're building a Windows service, an ASP.NET web application or even a desktop application; you should always write code to avoid memory leaks rather than ignoring them. Relying on restarts or AppDomain recycling as a workaround for sloppy coding and memory leaks is not my idea of software craftsmanship.

About the author

Simon is an independent consultant specializing in software architecture, and the author of Software Architecture for Developers (a developer-friendly guide to software architecture, technical leadership and the balance with agility). He’s also the creator of the C4 software architecture model and the founder of Structurizr, which is a collection of open source and commercial tooling to help software teams visualise, document and explore their software architecture.

You can find Simon on Twitter at @simonbrown ... see for information about his speaking schedule, videos from past conferences and software architecture training.

Re: Design software as a long running process

Funny you should mention this. We had a discussion today about how our server processes restart every day but should also have been designed with the expectation of lasting for the week. The recent daylight savings changes in the UK and US on consecutive weeks are less likely to have tripped up applications with fewer expectations about how long they run for or reliance on specific start and end times.

Re: Design software as a long running process

Too Right. Infact, the main physical difference between the two at this level (or indeed between any web application and anything else) is the "statelessness" of web requests - e.g the logical method by which a form post is made and the results retrieved. While there are obviously 'stateful' implementations (or at least those which pretend to be) which we are all familiar with, just occasionally this can trip you up. In terms of the quality of engineering required and the way processes should be designed - I see no difference between a web app and anything else - they should all be as efficient and robust as possible!

Re: Design software as a long running process

Due to the non interactive nature of a 'Windows Service' users will often not get the feedback necessary to identify failures. It is often the lack of something that will identify a Windows Service failure unlike other interactive applications which fail in response to a users actions. This may be the nature of the diligence required to write non-interactive services?

Re: Design software as a long running process

It depends on who your "users" are but the feedback aspects do certainly require some thought, which is why thinking about the operational aspects and adding a fuel gauge are really important. As an aside, CruiseControl.NET takes a nice approach with its system tray application that gives you feedback that the service is or isn't working.

Re: Design software as a long running process

Although ironically one of the common issues introduced with fuel gauges (not criticising the approach - I believe they are vital) - is that too much time is spent on "features" and not enough on stability and telling the user if the service has failed! CCTray is pretty good at this, mind you - the grey icon of confusion is a dead giveaway that something has gone boing!

Add a comment Send a TrackBack