xochi

Did you mean to say "data writes are more expensive with Transaction Logging ON" ? If so, then I agree.

2012 Mac Mini 4/8 core i7 with 16GB RAM, internal SSD. The process showing the major slowdown is in a table where we have one field which triggers auto-enter calcs in other fields, causing many other fields to update in that table. Many of these fields pull data from related records across somewhat complex relationships that may involve 2 or more keys that are sorted. Basically, it's a combination of "read lots of data" and "write lots of data". I would presume the "write lots of data" is where the slowdown is happening, but that's just a guess.

FYI, FMS 18v3 is out and fixes a subtle bug: sometimes after a reboot on macOS, the apache / httpd server fails to start up. As a result, FMPro works fine, but WebDirect will be dead, and there's no notifications. See https://community.filemaker.com/en/s/article/Software-Update-FileMaker-Server-18-0-3

Update: after enabling startup restoration (transaction logging), we found that several of our long-running batch processes were about 50% to 75% slower - an operation which used to take about 100 minutes was now taking 170 minutes. We didn't notice any performance improvments, but our usage scenario doesn't typically have multiple users doing big Finds, so not clear we would have seen improvements anyway. On balance for us, this is a net loss, so we are going to turn it back off. FYI, regarding my concerns that Startup Restoration could possibly introduce new bugs, here's one example (yet to be verified) which is worrying: https://community.filemaker.com/en/s/question/0D50H00007F4JmMSAV/deadlockedendless-queries-started-by-disconnected-users-on-fms-18v2-with-startup-restoration-enabled

Ok, I think we are in agreement here on the key facts. 😄 "Transaction Logging" is probably a better term to use because it conveys more information and is an established term of art: https://en.wikipedia.org/wiki/Transaction_log Although Claris does point out that their version of TL is not ACID compliant.

Wim, I'm not sure we are communicating. Let me try again so that we are crystal clear: In FMS18, we have 3 "features": SR - startup restoration TL - transaction logging BPP - better parallel processing By default, SR is ON, TL is ON, and BPP is ON. The only control we users have is to enable or disable SR (we can't control TL or BPP individually). The three are linked: Disabling SR also disables TL and BPP. Claris Inc documentation notes that leaving SR on may hurt performance, and suggests turning it off - here: https://fmhelp.filemaker.com/help/18/fms/en/index.html#page/FMS_Help/hostdb-startup-restoration.html As noted at the top of this thread, BPP can in some cases give worse performance, but in some cases better performance, sometimes dramatically so: see https://community.filemaker.com/en/s/question/0D50H00006tgeVdSAI/fms18-any-definitive-documentationevidence-of-multicore-use which shows a 15x speedup in one situation! So, my statement: Is true, and my point remains: Official Claris documentation says that disabling SR might help performance, but makes no mention of the fact that disabling SR might cause a dramatic slowdown in some situations. My opinion is that this needs better documentation.

A. We guarantee better performance B. Startup Restoration may hurt performance becuase it adds extra transactional logging. C. Startup Restoration might help performance because it enables parallel processing features. A: I'm not asking for this, please don't misunderstand. B: is what Claris provides currently. C : seems to be missing from the official documentation.

Definitely - which is weird that there doesn't seem to be any official statements about this - the only Claris Inc documentation I can find talks about performance problems, not benefits. Are there any official docs about this?

@WimDecorte: Just to be absolutely clear - you used the term "Data Restoration" but I'm talking about "Startup Restoration" as descirbed here: https://fmhelp.filemaker.com/help/18/fms/en/index.html#page/FMS_Help/hostdb-startup-restoration.html Are you saying that if I run the command fmsadmin set serverprefs StartupRestorationEnabled=false then I may lose some benefits of parallel processing in FMS18? It's strange the Claris mentions the performance penalties, but not the possible benefits. Our UPS has 36 hours of battery life and 10 year lifespan batteries. It's not really a limiting factor. Of course - we have multiple layers (local, cold onsite, and cloud offsite). We have progressive backups enabled. Progressive backups (on the several FMS servers I checked) are backing up our database every 5 minutes. So at worst we'd lose 5 minutes of data. I'm just not seeing the value proposition here for Startup Restoration. It sounds like it's only going to be useful in one particular circumstance, when you have a software or hardware crash which takes down FileMaker Server, but does NOT corrupt the startup restoration log, and the server is in incredibaly high use, so that 5 minutes of lost data entry is not acceptable, and you feel comfortable letting your server reboot automtically after a crash without human intervention. I can see how this may be useful for some situations, but this also assumes that there are no new risks in doing this. What if there's a bug in Startup Restoration which corrupts your database silently? That would not be good.

I just upgraded several servers to FMS 18, and I decided to disable this feature. My reasoning: I have not had a single one of my database servers crash in over 24 months. Startup restoration feels like a solution to a problem I'm not having. There are warnings about startup restoration causing performance hits It's a new feature, which always opens the possibility of there being some sort of subtle bugs Everyone's needs are different of course. But I would argue that if you are are having any server crashes whatsoever, you really should address that problem first. Do you need a better UPS? Is your server hardware flakey? Should you use a different OS? On second thought: is "transaction logging" the same thing as "startup restoration"? If so, then this discussion https://community.filemaker.com/en/s/question/0D50H00006tgeVdSAI/fms18-any-definitive-documentationevidence-of-multicore-use suggests that turnning TL off might actually hurt performance. I'm a little confused.

