Let me assume that currently you have a single screen, the user hits some kind of 'go' button, maybe 10 seconds later they get a reply.

The basic idea is to break this into three screens.  The user hits the go button; the code behind launches the long running process on an independant thread and immediately returns the user a new screen saying "Your request is being actioned", every couple seconds this new screen polls the server to see if the long process is done yet.  When it is (after about 10 seconds) they are sent to the results screen.  This replaces loooonnnnggg calls that clog up the server with several much shorter requests that fly through, and a long running process that goes on the side.  This article describes it http://msdn.microsoft.com/en-us/library/ms979200.aspx.

It's still possible that several people will demand this simultaneously, they might see the "Your request is being actioned",  page for a while.  Everyone else's (small) requests should carry on flying through.

Turns out the polling approach certainly has its advantages.  We are using this approach for many long running scenarios.  It is not a silver bullet however.  A single worker process can only handle so much load even though requests maybe quick.  It seems a good fail-safe is to still have multiple worker processes in case one gets bogged down.  The combination of the two is really powerful however.