GPServerSync.Load execution delay

Question

Hi, Long story short, does anyone know how to debug, or have any insight, into GPServerSync calls? I have a Python Geoprocessing Service I've published on ArcGIS Server 10.2. It's pretty basic; it takes a zipfile that's been uploaded already which contains a shapefile, it dissolves that shapefile, repairs the geometry, and then it returns a feature dataset. Executing this in ArcMap on my laptop takes about 600 milliseconds. In ArcGIS Server, it executes, but it takes about 7 minutes. I modified the service to output to my own logfile to see if there was a specific python call that was causing the delay, but it appears that once the script is actually executed, it really only takes a second. The issue is that there appears to be a several minutes long delay between when the job is submitted and when the script is actually run. ArcGIS Server verbose logs shows this. The request is issued at 10:43:30. 2 seconds later, there's an entry for GPServerSync.InitJob. The next logged item is GPServerSync.Load, which doesn't occur until 10:49:57, which is 6 and a half minutes later. The script then executes in less than a second. Any ideas? Ian GPServerSync.Activate REST request received. Request size is 99 characters. Load job message type REST message size 99 Load job j3e3c698147734869b66d0d87cdf1f3a4 message type REST message size 99 Load job j3e3c698147734869b66d0d87cdf1f3a4 message type REST message size 99 Execute job j3e3c698147734869b66d0d87cdf1f3a4 Save job j3e3c698147734869b66d0d87cdf1f3a4 message type REST message size 99 REST request successfully processed. Response size is 82880 characters. GPServerSync.Deactivate

IanHogan · Answer

Replying to myself for the benefit of future generations. You can thank me later.

It turns out that if the input file (which is a .zip file which contains 4 shapefile files) is named as a .zip when it's uploaded, then the script takes forever. However, If the exact same file is named something else (.txt, .jpg, whatever) when it's uploaded, then I can treat it as a .zip file anyways in the script despite its file extension and it executes immediately.

While it's possible this is an ESRI thing, I'm assuming that there must be something in our local environment on that machine that is doing .zip file scanning, but that's still undetermined at this point. Even that would be pretty random, since it's only a 38K file that contains 4 files, and what could possibly take 6.5 minutes to scan a 38K file?