[Swift-devel] Support request: Swift jobs flooding uc-teragrid?
Ti Leggett
leggett at mcs.anl.gov
Wed Jan 30 10:00:36 CST 2008
On Jan 30, 2008, at 01/30/08 09:48 AM, Ben Clifford wrote:
[snip]
> No. The default behaviour when working with a user who is "just
> trying to
> get their stuff to run" is "screw this, use GRAM2 because it works".
>
> Its a self-reinforcing feedback loop, that will be broken at the point
> that it becomes easier for people to stick with GRAM4 than default
> back to
> GRAM2. I guess we need to keep trying every now and then and hope
> that one
> time it sticks ;-)
>
> --
Well this works to a point, but if falling back to a technology that
is known to not be scalable for your sizes results in killing a
machine, I, as a site admin, will eventually either a) deny you
service b) shut down the poorly performing service or c) all of the
above. So it's in your best interest to find and use those
technologies that are best suited to the task at hand so the users of
your software don't get nailed by (a).
In this case it seems to me that using WS-GRAM, extending WS-GRAM and/
or MDS to report site statistics, and/or modifying WS-GRAM to throttle
itself (think of how apache reports "Server busy. Try again later") is
the best path forward. For the short term, it seems that the Swift
developers should manually find those limits for sites that the users
use regularly for them to use, *and* educate their users on how to
identify that they could be adversely affecting a resource and
throttle themselves till the ideal, automated method is a usable
reality.
More information about the Swift-devel
mailing list