1 of 1 people found this helpful
My first guess would be memory caching / fragmentation. I'm assuming this is a multi-user environment with a hosted database. In such a situation, FileMaker maintains a cache of record contents on the local computer (ironically, to improve performance by avoiding frequent record fetching back to the server). As a user accesses more and more records, the size of the cache will grow. Also, each user will periodically receive a refresh of his cache based on what other users are doing (so if one user makes a change to a record, the other users who have accessed that record will see it).
If, hypothetically, a user were to be running other, memory-consumptive applications at the same time, then the cache might be come fragmented over time, and might therefore end up having to page back and forth to disk (virtual RAM) more and more as the physical RAM became more fragmented and consumed. Also, the larger the cache, the more likely that a record in it will require updating from the server (simply by probability - more records, more likely someone will change a record in it).
You can attempt to adjust the cache size in the Preferences dialog under Memory and see if that has any effect to test this theory. Other tests you can try would be to have a subset of users not run anything else on their machines and compare their results against those users who have other applications running, or directly comparing the experience of users with less memory against users with more.
In the mean time, does anyone have any clue as to why it would start out running well and get slower and slower and slower the longer it is open?
What you don't say: are all clients complaining about this? If not, what is specific about them? Any plugins, any features that they use that others don't? Are these larger clients with more concurrent users? Are you using 3rd party software on the server like SuperContainer,...
1 of 1 people found this helpful
I saw the following comment a while back and wonder if this is really so:
"If your script goes to preview mode and then prints, memory consumption of Filemaker Pro increases, and does not go back down until Filemaker Pro is closed. If you do a lot of printing this way, you end with a LOT of wasted memory. We've seen up to about 700MB of memory used by one Filemaker process (instead of the normal ~160MB with default memory reservation setting). I've observed this behavior using Filemaker Pro 11 on Windows Server 2008 R2 and Filemaker Pro 11 Advanced on Windows Server 2003."
When it is slow, ask them to open the Activity Monitor ( or Task Manager )
On my Mac Mini, FileMaker slows to a crawl, if I have no free memory
> We have recently been getting complaints that the longer a user has our files open the slower they get
Our system does a ton of Preview to Print. Every print script stops and pauses in preview mode.
Yes we have them complaining. I haven't yet had to get ear plugs but it is getting close. 90% of our client have 8 or fewer licenses so the concurrent usage is not high.
Our system uses a few plugins: Troi File, SMTPit Pro, POP3it Pro, and FMBooksConnector (QB integration usually only installed on a single machine).
Activity Monitor (Task Manager) will be a next step. We will have them get us screen shots when experiencing sloooooow performance.
is it only lack of free memory?
What about inactive memory?
In theory inactive memory should be available to processes as well.