FileMaker 17 Onwards - Maximum Simultaneous Script Sessions

We're still getting problems with the FileMaker Script Engine up to at least FileMaker Server 17 on both locally hosted servers and virtual machines (in our case mostly Windows servers).

The following is available elsewhere, but it doesn't appear to be in the fmsadmin help system, hence posting here.

'Maximum Simultaneous Script Sessions' was removed, along with many other things we'd previously taken for granted, from the admin console with the release of FMS 17.

This can be set using the command line interface (CLI), Terminal on the Mac, by entering:

fmsadmin set serverconfig scriptsessions=number

The default setting is 25 sessions, but can be changed within a range of 0 to 500. However, do also take into consideration what resources are available from the 'metal box' or virtual machine. Details relating to this outside of this post.

Regards
Andy

2 Likes

The default in 18 and 19 is 100.

2 Likes

As ever, the font of all knowledge. Thanks Wim. I reset FMS 17 to 50 today, but it was a beggars only job to find the information.

I found your post elsewhere and one other, but this information was not in the fmsadmin help.

So I guess that this revision should be taken into account for the specification of a server, although I do appreciate that this is dependent on so many factors.

However, most of our production servers (but not all) haven’t moved beyond v17 as yet and FMSE continues to be a thorn in our side on VMs and metal boxes.

1 Like

great info - thanks for sharing - how about max setting (assuming hardware scales accordingly) ?

You mean setting it to the max and forgetting about it?
I probably wouldn't, because a reasonable limit is safer in case you ever create a race condition that starts spawning sessions that you don't want.

I am all for disclosed specs - just in theory would like to know ..
In regards of max concurrent user connections FMS could serve the number was fluctuating from version to version somehow - and also would be interesting to see how the server side execution compares to outside concurrency ..

specs are indicative IMHO

// Rolls Royce doesn't disclose max power just says "enough" ..

I understand the desire to 'know', but those are really tough comparisons to make and to be able to draw generalized conclusions from. I see way too many sick deployments where the developer had heard "that PSoS is faster", or the cache should be set as high as possible, ...

It's the combination of the chosen hardware (main disk i/o, # of cores and core speed) plus the nature of the solution, plus the design architecture plus the concurrent load that makes things fast or not, or robust or not. Throw in potential server-side plugins and the number of permutations of factors goes up exponentially.

I'm sure that I can prove that PSoS is faster and I'm sure I can prove it is slower :slight_smile:

2 Likes

just asking about the max setting - totally able to differentiate between multi-threading - hyperthreading - out of order completion, Amdahl's law etc ..

Not sure if I understood correctly; but if you are asking about what the max setting is, it is unchanged at 500 in all versions of FMS, including 19.

1 Like

Great thanks (hope in future revisions scalability will be addressed...)

Out of curiosity: how many deployments do you have with more than say 150 concurrent users?

And what hardware do you have in place for those? Mostly around # of cores and core speed.

3 posts were split to a new topic: File Folders: the still missing feature in FMS 19

None

My motivation is using PSoS logic on an SBA solution where just syncing happens via PSoS calls the rest is stand-alone. So far with 150 Users over 4 Sync Servers on FMS13 worked very well in the past since FMS14 (increased user peak count) server never stalled but was sometimes out of sync with it self - saved data wasn't available to connected clients immediately - some latency happening. The server was 20 Core Xeon dedicated Windows 2012 Professional Server. Now building a new SBA solution with max scalability / reliability in mind ..