Hi Stephan -- just to clarify a bit: with your paid plan, you have two worker processes handling requests to your website.
When a user makes a request, the worker process that handles it is tied up processing, and doesn't handle any other requests until it's done. That means that you still have one process handling requests -- but then, if another user makes a request, then both will be tied up and your website will be unresponsive. (There's also a bit of logic in the way request dispatching works that means that requests from a particular browser tend to be sent to the same worker process -- so you might see situations where it looks like the site is generally unresponsive when only one of the long-running requests is being handled, if you check its responsiveness in a different tab in the same browser as the one where you've triggered the long-running request. You can see something closer to the reality of what's happening if you use two separate browsers.)
Anyway, clearly you could "solve" the problem by adding extra workers -- you can upgrade to an account with more workers from the "Account" page. This is probably the easiest solution, but might be expensive.
The alternative that Glenn is suggesting is that you have a scheduled task that is always running by using this trick. It keeps an eye on a database table, looking for new entries. When your website wants one of these time-consuming things done, you hit a view that writes something to that table, and then display something like "working on it" to the user. Your code on the front-end then keeps hitting a view saying "is it done yet?" repeatedly. That view, when the task is completed, can return the result.
In the background, when the scheduled task sees a new job in the database table, it pulls it off, does the calculations, and then writes the result back to the database for the polling view to pick up.
Does that make more sense?