Bugzilla – Bug 3579
takes over 4 seconds to start a single job with 4.0.1 branch container
Last modified: 2006-10-02 14:33:12
You need to log in before you can comment on or make changes to this bug.
I built the 4.0.1 branch on a Mac G5 running Mac OS/X and I fired up a container. I then timed how long it would take to run /usr/bin/true 100 times: --------------------------------------------------------------------------- echo start singlejob without delegation: `date` |& tee >> timingdelegation.$$.log set i=1 while ($i <= $MAX) echo iteration $i of $MAX globusrun-ws -submit -q \ -F https://208.176.63.5:5656/wsrf/services/ManagedJobFactoryService \ -c /usr/bin/true @ i++ end echo " end singlejob without delegation:" `date` |& tee >> timingdelegation.$$.log --------------------------------------------------------------------------- Here is the output from that experiment: start singlejob without delegation: Mon Jul 18 12:09:38 CDT 2005 end singlejob without delegation: Mon Jul 18 12:16:21 CDT 2005 By my calculations it took 6mins,42secs or 402secs to run /usr/bin/true 100 times. It's been explained to me that running the job as I did above does *not* trigger delegation. I shared these results with Joe Link (author of globusrun-ws) and he was suprised. When he was testing globusrun-ws performance on his laptop (an IBM running a VM) he was able to run many jobs in a second. Is the performance that I'm seeing (>4secs/job) because I'm running on a Mac? Can someone please try the code snipet above on a non-Mac system to see if they get the same results?
I just ran this on my 2 GHz AMD Athlon(tm) 64 3200+ (using 32bit Linux) box and got 3 minutes 27 seconds (or 207 seconds) for 100 jobs. I also reran with the container still up to avoid the Java startup penalty and got 200 seconds. If you want to see if there is a specific bottleneck, you can turn on the performance timing debug statements in the Java code. See the following documentation link for details: http://www-unix.globus.org/toolkit/docs/4.0/execution/wsgram/developer-index.html#id2842414
This doesn't appear to be reproducible.