FMS 8 Performance - (again)

[Doktor Joy]

I know this topic comes up a lot. I've read a lot of the posts here on this forum, and still not found an answer to my concerns.

The problem in brief:

FMS8 performance seems to be lacking. If I open a solution locally on a G3 700MHz machine with 640MB of RAM, it runs a lot faster (400%) than if I open the solution using a remote client on a G5 Dual 2.5GHz connecting over 100MBit LAN to a G5 Dual 2.5GHz FSA server with 4GB RAM.

The facts:

The TOTAL size of the solution, all files and records, is 12MB.

FSA version is 8.0v4. Client is 8.0v3

FSA server cache is set to 128MB. SAT indicates that Cache hit is 100%. Worst cache hit ever (over several days) was 99%. Client cache is set to 40MB.

Detailed problem examples to highlight.

1/ One view of the solution includes two Summary fields, an Average and a Total. It is a form view, but the fields display for the found set. It seems that FSA performs none of these summary calculations, and instead passes all data, of every record in the foundset, to the client, then the client sums over just the two fields.

2/ Another view of the solution pulls together approximately 40 different fields from some 15 relationships and displays them all at once. Some of the fields are value-lists calculated by-relationship. So, to display a given record in this view, a lot of relationships need to be followed. When running locally on the low-spec laptop, the solution scrolls through each record in the foundset very fast (for example, a found set of 100 records can be scrolled through in a second). When running remotely between the two 2.5GHz DP boxes, the 100 record found set takes 20 seconds to scroll through, and often 'hiccups' along the way - pausing at some records before moving on. This happens repeatedly if you just scroll back and forth through the found set - so it's not a 'cache hasn't been loaded yet' issue.

Even when scrolling through the most complicated of foundsets, or using a big foundset with the summary fields as in example 1, fmserverd and fmserverh never go above about 5% of server load. The rest of the server is idle.

I believe that a small solution like this that will fit entirely in memory ought to run MUCH quicker remotely than it does. Any ideas what the problem is? Are there perhaps some horrendously large indexes that need to be updated everytime I view a record? (The solution does use a lot of filter-relationships - it is a "all the information you could want at your fingertips" kind of product).

[Søren Dyhr]

It's pretty wrong to have Summary fields shown elsewhere than in summary reports, created via dedicated scripting - it won't hurt as long the file only contains a few records - but dear me it gets annoying...

One of the incarnations of the transaction model should be consdiered a manditory implementation here, and since you have ranked yourself higher than me should you be smooth sailing turning your solution in that direction instead ...you should be skilled enough not to mix metaphors, at least not expect it in the wrong tool.

--sd

[Steven H. Blackwell]

Your server cache is probably too low and your client cache is too high. Set the client cache to 12 MB and the server cache to its maximum allowed.

You may also be experiencing some issues with the dual processor on the Server.

Steven

[Doktor Joy]

Steven,

I see frequent suggestions on the forums here to set client cache to 12MB. Is this some kind of magic number?

Also, can you enlighten me as to the DP issues I might be seeing - or is there a thread on here you can point me at?

[Søren Dyhr]

I just want to know if you have studied this thread, including the links it provides??

http://network.datatude.net/viewtopic.php?t=102&highlight=debi

Since my hunch tells me that the hardware issues isn't the only thing to blame for this problem.

--sd

[Doktor Joy]

Hi Soren,

No, I was unaware of that thread - tvm for linking it.

I have now read it, very interesting. But, we have Server 8v4 and Clients 8v3 and 8.5, so I am guessing the local-processing of unstored-fields is NOT the problem.

However, the solution concerned does use a LOT of unstored fields, so, I'm off to re-eaxmine it and see if I can't get rid of some of them

[Steven H. Blackwell]

You are correct. This issue has been addressed. I do think you might examine your architecture. Also check your cache settings on both server and the various clients.

Steven