Speed
GoZync5.Speed History
Hide minor edits - Show changes to output
Changed line 13 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. This is probably the most important thing you can do to effect zync speed.
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 affect zync speed.
Changed line 15 from:
-> Scripted finds on un-stored fields in the script [[DownloadingFoundSets | building your found set]] can be a slowdown. If you've modified that "Filter Records to Zync" 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 "Filter Records to Pull" script, check it out.
Changed lines 43-45 from:
For example, they can sync the workorders table several times a day but only sync products once a month when prices change. Even better would be to deliver prices [[DistributingMobileFiles | IN a new copy of their mobile file]] once a month.
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.
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.
to:
-> For example, they can sync the workorders table several times a day but only sync products once a month when prices change. Even better would be to deliver prices [[DistributingMobileFiles | IN a new copy of their mobile file]] once a month.
-> 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 so you can specify which tables to zync.
-> 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 so you can specify which tables to zync.
Changed lines 15-16 from:
-> 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:
-> Scripted finds on un-stored fields in the script [[DownloadingFoundSets | building your found set]] can be a slowdown. If you've modified that "Filter Records to Zync" script, check it out.
Changed lines 19-20 from:
-> 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 [[related records]] and have field level merge off for that table.
to:
-> If you have photos in your table among other fields, you may want to 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 [[related records]] and have field level merge off for that table: that's what we recommend.
Changed lines 41-45 from:
-> 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.
to:
-> 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.
For example, they can sync the workorders table several times a day but only sync products once a month when prices change. Even better would be to deliver prices [[DistributingMobileFiles | IN a new copy of their mobile file]] once a month.
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.
For example, they can sync the workorders table several times a day but only sync products once a month when prices change. Even better would be to deliver prices [[DistributingMobileFiles | IN a new copy of their mobile file]] once a month.
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.
Added lines 24-27:
'''Use FileMaker Server'''
-> If you're using FileMaker Pro as your host, GoZync can't utilize Perform Script on Server (PSOS) when pulling records. PSOS has the biggest impact on large tables and especially on large tables where few records change. Switching to FileMaker server makes PSOS possible. You won't need to change anything else in your code; GoZync 5 uses PSOS by default when it can.
Deleted lines 38-40:
-> If you can manage the deletion of mobile records yourself you can turn off GoZync's management of this, which can have a big effect on speed especially if you have large numbers of unchanged records in each sync. Details at the end of the article [[Deletes | here]] (though I'd read the whole thing).
Added lines 38-41:
Deletions
-> If you can manage the deletion of mobile records yourself you can turn off GoZync's management of this, which can have a big effect on speed especially if you have large numbers of unchanged records in each sync. Details at the end of the article [[Deletes | here]] (though I'd read the whole thing).
Changed lines 23-24 from:
to:
-> Slim down your photos using FileMaker's GetThumbnail() function: it can make images smaller, not solely make thumbnails. You'll find some tips for getting the most out of this here: [[Reducing Photo Size]].
Changed lines 27-44 from:
-> [[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.
-> 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 justpackage 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.
-> 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.
'''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 [[AutoProcessing | 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.
-> 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.
-> 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
-> 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.
'''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 [[AutoProcessing | 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
to:
-> [[Field Level Merge]] (FLM) 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 unchanged fields you have with data in them, the more of an impact field level merge makes.
-> 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 send the whole record. Remember, we're only sending modified records anyway. This is probably something to experiment with once you get the sync down, using the times in the Zync log as a 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. Be sure to '[[seeding FLM | seed]]" the FLM database before you deploy your mobile files.
-> For wide records (records with LOTS of fields), turn field level merge on. The more unchanged fields you have with data in them, the more of an impact field level merge makes.
-> 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 send the whole record. Remember, we're only sending modified records anyway. This is probably something to experiment with once you get the sync down, using the times in the Zync log as a 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. Be sure to '[[seeding FLM | seed]]" the FLM database before you deploy your mobile files.
Deleted lines 37-41:
'''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 its line items) you'll get a faster sync in this patients-visits example if vists are their own sync layout.
Deleted lines 6-7:
Changed lines 9-13 from:
-> 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.
-> 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.
to:
-> Zync fewer fields. Even with [[field level merge]] on, the fewer fields on your Zync layouts, the faster it works.
Changed lines 13-14 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. This is probably the most important thing you can do to effect zync speed outside of getting [[field level merge]] right (see below).
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.
Changed lines 19-22 from:
-> 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.)
-> 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).
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 [[related records]] and have field level merge off for that table.
-> Even empty fields have an impact on sync speed so instead of syncing 10 repeating container fields it can be faster to sync 1 related table with a single container field. This is true of regular fields as well as of container fields.
--> Slim down your photos using FileMaker's GetThumbnail() function: it can make images smaller, not solely make thumbnails. You'll find some tips for getting the most out of this here: [[Reducing Photo Size]].
-> Even empty fields have an impact on sync speed so instead of syncing 10 repeating container fields it can be faster to sync 1 related table with a single container field. This is true of regular fields as well as of container fields.
--> Slim down your photos using FileMaker's GetThumbnail() function: it can make images smaller, not solely make thumbnails. You'll find some tips for getting the most out of this here: [[Reducing Photo Size]].
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:
to:
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.
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.
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.
Added lines 5-6:
'''General'''
Deleted lines 10-11:
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'''
-> 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.
'''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:
-> Zync fewer photos and videos.
-> For very large tables, consider [[
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'''
-> 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:
-> 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.
-> 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.
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.
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.
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 - 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'rezyncing, 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 firstzync (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 onezync 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.
->
-> Don't do any [[custom field mapping]]. Even if the mapping isn't in the TO you're
->
->
->
-> And don't forget the first
-> If you're using [[field level merge]], perform one
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.
-> 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.
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.
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.
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.
-> 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).
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.
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.
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.
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.
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.
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.
