For such a resource-intensive application, one solution is to email the results to the users - emails are less ephemeral than web-pages and so your users would be less likely to waste resources by recalculating a previously generated set of results.

By the same token, if your data changes relatively slowly, you could cache results keyed off a parameter/date combination - then you could just use the cache if asked for a result set you've already calculated (this hinges on being able to tell if the data has changed since the result was generated).

If you cache results, sending the results as emails no longer frees up resources, but your users will probably like it better anyway. Even 15 seconds is a long time to wait for a webpage to load - whereas getting an email in 60 seconds feels fast. It's all a question of expectations - people tend to wait for webpages, but will go about their business if told the results will be sent to them. Plus, I think an email is a more useful form - if the user wants to send the results to someone else, they just forward the email, instead of cutting and pasting...

BTW, a daemon might be better than a cron job because even if the cron job runs once a minute you're adding an average of 30 seconds delay to one minute of processing (selecting is better than polling).

---

Update
Obviously, caching is only worth implementing if users are likely to submit the same parameter values before the data changes.