It used to be true. I guess it still is.
Note: you can now monitor server statistics overall, and for each user
> Is it posibble that the machines, previously running 4Gb, were slowing down the experience for all other users for this particular module?
Thanks Greg, that's useful, and confirms my thoughts.
Still interested if anyone else has other experience of this type of scenario, or an explanation of why this is.
Every change to the DB has to be propagated to every user. The notification process is only as fast as the slowest computer. This causes all Clients to slow down.
Large amounts of data being access from the drive, like a summary report or a portal to a large number of children records, causes the server to become less responsive as it reads data from disk. The ‘new’ data displases the old data and it becomes s swap meet to access the two ‘different’ groups of requested data. MORE RAM on FMS! Better solutions: Reduce the number of child records returned, through the relationship, instead of filtering the returned set. Run reports during low usage times and store the results.
The first line makes a lot of sense - puts it in a nutshell, think I may well quote you on that!
Our FMS server itself has plenty of RAM - 64Gb, and 2 Intel Xeon processors at 3.33ghz. We are aware we need to look at that particular module to change the way it works for speed. The question is really to see if the effect was placebo type thing, or whether it was actually making a difference. From the two answers it sounds like it really does make a difference!