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.)