3 Replies Latest reply on Dec 4, 2014 5:40 AM by TSGal

    Inconsistently slow Insert from URL on FMGo



      Inconsistently slow Insert from URL on FMGo


      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.  Using httppost, we set a field with a delimited string of data and then execute a script to parse the information.  The php files will send a result of "Error" if there was a problem, "Success" if the server action was OK, or a delimited string of data response (when applicable) that is parsed on the iPad. 

      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.  It is also not consistent among users (they are all using the same database on stand alone devices and some will have no issues, while others will experience problems).

      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.

        • 1. Re: Inconsistently slow Insert from URL on FMGo

          Marc Hill:

          Thank you for your post.

          For clarification, when the users restart to "get back on track", does performance return to normal?  Or, is there still a lag?

          Does this issue appear more often among a specific group of users or just a particular user?  Or, is it spread out amongst all users?

          The next time this occurs, have the user write down the approximate time FileMaker Go was running.  For instance, I've encountered users who have FileMaker Go running all the time, even when no file is being accessed.  Also, have the user write down the other apps that are running.

          There have been several posts of FileMaker Go entering a bad state after an extended period of time.  Some of these symptoms include global variables not being updated, and just general slowness, so your experience may be connected.

          Any other information you can provide may be helpful in narrowing down the possible causes.

          FileMaker, Inc.

          • 2. Re: Inconsistently slow Insert from URL on FMGo


            Thanks for the quick response.  Answers to your questions:

            Performance return to normal or still a lag?  I don't have a great answer for this right now.  I'll ask a bit more tomorrow when drivers are back.  Anecdotally, I've heard that some users may experience it once or twice during the day, while others may have the issue for the entire morning or day.  They have been instructed to reset when it doesn't come back within 30 seconds or so, but I don't know if this happens consistently.

            Specific User vs. All?  It seems to happen with everyone inconsistently.  One day, Group A are having problems while Group B are not.  Other days, the reverse is true.  I've tried narrowing it down based on some of the functions that are performed, but I can find no smoking gun at this point.

            Some additional info: 

            We do have an "Exit Application" button in our database that staff are supposed to press when they are done for the day. While it doesn't take down the app, it does quit the database.  I can't say that all staff adhere to this rule, but I know some do.  Should they be killing the app every day?

            These iPads are used on a college campus and are equipped with both mobile data and wifi.  Signal strength is strong for both in the area, but I'm not sure about the "transitions" between the two (i.e. - I leave a building and drop wifi; then LTE picks up). 

            We tested the Insert from URL step extensively prior to releasing it to our staff.  I experienced no issues with it on my Mac or on the iPad I used for testing.  However, I was not load testing at that time (just me as a single user).  We can have up to 15 or so devices using this communication method on any given day.

            During testing, I tried sending around 4,000,000+ characters through a single httppost.  In that case, I received a sever php 30 second time out error.  We don't receive that error with this issue.  It will simply stall on the "Transfer URL Data" screen and spin.  Is it possible that its connection and then FMGo just doesn't know what to do? 

            I will get with our staff and have them log particulars when it occurs.  We are also going to experiment with some other ideas and if we get any tangible results, I will post them here.

            • 3. Re: Inconsistently slow Insert from URL on FMGo

              Marc Hill:

              Although our Testing and Development departments cannot reproduce, there have been a number reports where FileMaker Go gets into a strange state with extended usage.  It doesn't matter which database file is being used.  So, even though "Exit Application" script step will not exit the application on any iOS device, I would suggest notifying your users that when they experience this issue, restart the application; not just closing and opening the file.  Ask them to report back if performance returns to normal.

              See if this helps you may suggest to users to restart FileMaker Gothe Exit Application  FileMaker Go getting into a state after extended usage.

              Many web servers cannot handle HTTPPOST requests larger than 2 MB, so first, I would test sending 1 MB of data to see if it works, and then increase to 2 MB data, and then increase to 4MB data.

              Continue to keep me updated with any progress.

              FileMaker, Inc.