Efficiency re Concurrent Connections

[Nickalex]

Given the new licensing model i.e. charging for bundles of 5 concurrent connections, I looking at ways to maximise the efficiency whilst minimising connection times. So how does the following scenario sound ?

 

1) Distribute local .fp12 for use on FILEMAKER Go which contains local data

2) Provide a 'Sync Now' button which fires a script to open a remote file (i.e. 1 x connection), sync between the local data and the remote data file, then close the file (i.e. connection to the remote file)

 

Will the above approach actually work and be efficient ?

 

Does simply closing the remote file from within the script break the connection, thus freeing up another connection, to the max for which I've bought connection licences ?

 

Anybody got a handle yet on the spec of the hardware to run to the max of 50 x connections ?

 

Would the above approach be possible from within a runtime distribution, as an alternative to FILEMAKER Go ?

[Steven H. Blackwell]

Anybody got a handle yet on the spec of the hardware to run to the max of 50 x connections ?

 

OK, this maximum tested concurrent connections applies to WebDirect.  It does not apply to FIleMaker GO. FileMaker GO still requires concurrent connections, however.

 

If I were to connect 50 instances of FileMaker GO, I would utilize at least a quad core machine with at least 24 GB RAM and 3 or 4 drives.  I would probably also want the machine to have dual NIC cards.  If you can tell us a bit more about what you want your solution to do, perhaps we can sharpen and narrow this advice some.

 

Steven

[Nickalex]

Thanks, Steven, I'll price it up that way...any comment on whether the approach I outline would actually be efficient in terms of minimising connections and connection time ?

[Nickalex]

It's actually a globally available self-registration database, with simple synchronisation (ie latest modification wins) of 4 potentially huge files, but all with only a small number of fields, each (about 20). Estimated new registrations = 1000 per hour, peak....estimated updates/syncs = 60 per hour, peak

[Nickalex]

Sorry, 4 potentially huge tables, not 4 files (huge in terms of number of rows)

[Wim Decorte]

Thanks, Steven, I'll price it up that way...any comment on whether the approach I outline would actually be efficient in terms of minimising connections and connection time ?

 

Connection time would be efficient I think but you'd still have no control over the number of concurrent connections.

[Nickalex]

No, that's fine, so long as we cater for what we think is the peak...if we get it wrong we can buy more licences pretty quickly, up to the max

[Steven H. Blackwell]

I believe a 1000 new registrations per hour with a once every minute sync rate is going to be a challenge. It might work, but I'd have a Plan B in mind here.  You can use the fm re-authenticate function to control what FMGO does if a user goes into multi-task mode on the mobile device.

 

Heavy duty server is going to be needed here, running either Windows Server 2008 R2 or Windows Server 2012.  If you employ Server 2012 do not use resilient file structure (the default option). it will disrupt the scheduled backup process.

 

Steven

[Nickalex]

Just to clarify those numbers, 1000 new individuals could register in a period of an hour...if evenly spread across the hour (it won't be, I'm sure) makes about 17 per minute...let's allow 30secs for the connection to sync between local and remote files, for each new registration, ie when the data has been entered to the local file and the 'Sync now' button pressed, we should be well ok, and use only 8 or 9 connections concurrently. Double it to allow for peaks, plus a fudge factor...say 20 concurrent connections. Now, on TOP of that, assume 1 user per minute, already registered, decides to change their local data, then press the sync button...the 1 user per minute is taken as a very low percentage of an estimated 1million registrations each wanting to update their existing data very infrequently...really tough to estimate, though. Hope that makes sense...