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.
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.
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
just asking about the max setting - totally able to differentiate between multi-threading - hyperthreading - out of order completion, Amdahl's law etc ..
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 ..
