1 of 1 people found this helpful
- They both get used.
- Changing the RAM cache on Server is applied as soon as you save. View the RAM usage before modifying, as you'll see it go up / down on saving.
- The RAM cache is used by FileMaker to store recent data (schema, layouts, record data, find queries, joins, indexes, calculation results, etc). This includes both data read and recent changes waiting to be committed (during idle time).
- The more cache available - the more that can be stored and the less likely that Server will need to go back to disk to get repeat data or Client will need to call back to Server for data.
- On your server, monitor the stats on your RAM cache - ideally it should be hitting the high 90's (100% would be great). Also, the unsaved should be low.
- On your client - I'm not sure if there is anyway to monitor the hit rate - but if you can afford it - make it higher. Just remember, it's all allocated at startup - even if it's not all used.
The two settings are independent, of course. The Server is on one computer and has its own settings and the client is on another computer and has its settings.
For the client, using the max setting produces the best result as you will find by testing this. I've had to go behind installers who placed FileMaker Pro on many computers and adjust the cache to the maximum much to the applause of the users whose Pro was now much faster. I won't discuss the hassle with the new IT guy who thought he was a super genius and kept telling me yet everything he did caused real problems.
There is some evidence that setting the server cache too high adversely affects performance, there is certainly a point after which there is nothing to be gained from a higher cache. FMS has to maintain it but does not really use it You have it set to 7GB, I would lower it substantially. How big is your solution?
Typically these cache settings can do some good in increasing performance but if performance IS an issue you'll get much better gains from fixes in other areas (design, network latency, processing power on the server/client,...)
How big is your solution?
The current solution that I am working on is on the larger side. There is one particular layout that is very complex, many tabs panels, slide panels, portals and popovers. There is not currently a performance issue. I was just trying to get a better idea of how these two settings can impact performance.
So if I set the client side cache to the max setting (512 MB) will it be able to cache more layout elements in RAM?
There is some evidence that setting the server cache too high adversely affects performance, there is certainly a point after which there is nothing to be gained from a higher cache. FMS has to maintain it but does not really use it You have it set to 7GB, I would lower it substantially.
Thanks for your reply Wim. How much lower would you set it and how do you determine this?
The Activity Monitor screenshot is irrelevant. The FMS stats in the admin console are the ones to look at.
The "cache hit %" should be 100%, potentially dipping down a bit during backup times. So start with 1GB or RAM and check to see if the numbers hold up. If not, increase the cache with say 500MB intervals until it does.
Yes. But it is not a silver bullet. Whatever benefits you can get from a higher client cache can be negated by:
- low disk space on the client
- latency on the network
Performance is a complex thing with many factors acting and counter-acting each other.
1 of 1 people found this helpful
Indeed. Also keep in mind that one of the functions of FileMaker Server is to keep the local client caches updated with changes from other clients. So, the larger the cache, the more traffic you may see, depending on what the other clients are doing. Keeping more information in the local cache may therefore end up hurting you more than it helps.
I may be wrong - but I don't believe this will have the impact you imply.
Yes - FileMaker notifies all clients when a data change is made and that they need to 'clear the record' from it's cache. But - that doesn't mean the client then download the new change immediately.
My understanding is (and I fully admit I may be wrong) that the client will only trigger a download of the updated record(s) if it needs to read that record.
If that record is on screen at the time - that'll be immediately.
But - if that record isn't currently being used - then it won't occur until next time the user tries to access that record.
No, that's not how it works. The cache is only updated for records that have already been downloaded.
I think we are saying the same thing - but in a different way.
If a record is changed by another client - then FileMaker Server will notify our client that the record is stale and to clear it from the cache (if it's there). This alone doesn't trigger our client to download the record again, it just clears it from the cache.
If however our client is accessing that same record at the time - then our client will download the updated record immediately and then refresh the screen with the updated data.
My point is: Yes, FileMaker server notifies our client a record is stale as you stated. However, it doesn't keep the data in the cache up to date with changes - it just clears it - which triggers your client to download it again when and if it needs it (as if you are accessing the record for the first time again).
Also: Remember that the cache doesn't just store record data. It also stores layout, schema, etc. data.
That is not my understanding from the performance session at DevCon. The cache is refreshed on all clients "with the changes" as other users make changes.
And we may be discussing two different things. The record changes are most certainly updated on each client. Whether that happens in the cache or the temp file ... not certain. Clay Maeckel said "cache", but he may have meant "temp file".
The record changes are most certainly updated on each client.
I think we both agree on this point - that each client is updated with record changes.
Where I disagree, is that the client gets the entire record again. This doesn't make sense to me if it's just sitting in the cache and/or a local temp file and may never be referenced again.
Will see if I can get Clay to clarify this point for us.
I don't think I said "entire record". I just said "changes".
Nevertheless, you are correct. We really don't know for certain (it seems each of us has heard slightly different things), and would need an FMI engineer to clear it up.