3 Replies Latest reply on Apr 2, 2013 8:07 AM by DrewTenenholz

    Dramatic Speed Increase with Server Side Scripts




      I just wanted to share a considerable speed increase I am getting by changing methods when performing server side scripts. Previously I was running 25 scripts overnight that did various things such as imports, exports, updating records based on certain conditions and generating many reports. Most of these scripts were spread out to begin over a 12 hour period, but inevitably there would be overlap where several of them, about 4-6 would wind up running at the same time. As time went on and the system grew, I was finding that the 12 hours overnight was not enough time to complete all of the scripts. Then I changed methods to make one Master Script that contained all 25 subscripts. This ensured that each script would run after the previous one finished with no contention on the server itself. Now instead of the 25 scripts taking 12-16 hours to complete, they are all done in less than 2 hours. What a difference!


      I am running FMSA 11 on a Windows 2008 R2 Server.

      I set up email alerts in between each subscript so I can tell how long each one is taking, and if there are any errors.




        • 1. Re: Dramatic Speed Increase with Server Side Scripts

          Evan --


          I set up a similar system for a client with a 'Master' controller and sub-scripts.  It has been that way from the beginning, so I can't speak to performance increases.  I can say that I added a few features to the system that you might consider implementing:


          1) A table with a single record for each of the subscripts you want to run.  That contains a description of what the script does, as well as a scheduling setup with the interval the sub-script should run, the last date run and next date to be run, and a 1/0 flag to enable/disable this subscript from a user interface within the FileMaker system and thus not requiring FMServer Admin access.  This makes it possible for the admin user to decide to skip a specific run, or reschedule a subscript to run every week instead of every day.


          2) A Table with a log of everything the sub-scripts (and Master Script) do; kind of like an audit trail, but enhanced to make the sub-scripts leave a note indicating which logic they used to change a field value.  I'm a bit paranoid, so I also recorded the previous value in case I needed to manually roll it back.  I also use it as a way to figure out when the last successful run of a sub-script was, which can be a useful detail in isolating the subset of records which changed since the last subscript run which are the only records worth running some subscripts on.  I also create a final summary of the run's statistics as a record in this table with a full count of the number of mods, callouts, and errors encountered during the process.  This record shows up on the admin user's dashboard to let them know the process ran, and if there is anything they need to look at.  Going through the individual lines in the log also provides a 'hyperlink' to the record the sub-script says it knows is wrong, but doesn't know how to fix because we didn't work out that logic yet.


          3) A single record table with a master control field that prevents overlapping runs and gives the user a way to gracefully interrupt the Master process or any subscript.  Values are 1=ready to run, 2=running, 0=abort at next breakpioint.  Again, the user can control this from FileMaker instead of the Admin console.  This was created before FMServer Admin had the ability to abort an endless script loop which was underway within a Server-Side Script.


          Just some thoughts on elaborating the process....


          -- Drew Tenenholz

          • 2. Re: Dramatic Speed Increase with Server Side Scripts

            Thanks Drew, these are all good suggestions.


            How does the single record with the 0-2 values stop the master script? Do you have muttiple "if" statements between each break point in the Master script or do you have the subscripts checking this for the values at their own breakpoints?