Just in case... I felt somewhat strange when reading the release notes - I was not aware of the 10.14 behavior..
The good: Startup restoration is turned off by default and some issues are solved
1 Like
Probably the single most important change in a while: you can now toggle on the regular stats.log from the admin console again. Unfortunately it is still off by default but at least it is a lot easier to point people to where it can be turned on.
If you're not enabling it as soon as you install FMS: start doing that! It's only the single most important troubleshooting info that is available. 
4 Likes
Is it correct (also for FMS19) that turning off Startup Restoration also turns off performance benefits for multicore processing?
Yes, that is still the same.
2 Likes
Uh i do not understand the relation between the two ”features”.
The "better parallel processing" means that FMS can use more cores at the same time more often. (It does already use multiple cores at the same time for some operations that allow it easily, like finds. Common myths notwithstanding that insist that FMS is not multi-threaded).
The way that you use more cores in parallel is by spawning more threads. More threads = more risk that one of them conks out = more chance of FMS becoming unstable. To mitigate that risk, Claris added a feature that would reconstitute the FM file if FMS crashes so that the increased risk (not increased probability!) of crashing is offset by something that would make it less likely that a crash would result in a corrupted file. That feature is the 'data restoration'. And that's how they are related.
There's no point in leaving the 'better parallel processing' running without the safety net of the data restoration. Thus when you turn data restoration off, you also revert FMS to the 17 processing model.
7 Likes
It would be hard to find another place to get such precise and competent answer. And so quickly. This encourages me to sponsor October 2020 for the fmsoup 
10 Likes
Thank you Mr Decorte. I now see the reasoning, even though i would have preferred having two separate controls.
That’s not even possible. Data would get corrupted much too fast. It would be like playing catch with multiple people at once with one arm tied behind your back and not catchers mask to protect your face. Imagine 6+ balls coming at you all at once. How many of them do damage?
What is the issue with this feature. Nearly every database has this feature - before-image logs, after-image logs, roll back or roll forward recovery etc. What are they struggling with - is is database engine issue ?
1 Like
unexpected stopped server processes, etc. We got servers that stopped running after cli-commands, etc. Since we stopped the s.r., those server are stable
1 Like
Strange feeling for me too after reading all these posts. With FMS 18 release I remember Claris announced better performances for now and for the future. They insisted upon their new multiprocessor support. One year later I did not heard anything about their “engagement” on leverage performances of client-server usage. Instead we now learn that by default, fms 19 multiprocessor support is back to 17. I am perplexed.
1 Like
They keep restating that engagement in every roadmap webinar. Neil Wright, the FMS product manager literally stated what you're asking for: stability and performance.
As to why it takes so long: I talk to them often and I can tell you that they're not happy with how long it takes to track this one down either. They're working hard on it.
3 Likes
Did you look at the “what’s new” for FileMaker Server 19? Literally, a stability and performance enhancement release.
Well not if you need multi core performance combined with database platform recovery mechanisms.
Mark, sorry but not sure to what/who you are answering ??
it’s funny that you are asking the question because yes, I’m trying to grab some info and when I went to take a look to the help article I was surprised by so much eloquence. Finally it is possible that all this is just a small communication problem: https://help.claris.com/en/server-help/#page/FMS_Help%2Fabout-whats-new.html%23ww1031291
Thanks. Since you have info that are not available in the official doc (i red carefully the help article about data restoration and the only mention about perfs is suggesting that it is rather bad for perfs) i will try my chance and ask you another question : Some day ago a customer of mine called me very excited and telling me that surprisingly, perfs on 18.0.4 version of FMS were very changed (he is using FMS via VPN and fiber conexion). Are you aware of a such possible improvements on last FMS 18 release or it is more likely due to other side effects ?
Can you expand a bit on who or what you are replying to?
This disabled feature doesn't mean you don't get multi-core performance. Nor is it the only way to get proper DR protection. Ask questions about that if you want to set up a good strategy but don't know how.
There always are performance fixes in every release but without knowing their numbers of before and after and details about anything else they may have changed it's hard to say what may be responsible.
It's one of the reasons why keeping the stats.log turned on and/or doing other monitoring so that you have a baseline to compare against and see the evolution on the traditional bottlenecks (processing power, disk i/o, memory and network throughput).