in reply to Queuing system for running a perl program

Let me please “harp on” my prior suggestion.   For one client, I prepared a formal research paper outlining the various batch processing / cluster processing systems that were available at that time.   And my recommendation was to buy one, because they had a tremendous amount of computational work to do and their home-grown cron stuff simply was not cutting the mustard.   Their problems were big, involved definite resource-contention scheduling concerns, and were mission-critical.   When you seriously start to “peel the onion-layers off of” this business requirement, you just keep finding more layers.   You have now touched upon only a few.   And that is precisely why I will again state that this has been done before; that it is more intricate than it first appears; and that it is an excellent “build vs. buy” decision.   It is extremely easy for a company to build a very costly and yet inferior solution because they didn’t want to spend any money.   The entirety of your requirement, including the PHP-driven screens that you now contemplate, might very well be bypassed completely.   (Interfaces that are specifically designed to snap-in to existing web applications are also common features.)

When you finally put into place a really-good workload management system, you will quickly wonder how you got along without one.   And, in my humble, this is probably a better buy decision than a build decision.   (Be careful about saying, “well, no, our situation is really not that complicated ...” because it most-assuredly will become so.)