Newbies Carey Archer Posted January 24, 2018 Newbies Share Posted January 24, 2018 Greetings, we just successfully implemented a server to server sync for a 100+ user solution. Overall the results were fantastic. The key issue is that when large updates are made on the hub server to 1000+ records, the sync can take over 1 hour to update all of the records in the spoke server. (We're talking a table with 30+ fields). On the contrary, when the same exact updates are made to 1000 records on the spoke server, the sync completes in a matter of seconds. We are having a hard time understanding why the changes that happen on the spoke sync so much faster. Any insight without having to dig into server / network configurations? Link to comment Share on other sites More sharing options...
Amber360Works Posted January 25, 2018 Share Posted January 25, 2018 Hey Carey, We are familiar with the issue you’re experiencing. Jesse Barnum, our head MirrorSync developer, made a FMForum post on just this topic that details what’s going on tech-wise when syncing in that direction: https://community.filemaker.com/ideas/2936 Feel free to up-vote this topic in the interest of increasing its visibility. Link to comment Share on other sites More sharing options...
fishtech Posted January 26, 2018 Share Posted January 26, 2018 Voted up! Link to comment Share on other sites More sharing options...
cbishop Posted August 22, 2018 Share Posted August 22, 2018 I'm having this issue too when testing with MirrorSync, and I already found that thread and upvoted it. I don't see FileMaker, Inc. improving the JDBC engine since they're heavily pushing the Data API now. I currently use SyncServer Pro (SSP). The way it handles remote server syncing is by allowing you to install additional SSP client software copies on each FM Server machine (or on a different machine local to that FMS machine). The hub SSP software communicates with the SSP clients rather than directly with the remote FileMaker Servers, then the spoke SSP clients connect via JDBC. SyncServer has many, many issues, but in write speed it does well. Can I suggest to add this as a feature request? Link to comment Share on other sites More sharing options...
Jesse Barnum Posted August 31, 2018 Share Posted August 31, 2018 Hi Chris - I'm planning on a switch to the Data API for the next major release of MirrorSync, I'm hoping that this will perform better than JDBC over the WAN. If it doesn't, I have also been considering a similar idea of running MirrorSync on each server, which would definitely solve the problem. The downside of this is that it wouldn't work with FileMaker Cloud, and I'd like to avoid different architectures for FileMaker Cloud. Link to comment Share on other sites More sharing options...
cbishop Posted August 31, 2018 Share Posted August 31, 2018 Hi Jesse, That sounds great. Not sure about the pricing issue with the Data API though (the per GB charge). It would be nice to have a pass-through small server instance located wherever you need it though... Link to comment Share on other sites More sharing options...
Jesse Barnum Posted August 31, 2018 Share Posted August 31, 2018 Also, have you tried using XML instead of JDBC? XML is much faster over a WAN, because it supports batch write operations. Link to comment Share on other sites More sharing options...
cbishop Posted August 31, 2018 Share Posted August 31, 2018 Yes. XML did have much higher write speeds (2 or 3 times the speed). However, the reads and connections were taking longer. Would be good to have a blend - tell it to use XML for batch writes only, but JDBC for all else - would this be possible to implement? Link to comment Share on other sites More sharing options...
Jesse Barnum Posted September 7, 2018 Share Posted September 7, 2018 Mixing XML and JDBC and trying to use one for reads and one for writes, or one for batches and one for singles, is going to be messy and difficult to maintain. I'm hoping that the Data API gives us the best of both, and I think we can architect in such a way that data usage will be minimal. Link to comment Share on other sites More sharing options...
Recommended Posts
This topic is 2058 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now