Server to Server sync speed

[Carey Archer]

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?

[Amber360Works]

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.

 

[fishtech]

Voted up!

[cbishop]

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?

[Jesse Barnum]

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.

[cbishop]

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...

[Jesse Barnum]

Also, have you tried using XML instead of JDBC? XML is much faster over a WAN, because it supports batch write operations.

[cbishop]

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?

[Jesse Barnum]

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.