I have approached this problem in a different manner

I have gui.pl start compute.pl via a start system call.

system("start perl compute.pl -arg1 arg2 arg3 arg4 sourcefile.txt > de
+stinationfile.txt" );
[download]

I then have compute.pl write its progress to a file(not at the ms level), and when done write a completion message to that file. I then use another gui (gui2.pl) program to print that file to the browser (this can have a auto refresh if you like). The first gui.pl then tells the browser what the new gui address is (i pass a parm to the gui2.pl that tells it what file to monitor http://../gui2.pl?file=tracker_file). Now i had programs that took days to finish, and that was way beyond the timeout limit of a cgi session, and you wouldnt want an auto refresh either. the user just refreshed the gui2.pl page whenever they wanted to check if its done.

Ive been doing it this way for over a decade. i have little modules that make it easy to do. gui2.pl takes a specially crafted file that contains elements for many table-sections. One section displays timestamps at various milestones (input done@time, first phase done @time...), another section often displays record counts or patient counts as the process continues, and a third section displays informational progress methods. It can have as many tables as you want, and they are displayed in order of the first reference to them. Often i have warning messages displayed first, with a button that can cause the task to be terminated if the user doesnt feel the progress is viable. This requires compute.pl to record its "task id" into the tracking file so gui2.pl knows what to cancel. For the lack of a better name i now call this module websee.pm

This is an example a line is a ctime, <space> <cmd> <space> <rest>

cmd=$s gives the pid.

cmd=P prints <rest> in the bottom section

cmd=T is a table, <rest> is taken to be a <table-name> <space> <row-name> <space> <col-name> <space> <col-contents>

1483271066 $s 3880 1483271066
1483271066 P started
1483271066 T table step started 2017-01-01-05-44-26
1483271067 T table copied started 000:00:01 000:00:01
1483271067 P d-time:000:00:01 000:00:01->auto:started:copied
1483271067 T table copied ended 000:00:00 000:00:01
1483271067 P d-time:000:00:00 000:00:01->auto:ended:copied
1483271067 T table blind_scrape_4a-setup.pl started 000:00:00 000:00:0
+1
1483271067 P d-time:000:00:00 000:00:01->auto:started:blind_scrape_4a-
+setup.pl
1483271067 T table blind_scrape_4a-setup.pl ended 000:00:00 000:00:01
1483271067 P d-time:000:00:00 000:00:01->auto:ended:blind_scrape_4a-se
+tup.pl
1483271067 T table blind_scrape_4b-worksish.pl started 000:00:00 000:0
+0:01
1483271067 P d-time:000:00:00 000:00:01->auto:started:blind_scrape_4b-
+worksish.pl
1483271701 T table blind_scrape_4b-worksish.pl ended 000:10:34 000:10:
+35
1483272144 P Ended
1483272145 $e 3880 1483272145
[download]

That produced a simple page, the $s creates the "kill-button" at the top. it exists till it finds the $e line.

It has one table "table" with 4 rows and two columns (started/ended), and the contents of the cells are formatted time pairs. The first is the interstep time and the second is the cumulative time.

Under the tables, the cmd=P lines are listed

This may be extreme for your case, but it has served me well since the late 90's. Like i said, some jobs ran for days, one ran for a week, Ive used this on windows and unixen. The process of "spawning" the separate command on unixen has used "at" and other queue managers. On windows ive just used start.