Very slow "Insert from URL"

[Tompa79]

At our office we were very glad of this new "Insert from URL" scriptstep, because we could replace:

 

Webviewer->Pause->Parse result from getlayoutobject...

 

with just 

 

Parse "Insert from URL". 

 

BUT

 

Now it seems like in some cases, this is VERY much slower for some reason, that we can´t figure out.

 

We have a mixed OS environment, some run mac and some run Win 7 (+ virtual XP) I am on a win7.

 

 

Here is the story.

 

 

I first encountered that I hade like more than 10 sec pause (not responding) when calling this script step. I also got a dialog saying something like waiting for http request. This went on for a day. The next day, I had the same problem for like three times, after that lightning fast - can't reproduce the problem. So then I hear that my salesman collegue has trouble demoing some of our system due to very slow performance on just those portions that use Insert from URL. On his Win7 this is slow everytime, and has now been so for quite som time (several days). I asked another win7 collegue to test - also slow - can not get it fast.

I also tried in virtual XP mode on my computer and it is also fast.

 

This has never been an issue for my collegues on macs.

 

Simply: On most of our win7 machines, Insert from URL, takes +10 seconds to complete, regardless of address used.

(We tried with IP instead of dns name, we tried local files, etc)

 

Has anyone else had this problem or any ideas that might help?

 

Thanks! 

 

/Tomas

[Tompa79]

Ok, now I can answer this myself. At least partly.

 

Both of my win7 collegues had windows defender installed, with "real time protection" enabled. Turning that off and it's fast as it should be.

 

This does not explain why I had the problem earlier, since I have AVG anti virus (free) installed and not windows defender. 

 

Thanks for reading!

[Wim Decorte]

Thanks for posting back with what you found!

[Tompa79]

Ok, some update on this...

Mostly, Insert From URL has worked fine for us, but last week, we had serious slow downs on two separate machines (server 2008), running regular Insert From URL:s - Both of them got very slow when using Insert From URL. These two machines is not connected in any way and run on two separare networks/customers. We have a backup plan for this, whick is Troi URL - this made them go as fast as they should again. 

We suspect some update to windows/explorer made this happen, since it happened at around the same time on two machines.

has anyone else experienced this? 

[dansmith65]

Wow, thanks for posting this; I run Windows 7 on my development machine and I've always experienced the same issue. I use Avira Antivirus Pro with real-time protection enabled. Disabling real-time protection caused the Insert from URL step to run approx. 10 seconds faster.

 

Same as you; using a plug-in instead of the Insert from URL step doesn't have the delay with or without real-time protection enabled.

[Marc Hill]

I'm experiencing very uneven performance with the Insert from URL script step with iPads.  We use stand alone devices in the field and they sync with our server using Insert from URL (we set a field with a delimited string of data and then execute a script to parse the information).  We used to use a web viewer and screen scrape as described above as well and thought that this new script step would solve many issues we've had with that transport mechanism.  I've been trying to determine the cause, but it is not something I seem to be able to reproduce.  My users tell me that it will work fine, then all of a sudden it will take a long time (minutes instead of seconds).  And in some cases, it gets stuck (an endless spinning wheel) and FMGo needs to be terminated and restarted to get back on track.  My first thought was that the processing scripts were the culprits...they have loops in them so perhaps they received truncated data and were in a loop that couldn't exit as a result.  But when I try to reproduce the issue, it works fine for me with the same data. 

 

Has anyone experienced anything like this?  Any suggestions on where I might look for more information? 

 

Thanks in advance for any help.

[Wim Decorte]

I don't think there is a mystery here; your iPads are roaming about so they'll sometimes be in areas where the connectivity is spotty...

 

How long does the process take when there is a very good connection?

[Marc Hill]

Wim,

 

Thanks for the response.  It's difficult to have a certain answer to your question.  I've experienced great results both on LTE and wifi, but that's been either in my office or at home.  Our users are truck drivers, so they aren't necessarily able to provide me with the best feedback for that sort of thing.  These devices are used almost exclusively on a college campus where both mobile signal strength and wifi are pretty reliable, but I'm not in the truck with them when it happens (perhaps I will have to in order to determine criteria for the issue).  Does Insert from URL simply hang on "forever" (no timeout) if it thinks it has a connection?

 

As I mentioned before, we used to use a web viewer to transport data, and we had pretty good success with it...but we also had it on a timer so if we didn't get the response we sought, it would move on after a few seconds.

 

Again, I appreciate the feedback.

[Wim Decorte]

 

 

Does Insert from URL simply hang on "forever" (no timeout) if it thinks it has a connection?

 

 

That's the main difference between "insert from URL" and using the web viewer.  In a script, once you tell the web-viewer to do something, the script moves right along, it does not wait for the web viewer to finish.

Whereas the "insert from URL" will hold up FMP because it needs the result of that step before it can move on to the next step.

[ShadowVote]

For me both the webviewer and the insert from url can screw up on windows whereas so far it is working without hangs on osx (one day)

After scraping a web page about 1000 times (with a one second timer between) windows fm hangs down whereas osx does not. win 8pro fm12 or fm13, I guess ms explorer has a memory leak.