How about approach it from the other direction: try using the (new in FM18) Create Data File script step followed by Write Data File, and see if the server can create a file using your file path. Maybe that will help you debug? See https://fmhelp.filemaker.com/help/18/fmp/en/index.html#page/FMP_Help%2Fcreate-data-file.html%23ww1258616 Also, I find that FMserver is sensitive to file ownership - if you right-click the file, get info in the finder, you can set the file to be owned by the 'fmserver' user. You might need to do that to the enclosing folder, too. Does that help?

Some report of memory leaks in FMS 18: https://community.filemaker.com/en/s/question/0D50H0000787p8sSAA/filemaker-server-1802217-memory-leak

I found this was also true with FileMaker Server 14 - you really need to run WebDirect on its own static IP address on the normal HTTPS port 443. If you don't, weird things can happen - although it may work with some clients, there may be issues for some companies that are running SSL proxy firewalls.

See

Yes, in fact I couldn't get it working until I rebooted. I suspect that it might not survive a software update to FileMaker server, if those two files get edited during the upgrade.

I figured out a way to get custom ports in FileMaker Server 17 so that it can coexist with macOS server 5.6.1 inside macOS High Sierra 10.13.6: Install macOS High Sierra + all updates. Then, install macOS server Finally, install FileMaker Server 17. If you get the "Apache is running" error, try to install again while running this terminal script (See https://community.filemaker.com/thread/156699 ) while sleep 5; do sudo killall -9 httpd; done After installation, control C the script to stop it. Then, after installation, you can change the ports that FileMaker Server is using by making 3 edits in two files: in /Library/FileMaker Server/HTTPServer/conf/httpd.conf change "Listen 80" to "Listen XXXX" (one place) in /Library/FileMaker Server/HTTPServer/conf/extra/httpd-ssl.conf change 443 to YYY (in two separate lines) (this assumes you want ports XXXX for HTTP and port YYYY for HTTPS) In theory, you should be able to restart FileMaker's apache process by : sudo fmsadmin restart httpserver But I found it didn't "take", however rebooting the entire sever seems to have fixed it. I now have a server running macOS High Sierra 10.13.6, with FileMaker Server 17.0.2, and macOS Server app 5.6.1 all running happily together. Note that macOS Server 5 does some weird things with port-mapping and proxies for services such as CalDAV which really want to run on 80 and 443. I found it much easier to change FileMaker's ports, rather than trying to change macOS server's ports. I hope this info can help others.

That probably depends on their specific policies. One should note that FileMaker Server 16 can now generate PDF files, so one could probably do this in WebDirect using the "Perform Script on Server" command, and avoid needing a second "robot" user altogether.

Thanks - it looks like that solution switches between Preview and Browse mode, which may be the only way to do it. I ended up scripting something somewhat similar: in Browse mode go record-by-record until I find that the RoomNumber has changed. Then make a new window, Constrain the found set to that single room number, save as PDF then close the window.

I have a multi-page printout which is split with a page break for each sub summary part. Imagine for example a room inventory list where each room gets its own page. I'd like to save these as separate PDF files, so each room has it's own file, e.g. Room1Inventory.pdf Room2Inventory.pdf ... One way to do this is simply loop through the room numbers, and for each room do a Find / Sort / Preview Mode / Save as PDF. But I'm curious if this can be done a different way - what if I already am in Preview mode with a report showing all rooms (where there's a sub summary page break). Is there any way at this point to loop through in Preview mode and save each page into it's own PDF file? I can almost get it working like this: Find Record Sort Enter Preview Mode Loop set variable $roomNumber = Rooms::RoomNumber set variable $startPage = Get(PageNumber) set variable $endPage = $startPage + 1 set variable $file = "Room Number" & $roomNumber Save Records as PDF (output file=$file, options/include specific page: from $startPage to $startPage+1 go to next page, exit after last End Loop Two problems: 1. unfortunately, since I'm in Preview mode, Rooms::RoomNumber never changes, it's always showing the value on the first record in the found set, regardless of what page I'm on. 2. if the report is more than one page long for a given room, I need to figure out what $endPage should be.

I'm a big fan of Arq Backup http://arqbackup.com which lets you back up to a variety of locations (onsite or offsite). I'm currently using a combination of Arq, TimeMachine AND SuperDuper backups on my Mac OS X (macOS) servers. The main thing to worry about is to avoid backing up live database files.

For me, the lack of server-side-schedules is a deal-breaker. But, as you say, it's a version 1 product. Hoping they add this in the future.

I have not tried it in 15, but as of 14 there is a new setting that seems to work without requiring CSS editing: Go to File / File Options / Open tab and click the Hide All Toolbars checkbox.

I'm dealing with this too. What I've found is that: I ended up using the OnRecordCommit event which triggers a script which normally returns False which blocks the commit --- unless my "Save" button has been pressed. This is a common technique. What I added was this: The Save button calls a script which timestamp field indicating that the user actually pressed the Save button, and this is the flag that I use to indicate "was actually committed by the user on purpose". Then it Commits the record. So this way I can distinguish between two cases: New records that were committed on purpose, and new records that were committed on accident. You then need some additional logic to deal with records that exist but are missing the flag, but this is not that difficult. For example, you could have a server-side-script that runs every X minutes and simply deletes records in that state. Or instead of deleting the data, perhaps it emails the user to say "Hey, you left an incomplete entry, please fix it".

That's always been a difference between OS X and Windows. On OS X, the scroll wheel never changes records, which is how I prefer it. So I would welcome this change, personally, although I can see how you might miss it if you were used to it.

Definitely not ideal, but it will probably get the job done in the short term. I do wonder if there's some magical combination of settings I could have to make it work properly however.