GoZync3

Speed

GoZync3.Speed History

Hide minor edits - Show changes to output

August 05, 2013, at 04:24 AM by 50.132.84.245 -
Added line 11:
-> Even faster would be to upgrade to GoZync 4. It's a free upgrade. More here: [[http://www.seedcode.com/filemaker-sync-gozync/ | GoZync 4]].
August 05, 2013, at 04:23 AM by 50.132.84.245 -
Added lines 1-2:
(:include NewerDocs:)
April 28, 2013, at 06:23 PM by 50.132.84.245 -
Added lines 7-8:
-> [[Version History | Version 3.172]] of GoZync '''significantly''' improves the speed of pulling records. We highly recommend it to all users of 3.171.
Changed lines 15-16 from:
-> [[Version History | Version 3.172]] of GoZync '''significantly''' improves the speed of pulling records. We highly recommend it to all users of 3.171.
to:
April 28, 2013, at 06:23 PM by 50.132.84.245 -
Added lines 13-14:
-> [[Version History | Version 3.172]] of GoZync '''significantly''' improves the speed of pulling records. We highly recommend it to all users of 3.171.
April 01, 2013, at 03:55 PM by 50.132.84.245 -
Changed lines 39-40 from:
-> For the fastest possible upload from the mobile file, don't [[Zync Options | round trip]] unless you have to. When you round trip, the hosted inbox is processed using the iPad's resources (its slower CPU). Your users may have a more satisfying experience pushing data up, having a server side script process it, then reconnecting later to pull their data down.
to:
-> For the fastest possible upload from the mobile file, don't [[Zync Options | round trip]] unless you have to. When you round trip, the hosted inbox is processed using the iPad's resources (its slower CPU). Your users may have a more satisfying experience pushing data up, having a [[AutoProcessing | server side script process it]], then reconnecting later to pull their data down.
March 18, 2013, at 10:22 PM by 98.245.113.231 -
Changed lines 51-52 from:
-> If tables in your solution aren't absolutely dependent on each other, don't sync them as portals on a single sync layout. When you use portals on your sync layout, GoZync sends every portal record whenever the parent is modified. So if you have a patient and patient-visits, for example, having patient-visits as a portal on patients means we send *every* visit each time the patient or any visit changes. While portals are great for tables that MUST go together (like an invoice and it's line items) you'll get a faster sync in this patients-visits example if vists are their own sync layout.
to:
-> If tables in your solution aren't absolutely dependent on each other, don't sync them as portals on a single sync layout. When you use portals on your sync layout, GoZync sends every portal record whenever the parent is modified. So if you have a patient and patient-visits, for example, having patient-visits as a portal on patients means we send *every* visit each time the patient or any visit changes. While portals are great for tables that MUST go together (like an invoice and its line items) you'll get a faster sync in this patients-visits example if vists are their own sync layout.
March 16, 2013, at 08:23 PM by 50.132.84.245 -
Added lines 5-6:
'''General'''
Deleted lines 10-11:
-> Zync fewer records. Bring down only the data a user needs to see that day / week, etc. See [[downloading found sets]] for details on how to do this. This is probably the most important thing you can do to effect zync speed outside of getting  [[field level merge]] right (see below).
Added lines 13-20:
'''Found Sets'''

-> Zync fewer records. Bring down only the data a user needs to see that day / week, etc. See [[downloading found sets]] for details on how to do this. This is probably the most important thing you can do to effect zync speed outside of getting  [[field level merge]] right (see below).

-> Scripted finds on un-stored fields in the script [[DownloadingFoundSets | building your found set]] can be a slowdown. If you've modified that script check it out.

'''Photos'''

Changed lines 23-24 from:
-> For wide records, turn [[field level merge]] on. The more fields you have, that have data in those fields, the more of an impact field level merge makes.
to:
-> Even empty container fields have an impact on sync speed (empty regular fields do not) so instead of syncing 10 repeating container fields it can be faster to sync 1 related table with a single container field (a portal of containers instead of repeating fields).

'''Field Level Merge'''

-> [[Field Level Merge]] should be off in most cases for the fastest sync.

-> For wide records (records with LOTS of fields), turn field level merge on. The more fields you have with data in them
, the more of an impact field level merge makes.
Changed lines 37-42 from:
-> Don't [[Zync Options | round trip]] unless you have to. When you round trip, the hosted inbox is processed using the iPad's resources (its slower CPU). Your users may have a more satisfying experience pushing data up, having a server side script process it, then reconnecting later to pull their data down.

-> Zync fewer photos and videos.

-> For very large tables, consider [[
Turning Off Deletes | turning off]] GoZync's deleted records support. This can make pulls much faster.
to:
'''Round Trip'''

-> For the fastest possible upload from the mobile file, don't [[Zync Options | round trip]] unless you have to. When you round trip, the hosted inbox is processed using the iPad's resources (its slower CPU). Your users may have a more satisfying experience pushing data up, having a server side script process it, then reconnecting later to pull their data down.

'''
Turning off Deletes'''

-> For very large tables, consider [[Turning Off Deletes | turning off]] GoZync's deleted records support
. This can make pulls ''much'' faster.

'''Modular Sync'''

Changed lines 49-51 from:
-> Even empty container fields have an impact on sync speed (empty regular fields do not) so instead of syncing 10 repeating container fields it can be faster to sync 1 related table with a single container field (a portal of containers instead of repeating fields).

-> Scripted finds on un-stored fields in the script [[DownloadingFoundSets | building your found set]] can be a slowdown. If you've modified that script check it out
.
to:
'''Splitting Portals into their own Layouts'''

-> If tables in your solution aren't absolutely dependent on each other, don't sync them as portals on a single sync layout. When you use portals on your sync layout, GoZync sends every
portal record whenever the parent is modified. So if you have a patient and patient-visits, for example, having patient-visits as a portal on patients means we send *every* visit each time the patient or any visit changes. While portals are great for tables that MUST go together (like an invoice and it's line items) you'll get a faster sync in this patients-visits example if vists are their own sync layout.
January 20, 2013, at 03:14 AM by 50.132.84.245 -
Added lines 27-28:
-> For very large tables, consider [[Turning Off Deletes | turning off]] GoZync's deleted records support. This can make pulls much faster.
January 17, 2013, at 04:23 AM by 50.132.84.245 -
Added lines 27-28:
-> Don't zync the whole file (all the tables) every time. Rather, use GoZync's API scripts to sync specific tables. This will let you give users buttons to just pull down those tables that change most often, and let them run their other syncs less often. The script to call is "Zync It - Public API - ( TOName ) { Action ; RecordID }" in GoZyncMobile. Comments at the head of that script will tell you how to pass parameters to it.
January 12, 2013, at 11:22 PM by 184.78.159.107 -
Changed lines 5-6 from:
-> Zync over WIFI instead of 3G or 4G.
to:
-> Zync over WIFI instead of 3G or 4G. =)
Changed lines 9-10 from:
-> Zync fewer records. Bring down only the data a user needs to see that day / week, etc. See [[downloading found sets]] for details on how to do this.
to:
-> Zync fewer records. Bring down only the data a user needs to see that day / week, etc. See [[downloading found sets]] for details on how to do this. This is probably the most important thing you can do to effect zync speed outside of getting  [[field level merge]] right (see below).
Changed lines 13-14 from:
-> If you have photos, turn [[field level merge]] on. This will prevent photos from being sent when they didn't change. This alone can speed things up dramatically.
to:
-> If you have photos in your table among other fields, turn [[field level merge]] on. This will prevent photos from being sent when they didn't change. This alone can speed things up dramatically. Note that an even faster structure is to sync photos as their own table (and have  field level merge off for that table.)
Changed lines 17-18 from:
-> For narrow records, turn off [[field level merge]] (just a few fields). It may slow things down to use field level merge as it can take us longer to check the fields changed than to just package the whole record. Remember, we're only sending modified records anyway. This may be something to experiment with, using the times in the Zync log as an guide.
to:
-> For narrow records (just a few fields), turn off [[field level merge]]. It may actually slow things down to use field level merge as it can take us longer to check the fields changed than to just package the whole record. Remember, we're only sending modified records anyway. This may be something to experiment with, using the times in the Zync log as a guide.
Changed line 29 from:
-> Scripted finds on un-stored fields in the script [[DownloadingFoundSets | building your found set]] can be a bit slowdown. If you've modified that script check it out.
to:
-> Scripted finds on un-stored fields in the script [[DownloadingFoundSets | building your found set]] can be a slowdown. If you've modified that script check it out.
December 19, 2012, at 11:51 PM by cm - minor edits and clarifications
Changed lines 7-22 from:
-> Fewer fields. Even with [[field level merge]] on, the fewer fields on your zync layouts, the faster it works. This is especially true if you're doing [[custom field mapping]].

-> Fewer records. Bring down only the data a user needs to see that day / week, etc. See [[downloading found sets]] for details on how to do this.

-> Don't do any [[custom field mapping]]. Even if the mapping isn't in the TO you're zyncing, we still check the TO for custom mapping.

-> Turn [[field level merge]] on if you have photos. This will prevent photos from being sent when they didn't change. This alone can speed things up dramatically.

-> Turn [[field level merge]] on for wide records: the more fields you have--that have data in those fields, the more of an impact field level merge makes.

-> Turn off [[field level merge]] for narrow records (just a few fields). It may slow things down to use field level merge as it can take us longer to check the fields changed than to just package the whole record. And remember, we're only sending modified records anyway. This may be something to experiment with, using the times in the zync log as an guide.

-> And don't forget the first zync (for each user) using [[field level merge]] will take a while: it is the subsequent syncs that are faster.

-> If you're using [[field level merge]], perform one zync on Pro before you deploy your mobile files. This will seed some of the data on the server, rather than forcing your first connected iOS device to do it.
to:
-> Zync fewer fields. Even with [[field level merge]] on, the fewer fields on your Zync layouts, the faster it works. This is especially true if you're doing [[custom field mapping]].

-> Zync fewer records. Bring down only the data a user needs to see that day / week, etc. See [[downloading found sets]] for details on how to do this.

-> Don't do any [[custom field mapping]]. Even if the mapping isn't in the TO you're Zyncing, we still check the TO for custom mapping.

-> If you have photos, turn [[field level merge]] on. This will prevent photos from being sent when they didn't change. This alone can speed things up dramatically.

-> For wide records, turn [[field level merge]] on. The more fields you have, that have data in those fields, the more of an impact field level merge makes.

-> For narrow records, turn off [[field level merge]] (just a few fields). It may slow things down to use field level merge as it can take us longer to check the fields changed than to just package the whole record. Remember, we're only sending modified records anyway. This may be something to experiment with, using the times in the Zync log as an guide.

-> And don't forget the first Zync (for each user) using [[field level merge]] will take a while: it is the subsequent Zyncs that are faster.

-> If you're using [[field level merge]], perform one Zync on Pro before you deploy your mobile files. This will seed some of the data on the server, rather than forcing your first connected iOS device to do it.
November 13, 2012, at 04:16 PM by 107.2.189.216 -
Changed line 29 from:
-> Scripted finds on unstirred fields in the script [[DownloadingFoundSets | building your found set]] can be a bit slowdown. If you've modified that script check it out.
to:
-> Scripted finds on un-stored fields in the script [[DownloadingFoundSets | building your found set]] can be a bit slowdown. If you've modified that script check it out.
November 12, 2012, at 03:58 AM by 50.132.84.245 -
Added lines 28-29:

-> Scripted finds on unstirred fields in the script [[DownloadingFoundSets | building your found set]] can be a bit slowdown. If you've modified that script check it out.
November 12, 2012, at 03:56 AM by 50.132.84.245 -
Added lines 19-22:
-> And don't forget the first zync (for each user) using [[field level merge]] will take a while: it is the subsequent syncs that are faster.

-> If you're using [[field level merge]], perform one zync on Pro before you deploy your mobile files. This will seed some of the data on the server, rather than forcing your first connected iOS device to do it.

Changed line 27 from:
-> If you're using [[field level merge]], perform one zync on Pro before you deploy your mobile files. This will seed some of the data on the server, rather than forcing your first connected iOS device to do it.
to:
-> Even empty container fields have an impact on sync speed (empty regular fields do not) so instead of syncing 10 repeating container fields it can be faster to sync 1 related table with a single container field (a portal of containers instead of repeating fields).
October 26, 2012, at 01:40 PM by 166.137.100.32 -
Changed lines 19-20 from:
-> Don't [[round trip]] unless you have to. When you round trip, the hosted inbox is processed using the iPad's resources (its slower CPU). Your users may have a more satisfying experience pushing data up, having a server side script process it, then reconnecting later to pull their data down.
to:
-> Don't [[Zync Options | round trip]] unless you have to. When you round trip, the hosted inbox is processed using the iPad's resources (its slower CPU). Your users may have a more satisfying experience pushing data up, having a server side script process it, then reconnecting later to pull their data down.
June 28, 2012, at 12:47 AM by 50.132.84.245 -
June 28, 2012, at 12:47 AM by 50.132.84.245 -
Changed lines 15-16 from:
-> Turn [[field level merge]] on for wide records: the more fields you have, the more of an impact field level merge makes.
to:
-> Turn [[field level merge]] on for wide records: the more fields you have--that have data in those fields, the more of an impact field level merge makes.
June 22, 2012, at 10:32 PM by 50.132.84.245 -
Added lines 9-10:
-> Fewer records. Bring down only the data a user needs to see that day / week, etc. See [[downloading found sets]] for details on how to do this.
June 22, 2012, at 10:31 PM by 50.132.84.245 -
Changed lines 17-18 from:
-> Don't [[round trip]] unless you have to. When you round trip, the hosted inbox is processed using the iPad's resources (CPU). Your users may have a more satisfying experience pushing data up, having a server side script process it, then reconnecting later to pull their data down.
to:
-> Don't [[round trip]] unless you have to. When you round trip, the hosted inbox is processed using the iPad's resources (its slower CPU). Your users may have a more satisfying experience pushing data up, having a server side script process it, then reconnecting later to pull their data down.
June 22, 2012, at 10:30 PM by 50.132.84.245 -
Added lines 5-6:
-> Zync over WIFI instead of 3G or 4G.
June 22, 2012, at 10:28 PM by 50.132.84.245 -
Added lines 1-19:
!! What can I do to make Zyncs faster?

There are actually a number of things you can do to speed up the zync.

-> Fewer fields. Even with [[field level merge]] on, the fewer fields on your zync layouts, the faster it works. This is especially true if you're doing [[custom field mapping]].

-> Don't do any [[custom field mapping]]. Even if the mapping isn't in the TO you're zyncing, we still check the TO for custom mapping.

-> Turn [[field level merge]] on if you have photos. This will prevent photos from being sent when they didn't change. This alone can speed things up dramatically.

-> Turn [[field level merge]] on for wide records: the more fields you have, the more of an impact field level merge makes.

-> Turn off [[field level merge]] for narrow records (just a few fields). It may slow things down to use field level merge as it can take us longer to check the fields changed than to just package the whole record. And remember, we're only sending modified records anyway. This may be something to experiment with, using the times in the zync log as an guide.

-> Don't [[round trip]] unless you have to. When you round trip, the hosted inbox is processed using the iPad's resources (CPU). Your users may have a more satisfying experience pushing data up, having a server side script process it, then reconnecting later to pull their data down.

-> Zync fewer photos and videos.

-> If you're using [[field level merge]], perform one zync on Pro before you deploy your mobile files. This will seed some of the data on the server, rather than forcing your first connected iOS device to do it.
(855) SEEDCODE
support@seedcode.com
Follow us: