Another “big picture” consideration is ... what do you do if the user impatiently mashes Reload?   If you are not careful, very soon you have a bunch of forked-processes all getting in one another’s way.

One simple-but-effective way to deal with this sort of thing is to define a database table as a work-to-do queue.   Your web-page simply adds a request record to this table, then provides the user with a way to monitor until (the database entry now says that) the work has been completed.

How does the work get completed?   How about a simple cron task that goes off once-a-minute?   The process that is fired works like this:

1. Check for the presence of a lockfile.   If one exists, exit.   (You’re a duplicate.)
2. Create a lockfile.   (There are CPAN modules for this ...)
3. Query the database for work to do.   If no (more) entries exist, remove the lockfile and exit.   Otherwise, select an entry, mark it “in progress,” do it, and then mark it “done.”
4. goto 3

You can get fancier than this, of course, but the bottom line is that there are entirely separate processes, periodically fired or always-running, which do the work, while the web-page monitors it (and provides the means to return results to the user).