The default remains to store a persistent DBCache, but by creating the DebugReleaseOn.txt file at the client and adding a line with NormalTempFile to it, you will go back to the pre-15 behavior FileMaker Pro will work with a cache file for the duration of the session and discard it when the session ends. In FileMaker Pro 19.1, you can now choose which of the two behaviors you want to use. Before version 15, the temp file with the cache was discarded every time your solution was closed. The aim of this cache is to speed up opening the solutions by avoiding rebuilding the temp file cache every time, something that is especially relevant for WAN connections and when using low-powered devices such as phones and tablets. Since FileMaker 15, the client keeps a persistent cache stored in the DBCache folder 1. While not strictly a FileMaker Server feature, how the client manages its temp files and cache certainly does affect the user’s experience when working with a solution hosted on FileMaker Server. When you turn the feature off at the client level, look for the DBDebug.log file in the same location as your FileMaker Pro application to confirm that the feature was indeed turned off after relaunching FileMaker Pro.
If you disable it at the client (by putting the ReleaseDebugOn.txt where your FileMaker Pro application is), then it will disable the feature for just that client. If you do that at the server level, then it will disable all server-side sorting. If, for some reason, you find that you need to turn this feature off, then follow the instructions above to create the ReleaseDebugOn.txt file and add this flag to it: DisableServerSideSorting. the overall effect of server-side sorting may not be clear at all times, but it should be beneficial overall. Note that there are quite a few pieces to the sorting puzzle, including how much data of the target table is already cached at the client, how busy the server is, etc.
If not, then the client will still end up doing the sort.
As with anything that involves asking the server to do more: make sure that your server is up to the task and has sufficient processing capacity to handle the extra load. It is very clear then that we are trading off-network traffic for server-side processing. Underneath each number is a visual bar-chart representation of the number to more easily grasp the relative difference. The cells then represent the number of seconds it took to complete each script execution. The Performance indicator (true/false) indicates whether FileMaker Server had the 19.1 performance enhancements features turned on (true) or off (false). In the example below, two scripts are shown that ran on an AWS t3.2xlarge instance type, which has eight cores.Įach column represents a test run with a number of concurrent Perform-Script-on-Server (PSoS) sessions, running on a specific FileMaker Server version on a given operating system. Each row represents a particular test script running on a particular test server. The results from Punisher are shown in a pivot table. It focuses the testing on nothing but the server resources: processing power, disk i/o, and memory. Punisher abstracts out the other variables that would have an unwanted impact on performance, such as client-side horsepower, network latency, and throughput, caching, etc. Performance benchmarking across different servers, operating systems, and FileMaker Server versions only work if you let those servers perform the exact same tasks every single time. Those metrics were collected using our own Punisher tool. Throughout this blog post, you will see a number of screenshots showing performance benchmarks of different server machines and how long it took them to perform certain tasks.
0 kommentar(er)
